using threads in remoting server to cater client requests

Hi All,

I have a remoting server which will cater to the client request in
asynchronous way, and the number of clients can be any,in the
implemention of the remoting server ,i am spawning one thread for each
client request. the server does bit of work before sending the results
to client.

my concern regarding this is ,if for each request one thread is
spawn,then say if there are 26 clients requesting for the same servies
at the same time ,i belive there won't be any problem for 25 clients
(only 25 threads can be run in parallel(switched) in windows one
processor m/c),but the 26th client request will be queued and it has
to wait for the threads to free up.

in this implementation i am not using threadpool ,i am creating threads
by my self.

the problem that i presume is all the subsequent client requests after
25 will be queued,
so can any body suggest any alternative to this approach, bascially i
want the build a scalable system.

Hope i am clear.

Thanks in advance
Deepak

"deepak" <tsdeepak (AT) gmail (DOT) com> wrote in news:1162552343.651743.233860
@e3g2000cwe.googlegroups.com:

so can any body suggest any alternative to this approach, bascially i
want the build a scalable system.

You should host your remoting objects in IIS - and use stateless remoting.

Another option is web services.

Deepak,

And another option is to put a compute grid behind your server. This will
give you a model that can scale to the thousands without bogging down the CPU
that the server is running on.

..NET Grid computing solutions:

