10

Clearly AJAX improves the user interface but does this also decrease server load? You would think it does because the entire page will not have to be served up each time, but maybe there are other variables I'm not considering.

6 Answers 6

14

It depends on what you're doing and how you're doing it.

  • If you're replacing full page loads with AJAX requests (i.e. only doing AJAX calls when a user clicks on what would have been a full page load) then AJAX will decrease server load because you're (presumably) doing less processing and returning less data.

  • On the otherhand, if you're adding auto-update type AJAX that polls the server every few seconds then that could increase load depending on the user (it might not increase the server load if the user keeps hitting F5 to refresh manually anyway, but most people generally don't do that for hours)

  • Another AJAX optimization is to only load more data as you scroll. In that case if the user doesn't scroll all the way down, that's wasted processing.

Of course actually implementation can skew results either way, these are typical results assuming reasonably good implementations.

1
  • The real question here is what changes when you move to an AJAX way of doing things? Are you able to eliminate work that was being wasted before by moving to AJAX, or merely breaking it up into smaller pieces? (and adding overhead in the process) Oct 18, 2011 at 1:50
3

Of course it does serve to decrease the server load. Look at this presentation @ jsconf'09 -- for how Facebook used ajax to do that.

Ajax is async. server communication -- and you can use that in myriad of ways. People use it for loading simple JSON to real-time Web, and everything in between.

Remember -- the real challenge is the balance between client and server. Strive to make each party do it's work such that the system is optimized and you get obvious benefits of Perceived Responsiveness and real Speed.

3

There are other factors you are not considering -- in most cases, AJAX will increase server load. In a typical, non-ajax scenario, a user loads one big page every few seconds or few minutes. Yes, that single page is a bit more work for the server, but it has plenty of time between requests to recover and serve other requests. In an AJAXified scenario, that single page load is now dozens of small hits, constantly hammering the server and waiting for responses.

It is a bit like death from 1000 cuts -- none of the requests are that big in and of themselves, but the total weight is a killer. Especially when you start considering that these small requests are just about as expensive to serve as a full-page request. In both cases, you are probably running through an entire web application pipeline, hitting a database and waiting for an answer while sitting on a precious HTTP connection.

Here is an example of how ajax can get ugly on the server real fast. Let's take a typical "executive dashboard" that features 4 slots for widgets. Let's say the CEO likes a full sales report in the right side, a top 10 list of earners in the middle and a company share price report on the right. And let's say we are going to do this via simple ajax remote requests. Without taking into account stylesheets, images and other assets, your page now requires 4 HTTP round trips (main page, each of the dashboard reports) against the server. Each of these requires a full web stack to execute -- you are going to be hitting databases and rendering HTML using your web framework, right? Now multiply the single CEO by 2000 remote users some of whom have spotty connections.

Conversely, you could have a single server-side page that executues and returns a HTML skeleton as well as the data (included in in-page JSON) to render the reports. Single, bigger connection but less beating on the web server in total because you are not handling 4 requests and spinning up 4 pipelines, etc.

9
  • 1
    Can you give an example of a small request that you would need in AJAX that you wouldn't need otherwise?
    – jhocking
    Sep 27, 2011 at 16:55
  • 1
    Sure -- ever notice how, on this site, it can tell you if someone answered a question already? That is accomplished via a small ajax request . . . Sep 27, 2011 at 17:10
  • @WyattBarnett AJAX doesn't necessarily mean polling. You can simply be replacing full page loads with partial page loads. In many cases it can increase server load but I don't think it's true in "most cases".
    – Davy8
    Sep 27, 2011 at 17:43
  • hm, well that example seems to me more like something you can do in AJAX that you can't otherwise, rather than something which requires more server requests than otherwise. I suppose the OP was unclear if he meant "more performance when doing the exact same thing" or if he meant "more performance when taking full advantage of AJAX"
    – jhocking
    Sep 27, 2011 at 17:46
  • 1
    Note that polling / long polling are a mere subset of AJAX (as noted here), also referred to as “comet”. Websockets, which enable “true” polling-free push or server-side (server-initiated) AJAX will greatly reduce the resource waste required for this kind of feature.
    – Alan H.
    Sep 27, 2011 at 21:36
2

If you are using AJAX to replace work that the server would otherwise be doing then yes that will improve server performace. However, you may have designed things so that the server is still doing just as much and now whatever is happening with AJAX is on top of what the server was already doing.

Mostly this is about UI stuff, since you shouldn't be doing anything else on the client-side. Basically, anything the server was doing to support UI (eg. reload the page with a different layout in response to user input) do with JavaScript instead.

0

If HTML rendering is a huge part of your application server's performance profile, then moving HTML rendering to the client can be a performance win on the application server.

However, if HTML rendering is a small part of your application server's performance profile, then more requests will typically mean more trips through the stack, more queries, more of everything on the application server, a performance loss.

Of course, the only way to know in your particular case is to try it out.

8
  • 1
    I'm having trouble thinking of any examples where using AJAX would cause more requests than doing the same thing without AJAX. Can you give an example?
    – jhocking
    Sep 27, 2011 at 16:58
  • 1
    HTML is always rendered on the client side.
    – Jonas
    Sep 27, 2011 at 16:58
  • 1
    Presumably he misspoke and meant "manipulation" and not "rendering"
    – jhocking
    Sep 27, 2011 at 17:03
  • Starting from view/template, combining it with variables, and rendering raw HTML from it.
    – yfeldblum
    Sep 27, 2011 at 19:09
  • AJAX would cause more requests than doing the same thing without AJAX in cases like: your main layout has "holes" but is delivered with those holes to the browser, and those holes are "filled" using AJAX. See e.g. Facebook.
    – yfeldblum
    Sep 27, 2011 at 19:10
0

You have to consider the best way to implement your solution. A simple non dynamic form does not need ajax and adding it may actually harm perfomance. If your problem is bad queries all the ajax optimization in the world is not going to get you a performance increase that will be acceptable.

If your server is overworked you need to figure out why.

If you are getting alot of hits then ajax is not going to fix that problem you need more capacity. Adding ajax will just increase the number of requests that your server has to handle.

If you have a complicated page you should see if there is anything you can do client side to reduce the load on your server. If your page is dynamic but really has a limited data package caching that for client side adjustment may pay off better.

And some times Ajax will help. When you have complex forms with dynamic data ajax wins the day. But if you queries are complicated and take a long time to run then ajax still will not solve your problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.