client/server question.

[Guest]

Hi,

I'm working on a client/server application.
In the current design, a new thread will be spawn, both on server and
client side,
to process every packet received.

As both client and server and client applications will be receiving
thousands of
of packets in any single session, there would be thousands of threads
created
to process the packets and then destroyed. I read in one of the
microsofts article
that this is an extra overhead and hence not recommended.

On the other hand, if we use thread pool, there would be only 25 threads
available to process the thousands of packets received.

In this scenario, what would be the better choise between a thread for a
packet,
thread pool.

kindly let me know. If you need any more information do not hesitate to
contact
me.

Cheers,

Naveen.

 

[Dmytro Lapshyn [MVP]]

Hi,

The thread pool is definitely preferred. There's indeed no use in running
thousands of threads - the context switching overhead will be so big that
you won't gain any performance increase, I'd even say you'll get performance
degrade. Therefore, use the thread pool and make sure the packet processing
is very quick - in this case, the 25 or so working threads should be
efficiently handling the request queue.

Of course I am assuming you have decent hardware - if the workload is
planned to be really high, you might want to consider a multi-CPU system.

 

[Vadym Stetsyak]

if there will be thousands of connections it is better to use threadpool, or
there is also CompletionPort implementation in the internet.

This solution is more scalable than just using thread/connection.
Great number of threads is bad, because not all of them will perform
efficiently...

http://www.codeproject.com/internet/winsockiocp.asp

 

[William Stacey [MVP]]

Why a new thread for each packet? Many times a new thread for each "client"
is very workable, but not a new thread for each packet. Think you need to
expand more on your requirements before we go farther down the road here.
Cheers.

 

[Guest]

Do you expect all 1000 packets to be arriving and processing concurrently? I
would guess no. Try to get a feeling for; 1) the average rate at which
packets arrive, and 2) the average time it takes to process a packet.

Given these figures you can calculate how big a pool you would require such
that there would always be an available thread in the pool to handle an
incoming packet. I'm guessing this will be much less than the thousands of
Thread objects needed to handle all the packets.

-- Tom

 

[Guest]

If the ThreadPool can fulfill your needs, there is no way I would recommend
spawning individual threads.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

Thanks for your response. I will implement thread pools and let you know the
result.