Ticket #539 (enhancement)
Opened 2 years ago
Last modified 1 year ago
Dynamic spare thread creation and destruction
Status: closed (toolfix)
| Reported by: | lawouach | Assigned to: | rdelon |
|---|---|---|---|
| Priority: | low | Milestone: | |
| Component: | CherryPy code | Keywords: | |
| Cc: |
In regards of ticket #497, I was wondering if we should not start considering a way to create new threads when the HTTP server becomes overloaded.
Simply something such as:
* as soon as you reach the limit defined by the deployer server.thread_pool, create half the size of that pool in new threads. * as soon as the number of used threads is below half of the size of the pool, stop half the size of that pool number of threads
That would allow the server to react a bit more dynamically.
Thoughts?
Attachments
Change History
09/02/06 14:51:01: Modified by fumanchu
- summary changed from Dynamic thread creation and destruction to Dynamic spare thread creation and destruction.
03/08/07 11:43:19: Modified by jamwt
- attachment tpool.py added.
03/08/07 11:43:43: Modified by jamwt
Attaching a general thread pool, max/spare setup (ala apache) with growth on demand and gradual decay.
Doesn't do exactly what Lawouach described, but I hadn't read this ticket yet. :-)
03/08/07 11:47:04: Modified by jamwt
Also, it's worth noting, that bit of code was not designed to be thread-safe in the case of multiple threads performing management (i.e., adding jobs, calling tick()) operations on it. It's written with a single-thread "master/dispatcher" model in mind.
10/02/07 11:53:26: Modified by fumanchu
- status changed from new to closed.
- resolution set to toolfix.
Generic Thread Pooling Code