Board index » delphi » multi-tier DCOM application server

multi-tier DCOM application server

Hi,
    We have a DCOM application server written in Delphi 5 which services n
number of clients. The observation we've made is that

1. When the client application is running on the same box as the DCOM server
the number of threads created by the server process is the same as the
number of clients connected. ie for 40 clients the server process (in NT
Task Manager) shows around 45 threads.

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.

    Due to this there is a noticable decrease in performance given by the
server box (running Windows NT Server) especially when the number of clients
connected concurrently reaches 40 or above. This DCOM application server
connects to an Oracle 8.1.6 database using BDE 5.1.1.1

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?
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).

Thanx in advance for any help possible.....
Regards,
Swapna.

PS: Anyone with a similar large-scale DCOM n-tier Delphi 5 application
servicing multiple concurrent clients please do get back at the earliest.

 

Re:multi-tier DCOM application server


Quote
"Swapna Apte" <swa...@vwebsol.com> wrote in message news:3ad17a27_1@dnews...
> 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...

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... ;-)

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.

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...

Re:multi-tier DCOM application server


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

Quote
"Swapna Apte" <swa...@vwebsol.com> wrote in message news:3ad17a27_1@dnews...

> Hi,
>     We have a DCOM application server written in Delphi 5 which services n
> number of clients. The observation we've made is that

> 1. When the client application is running on the same box as the DCOM
server
> the number of threads created by the server process is the same as the
> number of clients connected. ie for 40 clients the server process (in NT
> Task Manager) shows around 45 threads.

> 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.

>     Due to this there is a noticable decrease in performance given by the
> server box (running Windows NT Server) especially when the number of
clients
> connected concurrently reaches 40 or above. This DCOM application server
> connects to an Oracle 8.1.6 database using BDE 5.1.1.1

> 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?
> 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).

> Thanx in advance for any help possible.....
> Regards,
> Swapna.

> PS: Anyone with a similar large-scale DCOM n-tier Delphi 5 application
> servicing multiple concurrent clients please do get back at the earliest.

Re:multi-tier DCOM application server


Did you set your server up under DCOMCNFG? If so, the Identity setting is
probably "Launching User". If you want to mimize threads, set the Launching
user to either Interactive, or This User. Now, you'll then get one server
for all remote clients. If this doesn't work for you, then you'll need a
thread pooling mechanism such as MTS/COM+.

--
have fun

Binh Ly
www.techvanguards.com

Quote
"Swapna Apte" <swa...@vwebsol.com> wrote in message news:3ad17a27_1@dnews...

> Hi,
>     We have a DCOM application server written in Delphi 5 which services n
> number of clients. The observation we've made is that

> 1. When the client application is running on the same box as the DCOM
server
> the number of threads created by the server process is the same as the
> number of clients connected. ie for 40 clients the server process (in NT
> Task Manager) shows around 45 threads.

> 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.

>     Due to this there is a noticable decrease in performance given by the
> server box (running Windows NT Server) especially when the number of
clients
> connected concurrently reaches 40 or above. This DCOM application server
> connects to an Oracle 8.1.6 database using BDE 5.1.1.1

> 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?
> 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).

> Thanx in advance for any help possible.....
> Regards,
> Swapna.

> PS: Anyone with a similar large-scale DCOM n-tier Delphi 5 application
> servicing multiple concurrent clients please do get back at the earliest.

Re:multi-tier DCOM application server


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...

Other Threads