2009/12/4 rama <rama.rama_at_tiscali.it>
> Well, probably jsut because is difficult to correctly tune up the number of
> workerthread
> too much will use a lot of resource (and probably you will pay something in
> terms of context switch?)
> too few will cause problem if you have some "long time lasting req" (that
> is my case btw)
>
> Since in my scenario i have FLASH application that issue XML request, and
> need to get an XML response that is generated after
> 1) some heavy math computation
> 2) some even more heavy sql query
> 3) some not really important xml formatting
>
> this will cause (in some request) a max execution time of 250ms (excluding
> network delay, i am talking of math+sql+otherstupidstuff)
> this doesn't mean that with 5 threads i can serve 20req/sec (ideally)?
>
> So, isn't easy to say "if there is noone that use the FLASH shit, just say
> there with 4 thread and doesn't use too much resource because on
> the same server i run other stuff.....if there are 20000 FLASH users, that
> will do 200/req sec, i really need 50 threads"
>
> If i am wrong, and will be better to always have 50 threads instead of a
> variable number, glad to hear what you think about that, since you
> work on the code of FTP and DTP threadpool and probably you have make some
> regression test :)
>
> Tnx
>
>
> Yes your right, its not easy to tune. but :
When the load is low, what harm does many idle threads ?. not much, system
load is low anyhow.
Threadpools should be used as global resources for this to be optimal.
When load spikes, its now things matter. the threads are suddenly needed and
its of interest that they can get their tasks efficiently,and thats not the
case in the auto re sizable pools in that are designed to only be "good"
when its not needed.
To get the best of both, Its possible to have a fixedpool that dont suffer
overhead from anything "extra", that external (threadsafe) logic safely can
resize using poison pills and normal worker creation when the user number
changes etc.
To make it easier to tune and increase overall system efficiency/concurrency
as a bonus, the overall design needs to quite different from what its today.
Temp selector trick being used everywhere is an extreme example of what
makes tuning life hard in real world usage and also is a server
stability/availability risk.
--
regards
gustav trede