Re: Memory Manager Tests - using 512 Threads
- From: "Danijel Tkalcec [RTC]" <dtkalcec@xxxxxxxxxxx>
- Date: Wed, 28 Dec 2005 01:35:06 +0100
"Hannes Danzl[NDD]" wrote:
>> - if you get more throughput with less memory using 16 threads, why would
>> you want to consider even using 512 threads? Does this suggest that
>> somewhere between 1 and 512 threads there is an optimum value?
>
> In a way I'd say yes. What you see is most likely the fact that a default
> non-blocking TCP server hits a limit of connections it can handle. Adding
> more
> processors will push that limit up. This limit is the reason for all high
> performance TCP servers using IOCP which minimizes the use of threads and
> thus
> swtiching time and contention.
I don't quite follow you, Hannes.
I am handling the same number of connections with 16 as with 512 threads, so
I'm not forced to use 512 threads to handle a high number of connections. I
can also use 4 Threads, if I don't want more than 4 remote functions to be
running at the same time.
I'm not talking about 4 working connections, but 4 remote function calls
being executed. Receiving and Sending of data for any number of connections
can be handled from a single thread with non-blocking communication, same as
with IOCP.
The only difference between IOCP and "standard" non-blocking is that IOCP
issues WSARecv calls to check if there is data available for reading, while
non-blocking receives a message from Windows when data has arrived. I doubt
that IOCP would be able to handle a much higher number of requests, using
the same scenario.
Note that I am using the HTTP protocol (adds some overhead to each request),
client is preparing the request by "constructing the object tree" which is
serialized, compressed and encrypted before being sent to the Server. Then,
Server is encryption, decompressing and deserializing received data to
create the same object tree and make it available to all remote functions
being called. Remote functions then construct another object tree, which is
again serialized, compressed an encrypted before being sent back to the
client.
The highest burden on the CPU is not thread-switching, but
compression/decompression, encryption/decryption and object
serialization/deserialization. If thread-switching had big impact, then
using 512 threads istead of 16 would result in a much higher speed
degradation. I'd say that using 30 times more threads (16 vs. 512) would
result in lot more than 9% performance degradation. Remember that my Server
is handling the exact same number of connections with 16 as with 512
threads.
IOCP was designed by Microsoft to make it easier on developers to implement
high-performance Servers using blocking mode. But, you can achieve the same
performance using non-blocking mode, if your design can handle it.
In any case, I'd be happy to test any Client/Server application in my LAN,
doing similar tasks, to make a direct comparison to the RTC SDK.
--
Danijel Tkalcec
http://www.deltasoft.hr/rtc/author.htm
.
- References:
- ANN: Memory Manager Tests - Detailed Results
- From: Danijel Tkalcec [RTC]
- Memory Manager Tests - using 512 Threads
- From: Danijel Tkalcec [RTC]
- Re: Memory Manager Tests - using 512 Threads
- From: Dennis
- Re: Memory Manager Tests - using 512 Threads
- From: Danijel Tkalcec [RTC]
- Re: Memory Manager Tests - using 512 Threads
- From: David J Taylor
- Re: Memory Manager Tests - using 512 Threads
- From: Hannes Danzl[NDD]
- ANN: Memory Manager Tests - Detailed Results
- Prev by Date: Re: Memory Manager Tests - using 512 Threads
- Next by Date: Re: Memory Manager Tests - Detailed Results
- Previous by thread: Re: Memory Manager Tests - using 512 Threads
- Next by thread: Re: Memory Manager Tests - Detailed Results
- Index(es):
Relevant Pages
|