the_drizzle wrote:
You're certainly right about the sockets. There are better ways of doing things, but I'm just trying to write a demo architecture and what I actually use to block and signal threads for the moment doesn't really matter. It's painless to replace sockets with something else later on.
OK. Fair enough.
the_drizzle wrote:
As for polling, I did consider the option (thanks for the tip though). If I poll, at each interval - say 10 seconds - I poll the server for things to do to the client. This method requires sending data across the web, starting an entire apache thread that figures out if there's data for the client by accessing the database, and then sending a response back to the client.
Reading this, I'm not entirely sure you've got a good grip on it.
1) How much data do you really need to send from the client to check for change? Not much. An ID and perhaps a short and simple string at most (unless of course you insist on wrapping it in XML).
2) Apache doesn't allways start another child process or thread (based on version and configuration) at each request. It would be god awful slow at that rate. And besides, Apache isn't going to actually be doing the work itself here.
3) You don't allways have to access the database either. I can think of one or two potential scenarios for caching data (or data structures of some sort) pertinent to the user in particular. Pulling data from cache is allways faster then yanking it from a DB. And you can use another mechanism for maintaining the cache.
4) And likewise the response from the server back to the client: it doesn't have to be huge. If you are
realy, REALY worried about performance....
a) Just send plain strings
b) User innerHTML instead of DOM where possible
That said, the high level algortithm is going to be the same whether you use Sockets or AJAX. Of course tho, the question of threads is moot here as none of the technologies mentioned thus far in this thread are thread capable. The closest you are going to get is to use Javascript with individual timers for various events and a queue (or some other client side mechanism) to make sure those events don't go stupid on you.
the_drizzle wrote:
If I want very fast response times on the client when the server says the client needs to change its display (i.e. poll time of 1 sec) and I have a lot of clients using the site simultaneously, then polling isn't much of an option. I need something much faster than polling. Something like sockets only churns up a thread when it needs to, essentially letting the server decide when the client needs to receive data.
Once again, threads are a dead issue here unless you change platforms.
In terms of the potential performance of an AJAX front end, I wrote a systems monitor that can poll at an interval of 1 second with a response time of well under a half a second (timed by firebug). It's so fast that it runs a graph showing system load with a queue 30 entries deep (it's a very fast JS based graph too). It also has a second display with is essentially the output of ps -aux with only the 10 most cpu intensive apps at any one point. The server is fast enough to parse that output and generate a string that renders as a table in well under .5 seconds. It almost looks like the output of Top, but with color coding to show particularly CPU intensive processes.
Now if there are as many potential users as you say, have you considered the possibility of seperate dedicated AJAX servers? I'm not just pulling this idea out of my arse BTW. I've designed, built, and managed 2 seperate load balanced / fault tolerant clusters. The first being an LVS software cluster that was essentially a Shared Nothing architecture before the term was coined.
I'm saying all this to say that you have to think outside of the box sometimes. AJAX is still new enough that you are swimming into uncharted waters here. Applying a little creativity here can reap huge benefits. I had to! When I got the Turbo Cluster 6 documentation, they (Turbo Linux) had no documentation for running their system behind a firewall because they hadn't yet figured it out! I did it then gave them the answer.
Speed is dependent on you as an individual developer. If you insist on the band wagon and an alphabet soup of six layer deep libraries, your performance will be correspondingly poor.
Now if you insiste on threads, then perhaps you should look at Java. It's a language with native support for threads so perhaps you can use that in a browser.