Em Tuesday 04 March 2008 18:56:39 [EMAIL PROTECTED] escreveu:
> On Mar 4, 2:12 am, Jorge Godoy <[EMAIL PROTECTED]> wrote:
> > It does require your server to have a lot more of resources, depending on
> > how many simultaneous clients are you willing to support.
>
> More resources than what? polling? I thought Comet was *more*
> efficient than polling.
Why? You have to keep a connection open to be notified of changes. Polling
you open and close connections at specific intervals (e.g. every 10 seconds,
every 1 minute, etc.).
> But Comet *can* and *should* use an event driven server. Otherwise,
I'm not talking about the server. I was talking about the model used on the
client.
> you'd need a separate long running thread for each client. Perhaps
> I'm not clear what you mean by event driven+polling.
You are thinking about one piece of the system. I am talking about the whole
system.
It "doesn't matter" if you have 100 threads or 100 processes: you'll have 100
open connections to your system and possibly to your database for every 100
clients you have. You'll need to take that into account when specifying the
server. How big would your server need to be to handle 1000 simultaneous
connections? And how big would it need to be to handle 1000 connections
polling data every 10 seconds?
The second option requires a smaller server because you will distribute the
load between given interval.
For example:
second 1 -> answer requests from 0-200 and sleep for 5 seconds
second 2 -> answer requests from 200-400 and sleep for 5 seconds
second 3 -> answer requests from 400-600 and sleep for 5 seconds
second 4 -> answer requests from 600-800 and sleep for 5 seconds
second 5 -> answer requests from 800-1000 and sleep for 5 seconds
second 6 -> answer requests from 0-200 and sleep for 5 seconds
second 7 -> answer requests from 200-400 and sleep for 5 seconds
second 8 -> answer requests from 400-600 and sleep for 5 seconds
second 9 -> answer requests from 600-800 and sleep for 5 seconds
second 10 -> answer requests from 800-1000 and sleep for 5 seconds
second 11 -> answer requests from 0-200 and sleep for 5 seconds
second 12 -> answer requests from 200-400 and sleep for 5 seconds
second 13 -> answer requests from 400-600 and sleep for 5 seconds
second 14 -> answer requests from 600-800 and sleep for 5 seconds
second 15 -> answer requests from 800-1000 and sleep for 5 seconds
...
So, instead of handling 1000 requests, you have to deal with 200 simultaneous
requests.
It doesn't matter it you'll have threads assigned to each request or processes
or whatever... You will have to handle them. If your requests / queries
take more time, then you can simply put a longer interval and redistribute
things.
Clients on slow links would be delayed a bit more because they'd need more
time to stablish a new connection, but then they also give you chance of
answering more requests from clients on faster links.
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
