Slashdot Mirror
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?"
There isn't any useful information out there because it all depends on what you are doing.
Take a typical web application for filling in forms. One part of the form requires you to pick from a list of things, but the list depends on something you entered elsewhere in the form. In this instance, you might put the choice on a subsequent page. That's one extra page load, and needless complication for the end user. Or, you can save the form state, let them pick from the list, and bring them back to the form. That's two extra page views and saving state. Or, you can use AJAX, and populate the list dynamically once the necessary information has been filled in. That's no extra page views, but a (usually smaller) JSON or XML load.
In this instance, using AJAX will usually reduce server load. On the other hand, something like Google Suggest will probably increase page load. Without knowing your application and its common use patterns, it's impossible to say. Even using the exact same feature in two different applications can vary - autocomplete can reduce server load when it reduces the overall number of searches, but that's dependent upon the types of searches people are doing, how often they make mistakes, how usual it is for people to search for the same thing, and so on.
Bogtha Bogtha Bogtha
There are a lot of good points posted in here. Caching on the client on the server are two big things for a good application that is using the XHR. A good database design is also key if you do not want to use "like" which slows down the search. In Ajax In Action as discussed on Slashdot here. In chapter 10, the project talks about how to limit post backs with an auto suggest by using the clientside efficiently. The basic idea examines the results returned. If it is under a certain number, it uses JavaScript regular expressions to trim down the dataset instead of hitting the server. Plus there is a limit on number of results returned so it speeds up response time.
One thing I can not get through people's minds enough when I do my talks is Ajax is not going to be a "client-based app" on the web. The main reason is going to be network traffic getting in the way of your request. Imagine a dial up user in India with your server sitting in the United States. The request is going to have to travel to the other side of the world and back with the slow speeds of dial-up. Testing on your localhost is going to look great until you get on an outdated shared server hosting multiple applications with a full network load. Yes we are talking small requests pinging the server, but 1000 users with a 10 letter word could mean death if you designed the system badly!
I love XHR, cough Ajax, but you need to look at what you are dealing with. The design of an XHR app can kill you if you do not think it out fully.
My 2 cents,
Eric Pascarello
Coauthor of: Ajax In Action
I am not quite sure what the question is, but I am fairly confident that AJAX is not the answer. IMO AJAX is a freak of nat..., computer science.
AJAX reliance on ECMA-script seems like a shaky foundation at best. I imagine debugging ECMA-script can be quite clunky and even if tool support might solve this problem at some point, there is no guarantie that browsers will interpret ECMA-script the same way, it seems like an embrace and extend waiting to happen.
I will not venture too far into the dynamically vs. statically typed language discussion other than stating that personally I prefer strongly typed languages.
I get the impression AJAX is a quick-and-dirty solution to a problem that requires something more advanced.
It seems like AJAX is an attempt to overcome the shortcomings of thin clients using the technology that had the widest market penetration, without considdering whether the technology was the appropriate tool for the job.
I am afraid that we will have to live with AJAX for a long time. A tradgedy similar to VHS victory over betamax, where an inferior technology beat a superior one.
I wonder if something like a next generation X-Server browser plugin or a thick client Java framework might not have been better suited for the job. It can't help but feel like AJAX is somehow trying to force a round peg through a square hole.
I think we're all saying the same thing here, try to see if AJAX (ugh i feel dirty) makes sense in your webapp. Hard to see sometimes (see below)
Of the three examples Google maps is the only one that uses AJAX in a manner that provides major benefits over a traditional implementation
Now hold on. Gmail is another perfect example of how AJAX can help. Say I have an inbox with 50 emails and I want to trash, archive, or otherwise do something to one message/thread that would involve it being removed from my view, the rest of the inbox (not to mention all the other peripheral UI elements) shouldn't change. In the old way we'd re-request all this tremendous information (say ~95% of the UI) that didn't even change! And this is even more obvious when you remember that each seemingly tiny, simple piece of the UI (say a message line) may use a bunch of HTML (not to mention scripts, css, etc) behind the scenes to make it look/feel a certain way. In the AJAX version we'd just have to add some scripting to remove that DOM element from the page and send a simple, say 0.5KB, HTTP message like "[...]deleteMsg.do?msgid=x[...]" to the server. You still have to suffer the TCP round trip latency (but less so), but the difference can be dramatic, no?
why run from Vincenzo?