thank you all for the inputs!

xox bea

-------- Original-Nachricht --------
> Datum: Thu, 7 May 2009 07:03:05 +0300
> Von: "Nikos Balkanas" <[email protected]>
> An: "Stipe Tolj" <[email protected]>, "Guillaume Cottenceau" <[email protected]>
> CC: devel Devel <[email protected]>
> Betreff: 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
> > 
> 

-- 
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss 
für nur 17,95 Euro/mtl.!* 
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a

Reply via email to