For us, slow thread creation is more a scalability concern compared with 2.3.3. We have a production setup with 2.3.3 and have to evaluate how 3.X will affect that setup. Specific concerns: 1. We do launch threads. We have to look through all our code to make sure we don't do this anywhere with any frequency because of 3.X's big performance difference. 2. 2.3.3 crashes 5-10 times per day right now. We have recovery time down to about 10 seconds. If we use 3.X, we're hoping it won't crash as often. But if it does crash, 3.X is different in that requests aren't queued while the server is restarting--the user sees an error. How long will 3.X's recovery time be to get up to full speed given that thread startup takes much longer. Yes, we can say "start 50 threads in the beginning", but that still would takes minutes (if my 2-3 second thread startup time is right - I can't remember for sure but think so). 3. If a crazy search engine spider hits us, a worm, we send out our newsletter and a bunch of people start clicking on stuff, or we are mentioned in an online article or press release, we could have a large influx of traffic in a short period of time. If AS3 has to go from 10 active threads handling average traffic to 50 threads, will this work, or will customers see a 30-second timeout? Starting new threads is not only time-consuming in the real-time sense, but it is also CPU-bound and sucking up that resource. 4. Related to #3, I'm not sure how to evaluate what to use for maxthreads with 3.X. With 2.3.3 we have checkstats turned on every 2 minutes. I look through the interval stats periodically. If it looks like we are hitting maxthreads several times a day, I bump it a little. With 3.X this doesn't make sense if the thread startup time is 2-3 seconds. I need to bump maxthreads when the wait time for a thread to start handling a request exceeds 3 seconds. Is that information available? 5. The memory footprint of threads in 3.X is different from 2.3.3 for us because of our large TCL library and the fact that TCL interpreters are not shared. 2.3.3's memory problem is that it leaks, so ends up being quite large after running a long time. We have auto restarts if it gets too big. With 3.X, the initial footprint will be bigger, but I'm hoping that it will be more stable. I'm not at all saying that all these issues aren't manageable - they are. But they do give pause to sites that are running 2.3.3 in a production setup and cannot the time/effort/$$ involved to upgrade all server hardware ahead of time to avoid having to think about how these issues will affect the current production setup. Jim > Since the creation of threads is expensive we have put together a thread > pooling system that lets thread-creating apps use a thread pool. The > problems with creating/deletion of threads, if I understand everyone > correctly, seems to be endemic to applications that need to create and > delete threads themselves. The regular thread model for AOLserver's normal > operation seems to be okay but correct me if I'm totally off-base on that. > > You can find nsthreadpool at aolserver.com in the modules area. > > Kris > > -- > Kriston Rehberg > mailto:[EMAIL PROTECTED] > AOL Technology Development
