From: "Johan Otto" <johan.o...@ixchange.com>
From: "Alessandro Federici" <a...@bigfoot.com>
I suggest you revise the server object's threading models
Apartment threading is advised when using BDE
Single/Multiple instance is up to the kind of application your developing
##
I have a Multi Instance and tmApartment threaded DCOM Application server on
which i was trying a multi-user load test.
##
Quote
> 2. When the client application is running on some other box in the same or
> different domain of the network the number of threads created by the
server
> process is exactly double the number of clients connected. ie. for 40
> clients the server process (in NT Task Manager) shows around 85 threads.
Interesting. Makes some sense actually.
The first thing I am thinking of are the stub that get generated on the
server to handle communication but I never really checked.
The thing that surprises me is the approach you are using: why are you
keeping the DCOM and database connections open?
You should use a stateless model. Much more scalable that what it looks you
are doing... Even if you solve your issue with the small number of clients
you have, when you need serious load this thing is not probabily gonna work
that well unless you cluster it but even then, it would only mean getting
around the real problem...
##
i AM using the stateless model for my application as i've said above. When i
say 40 simultaneous connections these will all be disconnected as soon as
the required processing is complete. I'll try and research the stub theory
some more too....
##
Quote
> This DCOM application server connects to an Oracle 8.1.6 database using
BDE 5.1.1.1
mmhhh.... mmmhhh... ;-) puff puff, yack yack... ;-)
##
sorry me no comprendo...? Is this combination that bad?
##
Quote
> My queries:
> 1. Why should this be the case of doubling the number of threads on the
> server? Is it a problem with Delphi's implementation of DCOM or Windows NT
> itself?
If my theory is right, is just normal.
Quote
> 2. Any tips or suggestions on improving or optimizing performance for more
> than 40 concurrent DCOM connections (ie. server process having double the
> number of threads).
Use a disconnected approach. The is the best reccomendation I can make.
Object pooling is another possible solution but you are not using COM+.
There's an article on www.distribucon.com that may give you some ideas.
##
i really couldn't locate anything very resourceful, please could u point me
to a more specific article please :).
##
Quote
> PS: Anyone with a similar large-scale DCOM n-tier Delphi 5 application
> servicing multiple concurrent clients please do get back at the earliest.
Tell me more about what you are doing...