Commercial-> Digipede Network (http://www.digipede.net/products/sdk.html)
Free Developer Edition available.

Open Source-> Alchemi (http://www.alchemi.net/)

Kim Greenlee

--
digipede - Many legs make light work.
Grid computing for the real world.
http://www.digipede.net
http://krgreenlee.blogspot.net

Kim Greenlee wrote:

Deepak,

And another option is to put a compute grid behind your server. This will
give you a model that can scale to the thousands without bogging down the CPU
that the server is running on.

.NET Grid computing solutions:

Commercial-> Digipede Network (http://www.digipede.net/products/sdk.html)
Free Developer Edition available.

Open Source-> Alchemi (http://www.alchemi.net/)

How would a grid solution differ from a web farm in terms of
scalability? I would have thought a grid would be a more appropriate
solution for a single task that took a lot of computational power rather
than lots of separate (and unrelated) tasks??? Am I way off base there?

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

Hi James,

The purpose of a web server is to server pages. Studies indicate that if a
user doesn’t get a response back quickly (at most 3 seconds); they lose
interest and will go someplace else. So you really want your web servers to
focus on serving pages to keep your users coming back. As people add more
web applications and web services, the server CPU(s) are busy with
non-web-based work. You can continue to add hardware to your web farms, but
for some companies that isn’t an option. The other thing to consider is how
many machines you really need; you certainly want to have enough processing
power to accommodate peak times, but those machines may be idle far more than
you want them to be. A viable solution to this problem is a compute grid.

We have several customers who have put a compute grid behind their web
servers to improve performance. For example, one of our customers is an
event company and they create a PDF file on-the-fly
(http://www.digipede.net/products/case_pacevents.html.) When they had this
functionality on the web server, the web server’s response time was sluggish
during peak times. Because of the flexibility of a compute grid, the company
was able to create their compute grid using existing machines (that weren’t
in the server room) and move the PDF creation there. Read the case study
because it explains it much better than I am.

As for short running tasks vs. long running tasks. Short running tasks
aren’t a problem unless you get a lot of them. Individually the short tasks
would finish quickly, but when they come in a swarm the processor(s) can
quickly get pegged. Long running tasks become a problem much sooner. I
wouldn’t say that you’re off-base because so much of the literature on grid
computing talks about these long running tasks. But parallelizable work is
parallelizable work, in my mind a short running task is usually best suited
for a thread, unless you are expecting to get a lot of them. Anytime you are
building a concurrent system you need to do performance tests. As I see it
..NET developers currently have two concurrency tools at their disposal:
threads and grid objects. Testing will tell you whether the parallelizable
work can be done on the main machine (using threads) or if your system
performs and scales better by moving that work onto the grid (grid objects.)

I hope that answers your questions and if I missed something please let me
know...it’s after 2am right now. :-)

Kim Greenlee

--
digipede - Many legs make light work.
Grid computing for the real world.
http://www.digipede.net
http://krgreenlee.blogspot.net

Kim Greenlee wrote:

You can continue to add hardware to your web farms, but
for some companies that isn’t an option. The other thing to consider is how
many machines you really need; you certainly want to have enough processing
power to accommodate peak times, but those machines may be idle far more than
you want them to be. A viable solution to this problem is a compute grid.

So basically you're saying the advantage of a computer grid is that it
takes advantage of spare processing power you already have (on existing
workstations in the organization) which can avoid the need to purchase
additional hardware and server OS licenses as is the case with web farms).

I guess that might work for the middle tier (functional layer) of the
web site or web application - I can see you might run into difficulty
trying to have your grid handle requests for standard aspx pages though
(since you've got the AppData folder and web.config files etc. that
participate in the rendering of these pages)... which probably answers
my question - a grid is a viable (and sometimes preferable) alternative
for scaling out the middle tier whereas a web farm is pretty much the
only way of scaling out the UI tier in the solution... As for the
databases, I guess that's another technology again (SANs etc.).

We have several customers who have put a compute grid behind their web
servers to improve performance. For example, one of our customers is an
event company and they create a PDF file on-the-fly
(http://www.digipede.net/products/case_pacevents.html.) When they had this
functionality on the web server, the web server’s response time was sluggish
during peak times. Because of the flexibility of a compute grid, the company
was able to create their compute grid using existing machines (that weren’t
in the server room) and move the PDF creation there. Read the case study
because it explains it much better than I am.

That's cool - good to see a real world example. Looks like the grids
could certainly work well in some situations. Most of the apps I'm
working on are fairly database intensive so the bottleneck would
typically be the databases sitting behind the middle tier - there's very
little work that the middle tier could farm out to machines on a grid
since all of these machines would ultimately need to make request to the
bottleneck/databases.

computing talks about these long running tasks. But parallelizable work is
parallelizable work, in my mind a short running task is usually best suited
for a thread, unless you are expecting to get a lot of them.

I guess - although distributing tasks/work over machines in a grid no
doubt comes with some overhead - and I'm guessing there would be more
overhead involved when the tasks are many and small - in the same way
that there is more overhead when making 10 small requests for 10
datasets over a network vs. making one large request for all 10
datasets... the one request incurs less overhead (which is why n-tier
guys try to minimize round trips to the server). That was kind of what
made me think maybe grids were more appropriate for long running tasks.

building a concurrent system you need to do performance tests. As I see it
.NET developers currently have two concurrency tools at their disposal:
threads and grid objects.

or web farms ;-)

I hope that answers your questions and if I missed something please let me
know...it’s after 2am right now. :-)

No worries, thanks for your time.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net

Deepak, to answer your question, the 25 thread limit you are thinking of is
the default of the limit of the .Net threadpool (per processor). By spawning
your own threads, the 26th request will not be queued. However, depending on
the nature of the work being performed by each thread, you may well see a
degredation in performance as the number of requests increases, and not
necessarily a linear degredation.

I am not sure how applicable this is to your scenario, but I found this
artile to be excellent:
http://www.coversant.net/dotnetnuke/...0/Default.aspx

Maybe it will help.

Dan

"deepak" wrote:

Hi All,

I have a remoting server which will cater to the client request in
asynchronous way, and the number of clients can be any,in the
implemention of the remoting server ,i am spawning one thread for each
client request. the server does bit of work before sending the results
to client.

my concern regarding this is ,if for each request one thread is
spawn,then say if there are 26 clients requesting for the same servies
at the same time ,i belive there won't be any problem for 25 clients
(only 25 threads can be run in parallel(switched) in windows one
processor m/c),but the 26th client request will be queued and it has
to wait for the threads to free up.

in this implementation i am not using threadpool ,i am creating threads
by my self.

the problem that i presume is all the subsequent client requests after
25 will be queued,
so can any body suggest any alternative to this approach, bascially i
want the build a scalable system.

Hope i am clear.

Thanks in advance
Deepak