Discussions

News: The AJAX effect on Server Load

  1. The AJAX effect on Server Load (36 messages)

    As new technology is adapted people start to look beyond the initial attraction to understand the true costs and benefits of adoption. This is clearly happening in the AJAX world as evidenced by a discussion thread currently running at Slashdot. In this instance the cost in question is performance.

    J2EE application servers provide a means whereby many users can share the same set of resources. In short, J2EE can service thousands of clients because at any given time, a vast majority of the clients are not physically connected to the server. The cost of this strategy of client server interaction is that it is much bulkier, slower and is a very static experience. In most cases using a plain browser as a client provides a very inadequate user experience. Enter AJAX.

    AJAX, of course, provides a framework that allows the client to contact the server with finer grained requests. With AJAX there is no need to download an entire page just to update the values in a selection in list in response to selecting a radio button for example. With AJAX the client is free to contact the server for that information on demand. The good is that clients now have a much richer experience. The downside is that AJAX breaks the assumption that clients will contact the server very rarely. Thus we should expect that AJAX will impose a performance penalty on our application servers. The question how much of penalty will be imposed?

    As with any question the answer is that all depends on how your application functions. However that is not a very useful answer. Useful answers come in our experiences with the technology experimenting with things that work and things that don't. And it is this experience that is being shared at slashdot. Here are some of the suggestions offered to help keep you clients from bringing your server to it's knees are:

    • Strike a balance in the size of the request made to the server
    • Use client side caching
    • Beware of auto-completion as it will hammer the server
    • Get more hardware
    The last suggestion is not a facetious as it sounds as we often need to provide added functionality at the cost of needing more hardware. What are your experiences tuning AJAX based applications?

    Threaded Messages (36)

  2. I think this is problem for some Ajax frameworks as Echo2
    or just badly written Ajax components.
    Fine grained ajax components results in decreasing server load and more clean traffic
  3. Here's an interesting article about changing a web server to provide better support for AJAX

    http://www.mortbay.com/MB/log/gregw/?permalink=ScalingConnections.html

    OK. It's not quite on-topic. But not quite off, either.
  4. AJAX is Delicious[ Go to top ]

    Right now I am developing a project for scheduling Trip Requests for a client(a Fortune 10 MNC) whose requirement was to post changes in the database as soon as the user drags and drops any trip request and the trip requests are ordred by Trip start time. I am posting the changes to database as well as the whole screen is being loaded using responseXML using JavaScript.
    Believe me AJAX is very fast and in a blink the changes are posted to database and the pages reloads.
    This is much better than the other alternatives which we considered for the project like Swing or even Flash.
    Its Just Delicious!!
  5. It's not that simple[ Go to top ]

    Some uses of AJAX can actually _decrease_ your load. If your pages are heavy, e.g., a complex portal page, then judicious use of AJAX can decrease your server load and increase your user-perceived performance.

    It's a tool, like anything else. While the total number of requests will usually increase for AJAX web apps, the size of the requests and responses are usually much smaller - they are targeted to the functionality being requested.

    The old performance techniques still work for AJAX - you're still dealing with a web app. You can use edge cacheing for AJAX replies in the same way you can for a "normal" web app request.
  6. While the total number of requests will usually increase for AJAX web apps, the size of the requests and responses are usually much smaller - they are targeted to the functionality being requested.

    It's not even that simple :-) While this is the general trend with Ajax apps, remember that lots of small 'chatty' requests will have a high overhead. (The HTTP protocol is pretty heavy - I'd recommend you have a play with Fiddler or the Apache TCP Monitor to get a feel for the number of bytes actually traveling along the wire to transmit a simple 'OK' response, and those overheads are generally independent of message response.)

    In some cases, it can make more sense to queue requests on the client and send them down in batches to the server. We discuss this in chapter 5 of Ajax in Action, and the Rico AjaxEngine also provides a working implementation of this technique.
    The old performance techniques still work for AJAX - you're still dealing with a web app. You can use edge cacheing for AJAX replies in the same way you can for a "normal" web app request.

    Agreed, that approach makes a lot of sense. For a type-ahead suggest that doesn't hammer the server, client-tier caching can be a very good idea too.

    Cheers,

    Dave
  7. As Charles alludes to above, more requests doesn't necessaily mean poor performance. The coarse-grained approach to network transfers has been taken too. The idea is that you should bundle things uip and pass them back instead of sending one int at a time (as an extreme example.) And as with every bit of advice in software development, it has been taken to a ridiculous extreme: wrap 'everything' up into a huge ball of wax and shoot it down the wire.

    The theory is that if you do this, you reduce the network overhead. So what? If you are cutting it that close with your resources, you need more resources anyway: you'll never survive a spike in load or having a server come down. Also, saving a few bytes over the wire at the cost of the user experience is penny-wise, pound-foolish.

    I know that the bill-ball-of-wax approach is dangerous. It came very close to sinking a project I was on. It took serious kluging and long days to pull it out of it's tailspin. We would have defaulted on (and probably lost) the contract if we hadn't created work-arounds.
  8. Sorry for all the typos above. I have a one-month old at home. It's been that long since I've had a full-night's sleep.

    "...network transfers has been taken too far."
  9. Hi,

    The following link might be useful in understanding the impact of clients with heavy (and highly interactive) workflow logic that creates a significant number of client-to-server roundtrips.

    http://www.jinspired.com/products/jdbinsight/networklatency.html

    "This article shows how JXInsight's timeline analysis mode can help development and test teams assess the cost of network latency in applications with excessive client-to-server roundtrips."


    Regards,

    William Louth
    JXInsight Product Architect
    JInspired

    "J*EE tuning, testing and tracing with JXInsight"
    http://www.jinspired.com
  10. The AJAX effect on Server Load[ Go to top ]

    While it is true that a ton of AJAX request on the server will increase overall overhead, since the cost of each connection is high, if you design your client-side app in such a way that it is able to get most/all of the information it needs for its current context up-front, and cache it in the browser (hidden vars?), then you could actually reduce the load on the server.

    I would argue that most (but not all) AJAX-enabled applications should reduce the overall number of connections per user session, and if it doesn't, then someone screwed up during technical design.

    FWIW, I come from the mentality that AJAX should be used to get data from the server, not just get snippits of UI html (like refreshing the content in a DIV - what a waste!)

    -Michael
  11. FWIW, I come from the mentality that AJAX should be used to get data from the server, not just get snippits of UI html (like refreshing the content in a DIV - what a waste!)
    But it is a less waste than to refresh a whole page, is not it?
  12. AJAX not the answer[ Go to top ]

    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
  13. May be right but...[ Go to top ]

    I get the impression AJAX is a quick-and-dirty solution to a problem that requires something more advanced.

    That was also the case of Windows x OS/2, VB programming style x OOP, etc

    Some things just survive and even grow, no matter how messy they are. That´s life.
  14. Just a tool...[ Go to top ]

    Have you actually looked into ECMAScript? It's actually a pretty nice language, and capable of much more than the usual skript kiddie nonsense. And cross browser scripting is getting easier and easier as support for standards increases. There are some very thin libraries now that unify the JS event model, and with these it really is possible to make cross browser scripts that actually work.

    As for AJAX vs plugins, we'll have to agree to disagree. We already have a very capable, almost universally available thick(er) client plugin (Flash). I'd prefer to stick with AJAX.

    Getting back to the subject topic, the MortBay blog on Jetty has some of the most interesting articles I've read about AJAX performance, and the architectural changes they're considering to address it. Highly recommended.
  15. AJAX not the answer[ Go to top ]

    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.
    Ajax is not that hackish as some think of it. Also, after VHS they released SVHS, and DVHS was released relatively recently, so things are not that bad. Another benefit that comes for free is that you can use VHS cassette as an assault weapon.
  16. I had a chance to work with a few financial applications and they mostly use XML, XSLT for their processing. AJAX can be the very best way for improving the performance in that scenario. Just retrieve the XML from the server, apply the XSL transformation using javasctipt (Google has created a AJAXSLT library in javascript and that can be obtained from sourceforge.net). This would further reduce the load on the server in terms of bytes being sent out as response.

    Note: This again has a fair assumption that ppl out there are using decent enough machines in terms of processor and memory.
  17. There ARE better solutions than AJAX available in the RIA space already. E.g. light weight client-side Swing apps.
    If you combine this with Java Webstart, then you can easily
    deploy (even) mission critical rich Internet applications.
    One example in this context is ULC from Canoo.com.
    This library is based on Swing and enables an almost seemless client server split of Swing components: all listener/event handling code that is known from Swing is executed at the server while the widgets are displayed remotely. I am curious if anyone knows similiar technologies (tell me).
  18. AJAX not the answer -> very likely[ Go to top ]

    At least there is some tendency to think about appropriate user interfaces for web applications, as pure HTML is often not sufficient and leads to awkward user experience.
    AJAX is currently the hype technology on the RIA market, but has already proven some crucial shortcomings. In addition to the well known problems with: use of back, stop and refresh buttons, book marking, printing, offline availability, browser configuration …… it is especially the maintainability (as with java script) of the application, which will give the biggest headache.
    However there may be niche applications, which could benefit from the use of AJAX, but I recommend to do an assessment, as described in: Rich Internet Applications and AJAX - Selecting the best product
  19. I have been using the new echo2 framework that is fully AJAX based and it has been an interesting experience.

    Everything that echo2 does is ajax based. This has pros and cons of course like all things. By design echo2 maintains the entire web application in memory which allows for its highly dynamic behavior. Only changes are exchanged between the browser and webserver which makes for very efficient communication and a rich user experience (behaves like desktop app would for the most part). And the API is very natural and completely component based where the developer is overburdened with state management.

    The echo2 framework makes it very easy for the developer to keep every screen past and future cached. Now for an internet application this is a scalability problem not to mention session replication/clustering type concerns. But this can be addressed with proper coding patterns. And unlike most web frameworks like Sturts/Tapestry/JSF, which do the opposite and make the developer work extra hard to make application state persistent across requests. You pay for this lighter weight in much more complex code and there is a performance cost in constantly creating lots and lots of objects for every request.

    But with good coding conventions using echo2, I only keep the current visible screen in memory which allows me to use the full power of the framework and of AJAX while keeping memory footprint to minimum and allow for high scalability.

    With hardware advances these days I believe the restriction on memory and session affinity limitations will go away. For anyone building a new web product, you must choose a web app framework that is fully AJAX capable from the ground up where AJAX is not just a bolt on. Page and form submit type frameworks will go away.

    I think frameworks like echo2 will be the wave of the future as web programmers evolve out of the stone age. And this goes hand in hand with both hardware and software technology advances.

    -Sam
  20. Count it[ Go to top ]

    If you will implement same application once with AJAX and once without AJAX then for sure AJAXed version will transfer less data. Both versions with same usage will consist of same number of requests.
    Of course if you will put in AJAXed application more user friendly functions then you have to pay for it. However you are responsible to decide how far you can go (that is reason why they call as specialists).
    About hardware - it's sometimes cheaper to buy new hardware than investigate and fix some specific performance problems/bugs.
  21. Old C10K problem[ Go to top ]

    It's the old c10k problem. This paper shows you how many requests per second you could get out of any old PC:

    http://www.kegel.com/c10k.html

    Basically you want do the following:

    1) Use a http and servlet runner that uses select/poll. If you are using apache 1.x then upgrade to 2.x. I don't know if tomcat uses nio, but if it doesn't then switch to something else. WebLogic Express does, I think, but you have to pay for it. I don't know if jetty does.

    2) Use an os with a scalable scheduler, e.g. linux 2.6 or (I think) netbsd. See "Conclusion" here: http://bulk.fefe.de/scalability/
  22. re: about tomcat[ Go to top ]

    on jdk > 1.4 all iostreams internally use nio.
    Moreover, tomcat5.5.12 now can use native Apr lib for http1.1 connector.
    So tomcat will fit perfectly.
  23. re: about tomcat[ Go to top ]

    on jdk > 1.4 all iostreams internally use nio.Moreover, tomcat5.5.12 now can use native Apr lib for http1.1 connector.So tomcat will fit perfectly.

    1) I find your assertion about 1.5+ very difficult to believe. Do you have a reference for this?

    2) I actually mean using tomcat without apache. If tomcat switched to using nio it could probably serve files with the same throughput as apache.
  24. All is right[ Go to top ]

    1. jdk 1.4+ (not only 1.5+)
     see jdk source code, for example FileInputStream and like
     and you will see usage of nio. So now classic java iostreams is facade over nio.

    2. I meant tomcat5.5.12 without Apache httpd, but only with ~800kb Apache Portable Runtime Connector native library which, if found on path replaces Tomcat Coyote Http1.1 connector with apr Http1.1 connector and is recomended for production env (better performance and scalablilty (on windows, linux and other os).
  25. re: about tomcat[ Go to top ]

    So basically, usage of Apache Httpd in front of tomcat5.5 is no longer recommended even for static resources.
    High performance apr with openSSL and other goodies are in tomcat now.
    Benchmarks shows same performance (google if you want)
  26. All is right[ Go to top ]

    You need asynchronous IO (it's a feature of NIO) in order to go with 10K connections in java. FileInputStream may be based on NIO but the API forces you to work with one thread / stream and this is not very helpfull. Coyote connector does not use async network IO, so you need 10K threads in tomcat in order to manage 10K simultaneous connection. And this is quite imposible unless you have big irons.

    Still you can put Grizzly on top of tomcat and hope for more connections. http://weblogs.java.net/blog/jfarcand/archive/2005/06/grizzly_an_http.html

    As a starting point you should read http://weblogs.java.net/blog/opinali/archive/2005/10/tomcat_goes_nat.html as well.

    Regards,
    Horia
  27. but what sense?[ Go to top ]

    It seams that you don't read previous post.
    1. Tomcat coyote http1.1 connector DOES USE NIO (explictly or by jdk's 1.4+ iostreams facade). I review sources recently so I'm sure.
    2. Tomcat5.5.12+ now has apr native library with full power of Apache httpd 2.0 connector (http & https).
    3. Blogs are just thought of some people and while reading those ones I didn't find any useful info, but just stale thought about already known things.

    PS. do not promote useless blogs
  28. but what sense?[ Go to top ]

    It seams that you don't read previous post.1. Tomcat coyote http1.1 connector DOES USE NIO (explictly or by jdk's 1.4+ iostreams facade). I review sources recently so I'm sure.2. Tomcat5.5.12+ now has apr native library with full power of Apache httpd 2.0 connector (http & https).3. Blogs are just thought of some people and while reading those ones I didn't find any useful info, but just stale thought about already known things.PS. do not promote useless blogs

    I think what he said is that Tomcat allocates one thread per request, which is probably the case for servlets (as per spec) but is not necessarily the best for serving files. On each workload there is an ideal number of threads reading selectable sockets and an ideal number of threads doing disk reads, and these are independent numbers.

    However ajax requests are probably servlet requests so they have to use a whole thread. It's really the whole preemptible threading model which is a problem here. But one can still optimize throughput by keeping the number of these threads bounded, and using linux 2.6 which has an O(1) scheduler.
  29. I agree, but[ Go to top ]

    I agree with idea, but my counter argument was againts such a thouht that "Tomcat cannot serve 10K because coyote doesn't utilize nio". I think it is totally wrong thesis,
    so my anwser is "No matter whether Tomcat can serve 10K, It is absolutely unrelated to fact that CoyoteHttp does/doesn't use NIO".
  30. but what sense?[ Go to top ]

    Here is the documentation on what using APR allows in Tomcat (detaling benefits for HTTP, HTTPS, and AJP):
    http://tomcat.apache.org/tomcat-5.5-doc/apr.html
  31. AJAX is the way we cannot avoid[ Go to top ]

    The question is what drives the demand of AJAX. In addition to connectivity and sharing, end users expect to have richer internet experiences. It's the trend we cannot reverse.
     
    As AJAX gives Web applications a fresh look, the rising cost is challenging its way to success.
     
    Here is a server-centric approach you might take a look. And, it's an open source.
     
    http://zk1.sourceforge.net
  32. We made the decision decades ago[ Go to top ]

    Remember the age of green terminals? Remember how people argued extraordinary resource requirement for running GUI apps?

    No double that more communication bandwidth and server power are required to enable RIA. The bottom line is that users are demanding a better UI for Web applications.

    Current RIA appearances might be rough, confusing and counter-intuitive. It will evolve.

    AJAX might be a temporary technology. Heading to rich Web won't change:)
  33. The AJAX effect on Server Load[ Go to top ]

    Hi all,

    Have to agree with the comments re: JavaScript, not very pleasant to work with when you start to get lots of it. Cross browser is another problem as is its quirky interpretation (ever seen perfectly good script start to go bad for no apparent reason, I know I have and the cause is usually some obscure bug introduced in some totally counter-intuitive way)?
    Having said that as I understand it Ajax is more about using some basic JavaScript to make asynchronous requests which sounds OK although I'd watch out that I wasn't putting too much business logic in the view component.
    So long as the app doesn't lean to heavily on JavaScript for UI candy then its probably going to be more reliable and maintainable. I'm currently stuck with an app that has reams of JavaScript on the front end and guess what, no-one wants to touch that bit :-)
  34. People really should take a look at the latest ajax frameworks. See Rico, Dojo, Scriptaculous, DWR and other ajax toolkits, all of them shield you from cross-browser problems, and provide a uniform and simpler way of dealing with events, widgets (form controls if you wish), screen updates and client-server communication.

    There's no need to hand-code everything in javascript from scratch anymore, just call some framework's API and most of it should work automagically.
  35. The AJAX effect on Server Load[ Go to top ]

    Hi all,Have to agree with the comments re: JavaScript, not very pleasant to work with when you start to get lots of it. Cross browser is another problem as is its quirky interpretation .... although I'd watch out that I wasn't putting too much business logic in the view component. ...

    We hit the same problems and we have founded an opersource project to handle them. Please take a look of the ZK project's product overview (http://zk1.sourceforge.net/wp/ZK-wp-prodovw.pdf) that mentioned all these AJAX development challenges and how ZK overcomes them. Our aim is to make developing an AJAX web application as easy as developing a desktop application.
  36. AJAX is the newest in a depressingly long list of hacked-up solutions to the "web as platform" problem. All it lacks to make it a first-class, undisputed heavyweight contender for "your job is all debugging, all the time" status is the addition of PERL! Indeed, by the time I finish typing this message some wanker will probably have already added that abomination to this one. And pray-tell, where is the PHP? I mean, this crap is supposed to be Web 2.0, right? Hasn't anyone explained to you guys that PHP is the real Web 2.0?

    I'm a big Java fan but a Java critic once wrote that it was overhyped. He went on to succintly state what he thought the problems with web programming in general had been during the "bubble phase":

    "...It seems to me the 'new economy' that started with the Netscape IPO and ended in April of 2001 was mostly about squeezing productive work out of very poor programmers. The most important languages were thus the ones with the least rigor, the lowest barrier to entry, and trial-and-error debugging methods: Visual Basic, Perl, and Javascript. Compared to these languages, Java failed to meet whatever 'unique business needs' defined this era of atrociously prolific low-quality programming"
    quoted from http://web.ivy.net/~carton/rant/java_languageoftomorrow.html

    And now Javascript comes round again. Only this time we'll dress it up with XML and make it sexy. Put a dress on that turkey and turn her out to turn tricks and bring me my bling-bling yo' ho'! "Dimpled flesh, what? You get what you paid for!"

    Here's the thing - do you want an application or a bunch of speghetti code. Experienced application programmers pooh-poohed the "web as platform" at the start of the bubble, pointing out that adding a network to the equation makes NOTHING EASIER. Ten years on and we are still "...trying to squeeze productive work..." from the 'I'm too busy with my Playstation to get it right so I'll do it with Javscript' crowd.

    I guess I can look on the bright side. In 300 years we might have enough horror stories so that a professional standardization effort can put an end to all these self-styled "programmers." I think it more or less took that long with architecture (and the dropping of a cathedral or two on scores of workmen). Last time I looked you couldn't just hang "Architect" or "Dentist" on your front door.

    OK - all finished. Going along now to find the PERL port to the AJAX framework...
  37. Agree! My clients are impressed with Ajax. It's what my clients need at least.