Windows Service - Suggestions for Installing Multiple Instances

[John]

I currently have a Windows Service that runs Transactions that are very
Processor/Memory Intensive. I have a requirement to deploy multiple
instances of the Web service on the Same server. Each Instance needs to
run in its own process.

My current approach to this is to put all the logic into a separate
"Worker" assembly and install it into the GAC. I'm then going to create
Multiple Windows Services (i.e. MyService1, MyService2 etc..) that each
instantiate "Worker" . I will then have a separate install program for
each Windows Service. (Not exactly elegant)

Any suggestions on this approach?

Is there any Way to have one "codebase" for the Windows Services rather
than having a project for "MyService1", "MYService2" etc..?

Does having the "Worker" assembly in the GAC affect performance at all?

Is there an easy way to install Multiple versions of the same Windows
Service on the Same server (I can't seem to find one)
Thanks in advance !!!

[Nicholas Paldino [.NET/C# MVP]]

John,

See inline:

I currently have a Windows Service that runs Transactions that are very
Processor/Memory Intensive. I have a requirement to deploy multiple
instances of the Web service on the Same server. Each Instance needs to
run in its own process.
If you are exposing web services, why aren't you hosting them in
different applications in IIS?
My current approach to this is to put all the logic into a separate
"Worker" assembly and install it into the GAC. I'm then going to create
Multiple Windows Services (i.e. MyService1, MyService2 etc..) that each
instantiate "Worker" . I will then have a separate install program for
each Windows Service. (Not exactly elegant)

Any suggestions on this approach?
I would look into creating a serviced component and then installing in
COM+. You can opt to have your components run as a service (I believe on
Windows XP and Windows Server 2003), so you wouldn't have to create a new
shell for each instance. You just have to install your component as a
separate COM+ application and let it fly.
Does having the "Worker" assembly in the GAC affect performance at all?

No.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

[Peter Bromberg [C# MVP]]

John,
You could have the same "Codebase" as you describe it provided the
ServiceName property of each is loaded from the app.Config file in an
appSettings Section. This must be different for each service. However, I am
wondering why you really need multiple instances of the same service.
Wouldn't you be able to use one service and have it use some sort of metadata
or a Hashtable of "rules" and multiple threads to perform the different
functions all from one service?
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"John" wrote:

I currently have a Windows Service that runs Transactions that are very
Processor/Memory Intensive. I have a requirement to deploy multiple
instances of the Web service on the Same server. Each Instance needs to
run in its own process.

My current approach to this is to put all the logic into a separate
"Worker" assembly and install it into the GAC. I'm then going to create
Multiple Windows Services (i.e. MyService1, MyService2 etc..) that each
instantiate "Worker" . I will then have a separate install program for
each Windows Service. (Not exactly elegant)

Any suggestions on this approach?

Is there any Way to have one "codebase" for the Windows Services rather
than having a project for "MyService1", "MYService2" etc..?

Does having the "Worker" assembly in the GAC affect performance at all?

Is there an easy way to install Multiple versions of the same Windows
Service on the Same server (I can't seem to find one)
Thanks in advance !!!

[John]

Sorry Nicholas I meant multiple instances of the same WINDOWS SERVICE
not WEB SERVICE.
There is no WEB / IIS component to my application. Would this change
your recommendation? Also the Application is highly multi-threaded.

I've not worked with "ServicedComponent"s before. Is the reason you
recommend this to avoid the Multiple Windows Service code bases &
Install Programs? Or is there another benefit?

Could introducing COM+ application adversely affect performance?

This is an Enterprise wide application that runs 1000's of transactions
daily. Which is why I'm so concerned about performance

[John]

Peter,
The reason for Multiple instances of the same service is for
performance and throughput. Each instance of the Windows service will
run exactly the same set of Transactions/functions. The services pick
up requests that come in through a Message Queue and process them. The
current version of the Windows service is Multithreaded and handles
multiple requests "simultaneously". One problem with the current
version (one Windows Service) is that we are limited to the number of
threads that can run because we run out of addressable memory (each
thread loads many Instances of Excel Emulators etc...) .The thought is
that multiple process will allow us to run more Instances
simultaneously

Thanks For your help!

[Peter Bromberg [C# MVP]]

John,
Ok, well that sounds logical on its face, but I question whether in practice
it would help. After all, you have a fixed amount of addressable memory space
on the machine. If you run more processes as a workaround, would that not
actually take up even more memory from the get-go?
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"John" wrote:

Peter,
The reason for Multiple instances of the same service is for
performance and throughput. Each instance of the Windows service will
run exactly the same set of Transactions/functions. The services pick
up requests that come in through a Message Queue and process them. The
current version of the Windows service is Multithreaded and handles
multiple requests "simultaneously". One problem with the current
version (one Windows Service) is that we are limited to the number of
threads that can run because we run out of addressable memory (each
thread loads many Instances of Excel Emulators etc...) .The thought is
that multiple process will allow us to run more Instances
simultaneously

Thanks For your help!

[John]

I was told that each process would have its own address space and this
would help us avoid the OutOfMemoryException we receive when running
to many threads. If that is not the case then we have less incentive
to have multiple processes running.

Thanks!

[Peter Bromberg [C# MVP]]

I am no expert in this area. There is some useful info on MSDN here:

http://msdn.microsoft.com/library/de...ram_tuning.asp

Also, 64-bit machines / OS are getting pretty cheap these days - and that
can make a big difference, even for 32-bit apps.

Best of luck.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"John" wrote:

I was told that each process would have its own address space and this
would help us avoid the OutOfMemoryException we receive when running
to many threads. If that is not the case then we have less incentive
to have multiple processes running.

Thanks!

[Willy Denoyette [MVP]]

"John" <19*****@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
|I was told that each process would have its own address space and this
| would help us avoid the OutOfMemoryException we receive when running
| to many threads. If that is not the case then we have less incentive
| to have multiple processes running.
|
| Thanks!
|

Running 5 separate processes with each 10 threads or running a single
process with 50 threads will take at least the same amount of physical RAM.
But your problem does not relate to physical memory, it relates to virtual
memory and this will always be a problem if you don't "manage your memory"
consumption. That means that you have to restrict the number of threads,
each thread takes 1MB of stack space, each service runs at least 5 threads
before you even create a thread of your own.
Also don't think that more threads means higher performance, most of the
time it's the inverse.
For IO bound processes you can have some more threads running than for
compute bound process. A golden rule is to have at most 2 compute bound
threads per CPU, and up to 20 IO bound threads per CPU. When your threads
are mixed IO/compute, the number may vary between 2 and 20, depending on the
time spend waiting for IO completion. Note that the above figures are not
carved in stone, they are just an indication based on experience, you should
always measure your throughput/performance.
Another question, did you ever profile your memory consumption, are you sure
you dispose your instances and release all unmanaged resources when done
with them?
What version of the framework and OS are you running, and what's your memory
consumption (managed/unmanaged), do you create large objects? and finally
how many threads do you create?
Willy.

[Nicholas Paldino [.NET/C# MVP]]

John,

Like all things, anything can adversely affect performance if you don't
use it correctly. COM+ is no different. You can't just say "oh, it's going
to affect performance if you use it".

And yes, I recommended them because you can set them up to run as
services.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"John" <19*****@gmail.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...

Sorry Nicholas I meant multiple instances of the same WINDOWS SERVICE
not WEB SERVICE.
There is no WEB / IIS component to my application. Would this change
your recommendation? Also the Application is highly multi-threaded.

I've not worked with "ServicedComponent"s before. Is the reason you
recommend this to avoid the Multiple Windows Service code bases &
Install Programs? Or is there another benefit?

Could introducing COM+ application adversely affect performance?

This is an Enterprise wide application that runs 1000's of transactions
daily. Which is why I'm so concerned about performance

[Li-fan Chen]

Not sure what initiated the thread, but generally you'll want to have a
single Windows Service serving all the jobs. Use a pre-spawned thread pool
(one is provided by the CLR for light work) to dish work to individual
threads. If you anticipate the need for job throttling make the Windows
Service a MSMQ consumer.

The only time you'll have multiple instances is a hot stand-by service
dequeuing the same job queue. Add a watch-dog and it should fire an alarm to
your executive dash-board.

Regards,
-- Li-fan