This is for clarification. Someone raised the question of how Windows assigns work to the processors in a multiprocessor configured system. Windows will assign a thread to a processor if the processor is available and the thread is ready to run, unless the thread has a processor affinity set for another processor, and it is set so high that Windows will actually hold the thread until the processor it wants to run on is ready. The only reason I can think you might want to do this is for synchronization, but there's no reason to use processor affinity if you know how to use mutexes and waits. Assigning a process a specific cpu probably limits all of its threads to that cpu as well, so you probably don't want to even touch this setting on a multithreaded application like IIS.

Which brings us to the second point. IIS is multithreaded, and it runs approximately 7 threads on a single proc machine (I think 8 on a multiproc). Logic would say two of those threads are for the backend work in IIS like interpreting and running ASP since you now have two processors to do this on, and the rest are for accepting requests and spewing pages. The threads that do the ASP work are your bottleneck, as well as the single file input. Here's a simple test, if you can swing it. Copy the ASP to another asp page and copy the input file as well. Tell the second asp page to use the second input file. Then send two simultaneous requests for the two pages and watch the cpu utilization. If one cpu is used, then the ASP engine is single-threaded and this is a design flaw on Microsquiggly's part. If both cpus spin like they should, then perhaps your single input file is the bottleneck. I'd say take out the database dependency, but if it's a single-threaded ASP engine you've got there then the database dependency could very well help you identify it (since the database operation would have to complete for the first request before it could even start on the second request).