On Fri, 8 Mar 2002, Joe Cooper wrote: > you need. You may still see performance problems...that many threads > will have a huge overhead on any OS (Linux moreso than some, less than > most).
This is true. Thread-per-connect was one of decisions under the question from the start. But at that time I thought that OS and thread library is right place to fix performance problems with large number of thread. And moreover I was urgently need something to replace squid at that time (at 1999). So, solution was to create as simple code as possible, to be able write and maintain it easily. Need to say that I start to write absolutely new code from the scratch. I hope I'll fix all architectiral bugs sometime. The first fixes in the list: 1) Multithreaded reactor pattern to handle requests - it is written and seems it run. 2) safe string operation (also seems completed) 3) more memory control (memory pool) - seems completed but lack some ideas on how to handle memory shortage. 4) C++ instead of C (if this decision will not conflict with performance) 5) special db code to handle specific requrements (BerkeleyDB is good but it have several problems which is out of my control, GigaBASE is fast, but can SIGSEGV sometimes). Ideas that proved to be right are: 1) threaded code 2) two-level cache 3) single-file storage with ability to work with raw storages 4) modular design + several hooks where modules can change request and reply > > Linux kernel 2.4 and above have no reasonable thread limits that you're > going to hit. I'm guessing you can spawn a few thousand if you want to > (but don't do that--thread overhead would kill you!). > > BTW-The reason it stops working at around 980, is probably because Oops > wants to spawn some number of threads that pushes it over the 1000 > limit. Oops doesn't spawn just one when it runs out of free threads, it > spawns a bunch of them (because spawning threads is expensive, but once > they are running it is relatively cheap). Someone correct me if my > guess is incorrect (I haven't looked at the code--but I know Oops > pre-spawns a pool of threads on startup). Yes, it spawn several threads for it's internal usage (document swapper, disk cleaner,...) and pool of treads to handle requests. Igor Khasilev | PACO Links, igor at paco dot net | ===================================================================== If you would like to unsubscribe from this list send message to [EMAIL PROTECTED] with "unsubscribe oops-eng" in message body. Archive is accessible on http://lists.paco.net/oops-eng/
