From: Terje Eggestad <terje.eggestad@scali.com>
To: Lee Chin <leechin@mail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-newbie@vger.kernel.org
Subject: Re: debate on 700 threads vs asynchronous code
Date: 30 Jan 2003 10:36:24 +0100 [thread overview]
Message-ID: <1043919384.857.3.camel@pc-16.office.scali.no> (raw)
In-Reply-To: <20030129172631.29782.qmail@mail.com>
On ons, 2003-01-29 at 18:26, Lee Chin wrote:
> Today I do method (C)... but many people seem to say that, hey,
> pthreads does almost just that with a constant memory overhead of
> remembering the stack per blocking thread... so there is no time
> difference, just that pthreads consumes slightly more memory. That is
> the issue I am trying to get my head around.
>
> That particular question, no one has answered... in Linux, the
> scheduler will not go around crazy trying to schedule prcosses that
> are all waiting on IO. NOw the only time I see a degrade in threads
> would be if all are runnable.... in that case a async scheme with two
> threads would let each task run to completion, not thrashing the
> kernel. Is that correct to say?
Yes
And you can add that if you have many runnable threads, there will be an
extra overhead doing context switching.
> ----- Original Message -----
> From: Terje Eggestad <terje.eggestad@scali.com>
> Date: 27 Jan 2003 10:48:22 +0100
> To: Lee Chin <leechin@mail.com>
> Subject: Re: debate on 700 threads vs asynchronous code
>
> > Apart from the argument already given on other replies, you should
> > keep in mind that you probably need to give priority to doing receive.
> > THat include your clients, but if you don't you run into the risk of
> > significantly limiting your bandwidth since the send queues around your
> > system fill up.
> >
> > Try doing that with threads.
> >
> >
> > Actually I would recommend the approach c)
> >
> > c) Write an asynchronous system with only 2 or three threads where I
> > manage the connections and keep the state of each connection in a data
> > structure.
> >
> >
> > On fre, 2003-01-24 at 00:19, Lee Chin wrote:
> > > Hi
> > > I am discussing with a few people on different approaches to solving a scale problem I am having, and have gotten vastly different views
> > >
> > > In a nutshell, as far as this debate is concerned, I can say I am writing a web server.
> > >
> > > Now, to cater to 700 clients, I can
> > > a) launch 700 threads that each block on I/O to disk and to the client (in reading and writing on the socket)
> > >
> > > OR
> > >
> > > b) Write an asycnhrounous system with only 2 or three threads where I manage the connections and stack (via setcontext swapcontext etc), which is progromatically a little harder
> > >
> > > Which way will yeild me better performance, considerng both approaches are implemented optimally?
> > >
> > > Thanks
> > > Lee
> > --
> > _________________________________________________________________________
> >
> > Terje Eggestad mailto:terje.eggestad@scali.no
> > Scali Scalable Linux Systems http://www.scali.com
> >
> > Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE)
> > P.O.Box 150, Oppsal +47 975 31 574 (MOBILE)
> > N-0619 Oslo fax: +47 22 62 89 51
> > NORWAY
> > _________________________________________________________________________
> >
--
_________________________________________________________________________
Terje Eggestad mailto:terje.eggestad@scali.no
Scali Scalable Linux Systems http://www.scali.com
Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal +47 975 31 574 (MOBILE)
N-0619 Oslo fax: +47 22 62 89 51
NORWAY
_________________________________________________________________________
next prev parent reply other threads:[~2003-01-30 9:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-29 17:26 Lee Chin
2003-01-30 9:36 ` Terje Eggestad [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-01-29 21:32 Dan Kegel
[not found] <Pine.LNX.4.44.0301241840450.11758-100000@coffee.psychology.mcmaster.ca>
2003-01-25 0:24 ` Dan Kegel
[not found] <Pine.LNX.4.44.0301232144470.8203-100000@coffee.psychology.mcmaster.ca>
2003-01-24 8:21 ` Dan Kegel
2003-01-24 8:26 ` Mark Mielke
2003-01-24 22:53 ` Corey Minyard
2003-01-24 23:21 ` Matti Aarnio
2003-01-24 23:29 ` Randy.Dunlap
2003-01-25 0:11 ` Dan Kegel
[not found] <Pine.LNX.4.44.0301232028480.980-100000@coffee.psychology.mcmaster.ca>
2003-01-24 2:04 ` Dan Kegel
2003-01-24 1:46 Dan Kegel
2003-01-24 0:07 Lee Chin
2003-01-23 23:19 Lee Chin
2003-01-23 23:28 ` Larry McVoy
2003-01-23 23:31 ` Ben Greear
2003-01-27 9:48 ` Terje Eggestad
2003-01-27 21:48 ` Bill Davidsen
2003-01-27 22:08 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1043919384.857.3.camel@pc-16.office.scali.no \
--to=terje.eggestad@scali.com \
--cc=leechin@mail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-newbie@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®