Browser too busy, too many messages?

Hi,

I'm studying comet for a stock quotes application.
This is my typical scenario:
- around 10000 channels total
- max 4000 simultaneous users
- peek 200 messages per second
- average 20 subscriptions per user
- peek 10 messages/sec per channel

I implemented a test application, using Jetty continuation
servlet,
dojox.cometd and Ext for a table widget and rendering
effects.
Dojo.cometd is configured for long-polling.
I`m running Firefox 2 on Windows XP and Firebug.
Server is running Windows 2003, Jetty 6.1.5, a single user
is
connected.

It's kind of working, but the browser is hanging a lot.
I tried to comment out the rendering (Ext) but it still
hangs.
In my test the client subscribes 20 channels, and the load
is around
20 messages per second.
Using firebug I see the ajax POST requests, each lasting
for
300-4000ms.
I tried to tweak jetty servlet parameters but I don`t know
exactly
what they mean.
Any tip of how I can profile or test the client side?


I`m also wondering if comet, or at least this transport
type, is
appropriate for my scenario.
I mean, I see a lot of comet demos dealing with chats, but
stock
quotes data flow is very different from chat text flow.
Any opinions?

Thanks,
Danilo


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cometd-dev" group.
To post to this group, send email to cometd-devgooglegroups.com
To unsubscribe from this group, send email to
cometd-dev-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/cometd-dev

Visit the cometd website at http://www.cometd.com/
-~----------~----~----~----~------~----~------~--~---

Hi Matteo,

the behaviour you advocate tends to happen on busy servers
without the
need to explicitly wait for multiple messages to send.

If the server is mostly idle, then the latency between the
dispatch
caused by a message being available to send and the actual
sending of
it is small - thus the message tends to be delivered
individually.

But if the server is busy, that latency increases, so more
messages
are likely to queue waiting.  But so long as the
implementation can
deliver all waiting messages from the one dispatch, then you
get natural
batching and comms efficiency increases as the server gets
loaded
an more laggy.

cheers





Matteo Vaccari wrote:
> Hi all,
> 
> I'm new to this list so I will introduce myself.  I'm a
software
> developer who teaches part time in a college.  One of
my students wrote
> an implementation of Bayeux in Erlang -- you'll hear
from him as soon as
> I convince him to advertise his work. 
> 
> Getting to Danilo's question:
> 
> On 9/19/07, *tuler* <danilo.tulergmail.com
> <mailto:danilo.tulergmail.com>> wrote:
> 
> 
>     It's kind of working, but the browser is hanging a
lot.
>     I tried to comment out the rendering (Ext) but it
still hangs.
>     In my test the client subscribes 20 channels, and
the load is around
>     20 messages per second. 
> 
> 
> My suggestion is to hold messages for each user in a
queue, so that you
> don't even try to deliver them unless a given timeout
has passed since
> the last message.  When the timeout is exceeded, you
send a bunch of
> notifications all together.  This should improve
performance.
> 
> Matteo
> 
> 
> > 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cometd-dev" group.
To post to this group, send email to cometd-devgooglegroups.com
To unsubscribe from this group, send email to
cometd-dev-unsubscribegooglegroups.com
For more options, visit this group at http://grou
ps.google.com/group/cometd-dev

Visit the cometd website at http://www.cometd.com/
-~----------~----~----~----~------~----~------~--~---