Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #22300

Re: nThreads

Newsgroups comp.lang.java.programmer
Date 2013-02-13 17:27 -0800
References <e8f7a805-da38-4882-8037-2c964982abd1@googlegroups.com> <kfh9p5$ciq$1@dont-email.me> <1mv2pq2irp6wa$.1lqfljcyio53l$.dlg@40tude.net>
Message-ID <677fd91b-c7b4-4065-986f-2e62cd8744ba@googlegroups.com> (permalink)
Subject Re: nThreads
From Lew <lewbloch@gmail.com>

Show all headers | View raw


Joerg Meier wrote:
> markspace wrote:
>> However, 100 to 300 threads is trivial for most modern system.  Since 
>> most tasks will be IO-bound, it make sense to have lots of threads so 
>> some can be running while others wait for data to be returned.  (Sorry 
>> to contradict Mr. Meier but I'm pretty sure he's off base.)  Given a 
> 
> Obviously, you can pretty much have Integer.MAX_VALUE threads if all of
> them are waiting without negatively impacting your waiting performance -
> that's not really a sensible way to look at that question ;)

Perhaps not, but see below.

> I said, and stand by, that context switching is not free and is the cost of
> having too many threads. Threads that sleep or otherwise wait, such as for
> IO, don't typically cause much context switching.

But how "not free" is it? Let's look at your experience in a minute.

> That being said, I would expect the case of 100s of threads waiting for IO
> probably an edge case (for use cases such as web servers), and the majority
> of cases would have IO restricted to a small number of the threads. YMMV.
> 
>> 3000 is probably approaching some sort of upper limit on most "average" 
>> servers.  Don't neglect to measure actual running performance, but I 
>> don't think commodity hardware can handle that many practically.
> 
> We once ran (by accident) something that triggered 100,000 threads (+ GC
> and whatever) on a normal Linux server with a quad core CPU and it still
> worked (although much slower than with the intended 100). As far as I know,
> neither Linux nor the hardware was anything unusual.

The question is how much slower, and whether 1,000 threads would have experienced
a severe slowdown for that setup. Or 10,000.

Quite often resource limits show up as a discontinuity in the scaling graph. Service time 
degrades gracefully up to some n, then catastrophically above that.

In your case there might have been such a knee in that 10^3- 10^4 range. The numbers 
would tell.

And that's the point for the OP. You cannot know ahead of time what the right number is, 
really. You need to measure, under realistic loads. (And be pretty good at simulating "realistic".)

Notice that answers here are in terms of "if you're I/O bound", "if you're waiting", "if this", "if that". 

You need to know which ifs apply to your case.

-- 
Lew

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

nThreads bob smith <bob@coolfone.comze.com> - 2013-02-13 15:25 -0800
  Re: nThreads Joerg Meier <joergmmeier@arcor.de> - 2013-02-14 00:46 +0100
    Re: nThreads Roedy Green <see_website@mindprod.com.invalid> - 2013-02-14 03:43 -0800
    Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 08:56 -0500
  Re: nThreads markspace <markspace@nospam.nospam> - 2013-02-13 16:06 -0800
    Re: nThreads Joerg Meier <joergmmeier@arcor.de> - 2013-02-14 01:46 +0100
      Re: nThreads Lew <lewbloch@gmail.com> - 2013-02-13 17:27 -0800
      Re: nThreads Robert Klemme <shortcutter@googlemail.com> - 2013-02-14 22:19 +0100
      Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 08:59 -0500
  Re: nThreads Roedy Green <see_website@mindprod.com.invalid> - 2013-02-13 18:37 -0800
    Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 09:01 -0500
  Re: nThreads Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-14 07:07 -0400
  Re: nThreads Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-14 09:55 -0800
  Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 08:55 -0500

csiph-web