Re: singlethreaded or multithreaded

Hi,

Actualy I have been working a lot in that area recently, in wap. Kannel has 
a static thread structure, from beginning to end. The threads (22 for 
bearerbox, 18 for wapbox) serve to connect and move data between queues. 
The input/output character is single threaded in wapbox/bearerbox.

I have implemended dynamic threads to the outgoing wap interface. 
Performance is not that much improved by it, if accessing from within the 
LAN, in fact threads will introduce some overhead due to thread manager and 
scheduling, and might run slightly slower. What threads do is make for a 
more robust software.

Having introduced a 10" delay, as in real networks, between transmit and 
receive threads, wapbox can handle as many as 3 simultaneous users before 
timing out (>30" delay). The threaded design can handle thousands of 
simultaneous users with the same baseline delay of 10" each.

It is quite easy to find for yourself the smsbox character. Start top and 
watch the number of threads. Generate some load, and if the character is 
multithreaded, you will see threads increasing. Else it is sequential in 
character.

BR,
Nikos
----- Original Message ----- 
From: "Guillaume Cottenceau" <[email protected]>
To: "Stipe Tolj" <[email protected]>
Cc: "devel Devel" <[email protected]>
Sent: Wednesday, May 06, 2009 7:28 PM
Subject: Re: singlethreaded or multithreaded


> Stipe Tolj <st 'at' tolj.org> writes:
>
>> The HTTP client layer in gwlib/http.[ch] works this way:
>>
>> We look for a connection to the target host in our connection pool. If we 
>> have
>> one in the pool we grep it and use it, if we don't have one, we create a 
>> TCP
>> connection to the host.
>>
>> As soon as the request/response transaction is finished, and we run in
>> Keep-Alive mode (HTTP/1.1) we will put the connection back to the pool.
>>
>> Well, what does that mean? we create as man connections (there is no hard 
>> limit
>> per host target), as the re-cycling of the connection is put back into 
>> the pool.
>>
>> This is a pretty hard way to hit the HTTP server. We get a lot of 
>> complains that
>> we break HTTP servers by hitting it too hard ;)
>
> Actually, the parallelization achieved is quite very good, and
> adding the power of C and pthreads it allows a very good
> performance, seemingly.
>
> In my company, we use the tomcat java web application server,
> backed by a postgresql database. Once upon a time, we decided to
> ask for as many DLRs as operators/kannel could produce, and it
> ended up in "breaking" tomcat within a few years during a DLR
> peak time, because each DLR would produce a synchronous database
> request in our application.
>
> So I quickly redesigned that for a production/consumer FIFO queue
> optimized for fast production in our java application, with only
> one consumer thread performing the actual DLR processing
> involving the database query, and it is now entirely fine. In
> other words, the bottleneck was in our bad software design, and
> database performance, that the HTTP server itself (yet, it's
> written in pure java).
>
> In production, IIRC I have seen as many as hundreds of DLRs
> received from a single SMSC link per second (even if operators
> would never accept as many submitted SMS's per second as that,
> but that's a different story), an amount kannel was totally fine
> with (on a midprice dell xeon server several years old) - and
> also tomcat.
>
> -- 
> Guillaume Cottenceau
>