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
> In what way min max mighty stuff ?.
> its costly stuff, it costs concurrency.
> Peoples "need" for such things is based on what ?, it severely limits the throughput of many threads and short jobs.