Re: Performance Issue with Runtime Image

steve,

> > The test was a simple server that accepts a connection and forks a new
> > Dolphin Process which reads 512 bytes, sends the same 512 bytes back to
> > the client, closes the connection, then dies. Not particularly
> > realistic ;-). The client
>
> Not that unrealistic. this is similar to what I need. I have
> created a buffered work queue and the request comes in, all I do is
> read it in, add it to the queue and go back to waiting for input.
> (Another thread waits for work in queue then processes it)

Ah, yes. Actually that's quite a different architecture, so my comments have
maybe been a bit irrelevant.

If I understand you correctly, that means that you will have one Dolphin
Process dedicated to reading in requests, and that it will finish reading each
request before even accepting the next incoming connection. Similarly you have
one worker Process, which will take a request off the queue, process it, and
send the answer back, before going on to consider the next request. That does
keep the number of Processes under strict control ;-) but you may find that it
limits the degree of concurrency you can support. You may not see any point in
allowing more than one request to be /processed/ at once, but a slow client can
effectively block any other client from making a connection, and then will also
prevent any other request from being processed while your worker Process
attempts to transmit the reply back to it.

Still, that may not be an issue in practise, and anyway it sounds easy for you
to change your architecture should it turn out to be necessary.

I'd be tempted to use a small pool of Processes reading incoming requests, a
similar pool of Processes sending back replies, and a single worker Process
that does the actual thinking. In D5, the I/O Processes would be implemented
entirely as lightweight "threads" inside the Dolphin VM, and would be invisible
to the Windows kernel. The (pseudo-) parallelism between them would be
implemented entirely by Dolphin using the (slow) asynchronous network API. In
D6 if you use the new Sockets package (and if my understanding is correct),
that would end up with a Windows thread permanently allocated to each of the
Processes in the IO pool. Since that pool is of fixed size, so will be the
number of threads -- so there's no problem with the thread number growing out
of control. You would have to do some testing to discover the optimum pool
size (if you think it's worth it at all, that is).


> > I saw one other difference between deployed and IDE execution. On one
> > of the three machines I tried (a Win2K box) running the server in D5
> > IDE worked fine, but when I tried the deployed version, it consistently
> > failed after running for a little while -- the crash dump showed that
> > an accept() operation failed, but Windows reported no error (the error
> > code was zero). That didn't happen at all when running in the IDE. I
> > have no idea what the problem is. FWIW, on a WinXP Pro box, I saw the
> > same problem, but only very occasionally, in both the IDE and deployed.
> > On another (significantly slower) Win2K box, the problem didn't occur
> > at all in either configuration.
>
> That is scary... my client sure would be mad if I delivered that.

I've investigated that a bit more. It turns out that the condition occurs
occasionally in all the D5 configurations I've tried (not sure about the
slowest machine -- it may be timing related). The good news is that it appears
to be easily fixable. It seems that Dolphin is sometimes deciding (for
whatever reason -- maybe Windows is lying to it) that there's an incoming
connection to be processed when there isn't one really. Dolphin attempts to
#accept it, and Windows (obviously) can't supply a corresponding socket, so an
error is triggered. If I put an error handler around #accept that traps
SocketError and ignores it if the #errorCode is zero, then everything seems to
work properly. The client program is unaffected so presumably the server is
not missing incoming connections.

There's discussion thread dating back to 2004-5-22 between Yar Hwee Boon and
Bill Dargel, entitled "subclassResponsibility (#onAsychSocketAccept) error when
unit testing sockets", that sounds as if it might be relevant here too. I'm
not certain, though -- if I were seeing the same scenario as they describe then
I don't think my simple fix would work.


> > However, remember that my test setup was such that the server wasn't
> > seeing a lot of concurrent requests. If the 600 requests per second
> > had come from 600 clients all sending one per second, then the server
> > would have been running an infeasibly high number of OS-threads. A
> > realistic server implementation, based
>
> Would they be OS threads or dolphin processes? Also, there is a way to
> to pool the threads to make this more efficient

They'd be OS threads /and/ Dolphin Processes since (I think) the new VM
dedicates a windows Thread to each Process that issues an overlapped call.
However that would only be a (potential) problem with the simple architecture I
was thinking of where each request is handled in its own Process, the
architecture you are considering (and extensions of it) don't suffer from the
same problem.


> Thanks again for your investigation...Chris where do you work?

You're welcome -- I get curious about things and can't (don't want to!) resist
the temptation to investigate ;-)

Actually, I don't work anywhere at the moment -- I've been taking some time out
to rest and pursue my own projects -- which is why I have time for random
investigations.

Unfortunately for me, the time is fast approaching when I'll have to start
earning my keep again ;-( So (I hope no one minds a small advertisement), if
anyone out there is looking to hire a British Smalltalk/Java/C++ programmer,
then I'd like to hear from you.

-- chris


.

Relevant Pages

  • Re: breaking the model
    ... > The forms data then is in the Request object. ... HTTP Request; in this case, the form POST Request from the Page. ... client and server. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Resolving record with enumerated type
    ... In a CPU BFM package, ... because data goes in two directions (request from the ... from the server to the client), you'll need some way to orchestrate ...
    (comp.lang.vhdl)
  • Re: .Net Scalability problem
    ... LoadRunner will peak out a server with a few virtual users. ... To get an idea of load, ... Fire off the test client and watch the number of ... > So I think that the MTC generate concurrent connection and per ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Connection lost at same time every hour (sometimes)
    ... After making the two following alterations on the server the problem seems ... After analyze your ipconfig on SBS and client, ... Then, other connection is good, ...
    (microsoft.public.windows.server.sbs)
  • Re: server disconnection - very often
    ... Reason of permanent popups is VMware server aplication on clients. ... Run CEICW to configure the network of SBS: ... Two network adapters - manual router connection to broadband ... Uninstall VMware on client. ...
    (microsoft.public.windows.server.sbs)