Squeak async i/o performrance, was Re: HTTP Performance

Bruce ONeel edoneel at sdf.lonestar.org
Thu Nov 20 12:57:39 UTC 2003


Avi Bryant <avi at beta4.com> wrote:

> Like Stephen, I'm intrigued by your 50rps figure for Comanche - that's 
> the number that I always seem to come up with as well.  There *must* be 
> something throttling that, and we need to get to the bottom of it.
> 

Hi,

I poked at this today and I don't quite get the math to work.
I looked at unix Squeak 3.4-1 so that might distort things.

The basis of the clock in interp.c seems to be in milisecs.  I'm
getting idea from comments and the definition of ioiMsecs in 
sqXWindow.c.  So, given that:

checkForInterrupts (interp.c) is called approx every 1000 byte codes
executed.  If it hasn't been 3 milisecs since the last call this
1000 is scalled up.   If it's been more it is scalled down.  We seem
to be trying to check for interrupts every 3 milisecs.  This is
controlled by interruptChecksEveryNms.

Once this happens if it has been 500 milisecs (this seems high)
after the last time we called checkForInterrupts we call
ioProcessEvents().
This comes from the bits in checkForInterrupts()
if (now >= nextPollTick) {
	ioProcessEvents();
	nextPollTick = now + 500;
}

ioProcessEvents (sqXWindow.c)  calls aioPoll.

aioPoll (aio.c) calls select and then calls the aio handler for 
each descriptor which has pending i/o waiting.

sqSocketListenOnPortBacklogSize has set up the socket with a listen
and then enabled an aio handler.

TcpListener has created a socket with a backlog default of 10.

This implies that every 500 milisecs (ie, 2 times per sec) we can 
get 10 accepts for 20 connections per sec when processing
is happening.

On top of that events are polled when we call 
relinquishProcessorForMicroseconds which is called by the idle
process.  This would be called with a wait of 1 milisec 
(1000 microsecs).  I'm not sure how often this is called and it
depends on the load in Squeak as well.

I guess then that the additional 30 connections per sec
would be accepted during the idle process running.

It would seem then that a higher backlog in TcpListener might
give higher connections per second.  If someone has a test bed
set up which shows the 50 connections per sec, what happens if
you doIt

TcpListener backLogSize: 1000

do things work?  Do you get more connections pe sec?  Do things
hang?  

I'm obviously not sure the above is correct.  With luck someone
with a chance of knowing will speak up :-)

cheers

bruce



More information about the Squeak-dev mailing list