Troubleshooting a high-load scenario

[Ulf Wiger (AL/EAB)]

I stick to my recommendation.

As a rule, I don't think one gains much by
having messages stay in the socket buffer,
since you can't prioritize them, for example.

It's usually better to have an agent suck the
messages out of the buffer and get them as quickly
as possible to a point where they can be parsed,
tagged and prioritized. Once messages have been
identified and prioritized, effective load 
control can take place.

For example, your bots respond to bet requests,
but could probably dispense with other messages
rather cheaply. The efficiency of the bots will
also increase if they can process more than one
message per time slice. The efficiency of the 
socket reader also increases if it's allowed to
read and dispatch several messages at once.

/Uffe 

> -----Original Message-----
> From: Joel Reymont [mailto:joelr1@REDACTED] 
> Sent: den 17 januari 2006 13:06
> To: Ulf Wiger (AL/EAB)
> Cc: Erlang Questions
> Subject: Re: Troubleshooting a high-load scenario
> 
> The majority of the load originates with the server. It keeps 
> sending moves by other players, table state updates, etc. 
> etc. etc. How does that change your answer?
> 
> On Jan 17, 2006, at 11:57 AM, Ulf Wiger ((AL/EAB)) wrote:
> 
> >
> >> Are you suggesting this _with_ the socket reader waiting for the 
> >> message to be processed before reading the next one?
> >
> > No. That seems a bit like reversed flow control anyway.
> > Do you expect the server to overload the bots?
> > Doesn't the majority of the load originate with the bots?
> >
> > /Uffe
> 
> --
> http://wagerlabs.com/
> 
> 
> 
> 
> 
>