Socket performance
John M McIntosh
johnmci at smalltalkconsulting.com
Wed Nov 5 18:27:20 UTC 2003
Good morning. When I was writing the open transport socket logic and
doing testing on a 100mbit network where I'd get upwards of 80-90Mbit
saturation I discover that the original model of signaling semaphores
wouldn't work because my test cases uncovered the loss of semaphores.
This was because the original logic had a small table and it was a
counter and an array which wasn't thread safe, draining the array at
the same time an interrupt driven routine deposited a new element
caused interesting side-effects.
The existing model uses two counters and two (what 500 entry?) tables
and the VM switch betweeen them to allow the interrupt driven routines
to deposit new semaphores as it drains the existing table, then
switchs... This seems fairly thread safe? The number I picked was
chosen as about 2 times the highest observed threshold in my 100mb test
environment, say 200+ per second
To have another number means building a new VM and changing that
constant, let's see, yes SemaphoresToSignalSize
Now when do we look at the array and drain it? Well check out
checkForInterrupts
how often this is called is limited by interruptChecksEveryNms (3ms)
but just to make life more interesting I believe on windows a call is
forced every 1ms and usage of delays will force more activity to ensure
Delay waits are accurate to a millisecond or so, depending on the
platform. You'll need to check your platform to confirm expectations.
Mmm I think you need to build a new VM if you want to expose high water
marks for semaphore usage, but I don't think this is the problem.
On Wednesday, November 5, 2003, at 08:20 AM, Stephen Pair wrote:
> In all of the tests that I've seen of Comanche's socket serving
> performance, I've never seen it handle more than 50 incoming requests
> per second, regardless of the CPU (if anyone has observed higher
> performance, please let me know). This makes me think that we may be
> throttled by Squeak VM logic that checks for interrupts (and signals
> external semaphores)...maybe, we're exeeding the size of the
> semaphores to signal buffers. Is there a way that I can play with the
> interval that we check for interrupts without building a new VM?
> Also, is there a way to adjust the size of the semaphoresToSignal
> buffers? And, finally, is there a way to monitor the number of
> semaphores that are being marked for signaling during each cycle (to
> see if we're approaching or exceeding the limit)?
>
> - Stephen
>
>
>
>
--
========================================================================
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===
More information about the Squeak-dev
mailing list
|