I've heard polling the server is not the best of ideas.
Let's say I make a client-server application. A simple game for example. Where each client polls the server every half a minute. How many clients is it possible to have before it overlaods a wamp server? Basically how robust is Apache for this kind of stuff? Getting a request, aggregating data from mysql server, and then returning the data in an xml format.
This is a really open ended question. It entirely depends on your configuration, how many apache services do you have running, how many physical servers do you have, how is your mysql server setup (is it on it's own machine)? You want to also keep in mind that by polling the server you have to initiate a connection each time and allocate resources for that communication (in the lower level networking and your program).
If at all possible it might be better for the server to push content to the client (assuming a push happens less frequently than polls happen).
Can't really give you numbers. It depends on a bunch of factors (including hardware).
What's more important to you: How many concurrent users you can support or how real-time the results are?
If you looking for real-time results, you probably want to investigate something like Comet or long polling.
If you're looking for supporting a lot of users, the long polling approach probably isn't ideal and you'll probably want something more lightweight than Apache. Personally, I'm a fan of nginx.
EDIT: And if you're feeling really hip, your best bet for real-time results here is Web Sockets, but if you're a microsoft guy this isn't going to do you much good as IE doesn't support them.
My guess is you will maxout whatever the request is handling and the mysql database before Apache server becomes a problem.
However, going out on a limb, if proper caching is in place, and a sufficiently smart architecture and pragmatic design, and effectively only the 30 sec polling, you should be able to support a couple 1000 users.
But : mock it up, quick and dirty, do roughly what you think you will be doing, and hit it with JMeter (or similar) with 3, 10, 30, 100, 300, 1000, 3000, ... till you find the performance wall.
I am scared about the aggregating data part... if aggregation is really needed, carefully architect it so you do not need to go to the DB, because this will kill you in production, and you wont find it in development.