Question

I need to build a web-scale public site that can handle, say, 100 queries/sec. I want to use Ajax to make it interactive. The Ajax must be bulletproof across all major browsers and all reasonable situations (stopping, restarting the page from the client’s side; coming back the next day after leaving the terminal all night; etc.) The server will be a distributed Linux farm.

Jquery $.post() seems like it could fit the bill.

In the old days, Ajax was implemented by clever schemes to keep the socket open between the server and the client. This approach then supports “Ajax Push”, a.k.a. “HTTP Server Push” or “Comet”, a two-way communication pipe that allows the server to initiate packets to the client.

The main problem I see with this Ajax approach is that it apparently ties up a socket on the server, for an indefinite long period of time. This would not seem to scale. Secondary problems are that breaking a modem connection overnight will break the pipe; reloading the page from a saved local version probably won’t re-establish a live pipe; and various browsers require various unreliable hacks to get the Ajax working in the first place.

Using a strict “client pull” model of Ajax, based on post requests, would seem to fix all these shortcomings. I’m happy to give up the capacity for unrequested server push, if I can gain a bulletproof implementation substrate.

So I am using a simple
$.post( 'serverAjaxModule.php' ,
{mydata: Dataword },
function(output){ do_handle_results( output); });
invocation, which seems to work pretty well for at least Firefox and Safari.

However, I don’t know what this is doing under the hood. I learn that .post is a macro for .ajax, and there seem to be a handful of commands, such as .ajaxSetup and .ajaxStart, that have names seeming to make them requirements. And then there’s the jquery-ui.min.js include, which could be running almost anything as setup.

My questions, then:

1. Does jquery $.post scale well, to massive usage?

2. Is $.post implemented with the old continuous-open-socket paradigm, or does it establish a new socket connection every time I do a client-pull ajax message? Implications?

3. Am I right in thinking that I don’t need to call anything extra, such as .ajaxSetup nor .ajaxStart, etc., and I can just go ahead and call $.post successfully without any unusual consequences?

4. How good is the jquery cross-browser functionality for this feature? Can I rely on it simply working for basically all reasonable modern browsers, or are there known ones I have to watch out for?

5. How far back does this approach to Ajax technology go for ancient browsers? .post would seem to be using round-trip POST technology, which should be completely universal and bulletproof; yet I seem to remember cases with the old technology where some browsers were too old to support Ajax, and we had to laboriously code around it. Are those days gone, now, with the new jquery? How much do I have to worry about non-Ajax support, in the civilized international world?

6. Anything else to watch out for? If you were just beginning to build a massively scalable implementation, what are the most important points that you wish someone had told you about creating dynamic, interactive web experiences?

Thank you so much for your kind assistance.

Answer 1

$.ajaxSetup is not required but it is useful:

• if you run a $.post you can’t define an error handling function and debugging will be hard – in this case you can define a generic error function in $.ajaxSetup;
• if you run a $.post and receive HTML data that you need to show and you need its elements to have bound events to them – you’ll be able to define what event handlers should be reapplied to these new objects;

$.ajaxStart is not required either.

jQuery UI is a user interface core library that usually comes packed with some other libraries such as drag&drop elements behavior, sortable elements behavior and some widgets like an accordion menu, modal message box etc.. This is not needed unless you intend on actually using its API to build your front-end.

1 it has no constructive reason (that I know of) for not scaling; of course if you set it up to batter the server with requests every millisecond you can make the server crash (with many concurrent users) or make the browser crash (with an infinite loop of connections opening) or both, but in either case that’s bad craftsmanship

2 Not it does not keep an open socket

3 Yes

4 It works well any browser including IE6 – but some browsers (such as IE6) may experience a bigger slowdown due to larger amounts of JavaScript code (and their memory leaks)

5 IE6

6

• Browsers being open for a long time eat up memory like peanut butter;
• JSON is your friend – build your app with front-end logic in mind, don’t build it with HTML sent over the wire it complicates things (you need to rebind event handlers to every new object received via AJAX, you have little formatting access to a big blog of HTML you just received etc.);
• get the data as JSON, use a front-end template engine such as Mustache.js to compose data using the JSON;

Memory leaks and/or loaded and unused content are normally cleared after a refresh – especially in Chrome – on the other hand Firefox is a real memory muncher, 6-12 hours of having it open even with no activity you’ll see an increase in memory usage.