Things to consider when using ajax and setInterval?

battletoad

Expert Member
Joined
Mar 10, 2009
Messages
1,461
Reaction score
52
I am testing out a system for polling. Someone sets up a poll, people on cellphones can vote.

There will be roundabout 3 randomly timed polls within an hour. So I'm thinking I'll have the cellphone users query the server every 10seconds with an ajax .post() request. Atm the system works fine with 10 testers (the pollster has a graphic of the results sent their way), but ultimately there will be an average of 70 volunteers in said hour, about 500 max.

Which performance issues should I expect my web server to suffer from?

On a side note, I had a look at web sockets. Seems perfect for my application. Unfortunately Android does not support the protocol in its default browser (nor Opera Mini, but that's expected). BB and Apple does however, so I will be implementing it soon enough with fallback for the unsupported mobile browsers.
 
I'm not sure if I understand you correctly.

Someone votes on a poll. And the results are pulled from your server at specific intervals?

If that's the case, I wouldn't worry about performance issues unless the resultset returned to the volunteers is huge/takes a long time to process on the server. You'd be able to run perfectly on a 256mb linux box with mysql and apache, provided your sql queries/code isn't the bottleneck

remember, there's nothing special you're doing here except forcing a client to check the website every 10 seconds. It's the same as if they're visiting for the first time anyway (or anyone else visiting it, be it google or whatever). And it's not the entire website you're returning, just the json bit that shows the results of 1 poll
 
apache can easily handle thousands of concurrent connections.

are you returning json, or parsed HTML (eg smarty templates, or JSP's)
 
I wouldnt worry so much about the server having strain, but refreshing a users browser on a cellphone every 10 seconds? That sound s like its going to chew like a muthafuka into their data bundles/airtime.
 
I wouldnt worry so much about the server having strain, but refreshing a users browser on a cellphone every 10 seconds? That sound s like its going to chew like a muthafuka into their data bundles/airtime.

a poll returning 3 or 4 answers and their results is maybe 3kb data. So I don't think it would be too much :) it's up to the user keeping the web app open though, I suspect they'll close it before the 10 seconds (I know I don't check my phone that much for poll results, regardless of if there's an item I want to win because of it or something)
 
a poll returning 3 or 4 answers and their results is maybe 3kb data. So I don't think it would be too much :) it's up to the user keeping the web app open though, I suspect they'll close it before the 10 seconds (I know I don't check my phone that much for poll results, regardless of if there's an item I want to win because of it or something)

3kb every 10 seconds... it adds up.
 
I'm not sure if I understand you correctly.

Someone votes on a poll. And the results are pulled from your server at specific intervals?

If that's the case, I wouldn't worry about performance issues unless the resultset returned to the volunteers is huge/takes a long time to process on the server. You'd be able to run perfectly on a 256mb linux box with mysql and apache, provided your sql queries/code isn't the bottleneck

There are a few departments who use the same server. I'm not sure the amount of their traffic.

For some reason, the server timed out yesterday for an hour when I was testing with a cluster of 50 pcs. I thought my queries, although small in size, was the cause of this... perhaps something like DDOS. But requests are time delayed, so no its not DDOS. Blame paranoia :)

EDIT: excuse the lack of clarity. the ajax calls are to check if there is an active poll, and if so send it to the client. The person who is running the poll receives the results. Definitely not a difficult application by any stretch of the imagination.

apache can easily handle thousands of concurrent connections.

are you returning json, or parsed HTML (eg smarty templates, or JSP's)

It returns xml, but I'm thinking of trying to minimise traffic even further for the sake of mobile data. Thanks for the heads up.

3kb every 10 seconds... it adds up.

At the moment its more like 400bytes for requesting an active poll (lack of an active poll results in 60bytes, which would be much more often than not). So statistically speaking, 1hour a day results in 23kb.
 
Last edited:
I've seen bidding sites go completely to a halt due to their Ajax queries being done once every 2 seconds.
The other problem that they had was that they had a timer that tried to query the page every 2 seconds, no matter if it actually took 3 seconds for the request to complete!

At my office we're only using a timer inbetween requests, but that doesn't always work that great with poor 3G/Edge connections either.

30kB/hour ain't that much, but I guess it adds up if you're going to keep it open for a month.

Compressed (by Apache) JSON is definitely a good idea if you're trying to send as little as possible network data across on HTTP. XML has quite a large overhead.
Firebug works quite nicely for checking the amount of data being sent and received.
 
If you want to do some kind of interactive polling I would recommend pubnub. They offer real time updates via a publish and subscribe mechanism. Take a look at www.pubnub.com. There is a free option and if you pay it is pretty cheap anyway. Oh, and it is cross platform, Web/Android/iOS/Windows/Linux/MacOS
 
50 PC's polling every 10 seconds made your server grind to a halt? Geez

My only suggestion would be to optimize your server then, regardless if it's being shared by several people/departments. A tiny request like that would be less than a second's worth of processing for all 50 requests at once. I know my server is configured to be able to handle 1200 requests per second (mysql/php/apache)
 
50 PC's polling every 10 seconds made your server grind to a halt? Geez

My only suggestion would be to optimize your server then, regardless if it's being shared by several people/departments. A tiny request like that would be less than a second's worth of processing for all 50 requests at once. I know my server is configured to be able to handle 1200 requests per second (mysql/php/apache)

use nginx you will get even better performance.

http://lowlatencyweb.wordpress.com/2012/03/20/500000-requestssec-modern-http-servers-are-fast/
 
Last edited:
AFAIK nginx is only good for static content? I'll read up on the link there. I know compared to Apache it's footprint is quite small, I used it for a while on some of my servers but opted for Apache after a while running on as little as possible extra's and configured to take a bit of a knock

Its not only the foot print that is small its FASTER than apache.

Lol what? only static contact ? its an HTTP server it can be configured with FastCGI.

http://wiki.nginx.org/Configuration
 
Last edited:
Its not only the foot print that is small its FASTER than apache.

Lol what? only static contact ? its an HTTP server it can be configured with FastCGI.

http://wiki.nginx.org/Configuration

The bigger guys (handling 35million + requests a day) mentioned they use apache for normal stuff and serve their images through nginx. I'll do a split test when my hits go above 350k a day. I'm happy with the 150ms response time/1.3 second page load I have for now.
 
The bigger guys (handling 35million + requests a day) mentioned they use apache for normal stuff and serve their images through nginx. I'll do a split test when my hits go above 350k a day. I'm happy with the 150ms response time/1.3 second page load I have for now.

What bigger guys are these that sounds like piss poor architecture.
 
Apache's problem is with memory and concurrency - not necessarily speed. Apache can serve large numbers of concurrent static files very efficiently when compiled in Worker (threaded) mode. However, PHP should not be treated as thread safe, and so almost all Apache servers that require PHP are compiled in Prefork mode. This means that each request causes Apache to fork (or reuse) a new process which quickly eats up memory which (hoefully) results in your max_clients being relatively low. Nginx uses an event loop and you'll typcially only ever have one Nginx process running for each processor you can spare. This makes your memory profile very stable. PHP requests get offloaded to PHP-FPM which still run within their own processes but with a far lower memory footprint than Apache and mod_php, mod_x etc. together. The bottom line is that you can do a LOT more with a lot less with Nginx.
 
Hmm interesting indeed. I might just use nginx again to see the difference in memory usage. However, wouldn't the memory then be offloaded (if I can use that word) to php-fpm instead?
 
Top
Sign up to the MyBroadband newsletter
X