AJAX Applications vs Server Load?

Squink asks: "I've got the fun job of having to recode a medium sized (500-1000 users) community site from the ground up. For this project, gratuitous use of XMLHttpRequest appears to be in order. However - with the all of the hyperbole surrounding AJAX, I've not been able to find any useful information regarding server load [Apache + MySQL] when using some of the more useful AJAX applications, such as autocomplete. Is this really a non-issue, or are people neglecting to discuss this for fear of popping the Web2.0 bubble?"

Cache, cache and CACHE

[Anonymous Coward]

After doing quite a bit of AJAX type work for my employer, that's the best advice I can give you. The most common things will be queried the most often, so caching is the key. If you're using PHP and MySQL, use something like eAccelerator for PHP (less important) and MySQL's query cache (most important!) properly tuned. And remember, not everything AJAX has to query a database.

Re:Cache, cache and CACHE

[captainclever]

And Memcached [danga.com]!

Delay the autocomplete

[Albanach]

Another suggestion is only to auto-complete after .5 seconds with no typing - that way rather than autom completing s sl sla slas slash slasd slasdo the user who knew exactly what they wanted doesn't load down your server with spurious requests.

bad advice: try BENCHMARK BENCHMARK BENCHMARK

[Anonymous Coward]

Uhm, you should never give blanket advice like that. This is the simplest brute-force way optimize an app:

STEP 1: develop a set of benchmarks.

STEP 2: adjust something

STEP 3: see if it improves your benchmarks. If not, roll it back. REPEAT STEP 2

How can you possibly improve your app if you can't even tell when you've improved it? PHP accelerators may or may not help (actually I would recommend AVOIDING PHP because of the difficulty in dealing with persistent compiled PHP code). MySQL query cache may or may not help (in some of my apps, the query cache *lowered* performance).

You can improve on this basic formula by the way. For instance, you can use benchmarks to *identify* which parts of the app are the slowest so you can focus your energy just on the slowest stuff. But the basic premise is the same: benchmarks are the most important thing you can do. Devote 1/3 of your time and budget, at least, to developing the benchmarks. Throw in some automated testing too, while you're there.

Decide what you really need

[b4k3d b34nz]

It's going to be tempting to use a lot of AJAX, especially if sounds fun. In reality though, you should be considering user experience, since this is a community site. Don't use an AJAX call where someone might expect a page refresh.

With that said, it's best to try to cache frequently accessed items in memory (regardless of whether you're doing AJAX calls). ASP.NET does a good job of this--I don't know what you're programming in, but definitely find out how to cache so that you don't have to read the database all the time. This reduced our database server load from 55% to 45% upon implementation (it's separate from the web server).

To specifically answer your question, the thing that's fast about AJAX is mostly perceived. Yes, you'll reduce calls, but at the sacrifice of having to code things twice: once for users with JS, once for those without. Use it in places where it's senseless to reload an entire page. For example, opening a nested menu. Searches that aren't done by keyword are good as well. Like has been said above, delay a server request until the user is done typing so that you can reduce calls. Remember, it's still a hit on your server, it just doesn't have to get all the rest of the crap on the page.

To reduce bandwidth, use JSON instead of XML, and only pass the headers that you need to into the AJAX call. To reduce server strain, cache frequently accessed database calls/results. Also, other non-AJAX javascript can help reduce calls, such as switching between "tabs" with some display:none action instead of reloading a page.

The answer is not gratuitous AJAX, the answer is thinking through how people will most commonly use your site, and making those parts easiest (so users don't have to redo things, therefore wasting your server capacity/bandwidth). Take things that shouldn't have to refresh the page and make them work using javascript, AJAX or not. Depending on how crappily things are coded now, you should see between a 15 and 35% reduction in server load and database calls.

Cash cash and money

[tod_miller]

Don't mention web2.0 it is utter stupidity.

People talked about RSS web server loads versus advertising revenue about 2 years ago on slashdot, so I hardly think people are that stupid.

Also, if every page is (at best - which I doubt in your case) 50Kb - and the AJAX traffic each call is 500bytes - decide if that ajax call saved an entire page refresh (from your site, a page is probably 120Kb, with ads for customer pages can be 200kb..)

So, initial download even at worst (or best) would be 50Kb, each call 500bytes, so you can see the % of overhead is little, and if this call SAVED a refresh then you have saved 49.5p which is good for half a pint on fridays between 12 and 2 at the little willow on hidge street.

good day.

Comment removed

[account_deleted]

Comment removed based on user account deletion