Printable View
I made the assumption that Win2K Server and IIS 5.0 were both designed to take advantage of dual procs. Maybe I was wrong. :rolleyes:
There are no other programs running on this system and the code we use to test is a simple ASP page that parses delimited files.
Damn this is frustrating. :mad:
Is it parsing the same file? And when parsing, is it writing to that file or another individual file? This could have the effect of serializing all of the threads down onto one processor. Then, because you've possibly halved the bandwidth to that one processor, it will be slower.
I'm not sure what ASP goes through when executing, but I would hope that it is multi-threaded, thus making use of multiple processors.
M
The tests I have been running are parsing the same file so there is no variance in the amount of content of the data. The system actually parses the files, pulls records and then either inserts or updates various databases.
I doubt there is anything wrong with the hardware. It is probably something about the way ASP is accessing the file or possibly the DB access afterward.
Can you watch the Performance Monitor and see if both procs are over 50% utilized? Typically, a single threaded app will show up as 2 procs pegged at 50%. If they peg higher, then the system is just being overworked. If they are both very low, then the software is likely being delayed by disk access or some other hardware event.
M
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).
Maybe you just need more processors. How about a Compaq 8500 ;-)
Seriously, 2000 scales pretty well. I've heard numbers around 80% efficiency up to 4 processors. You machine should not slow by adding a processor. From the earlier post it seemed like this is what was happening. If it is, you have a hardware/driver problem somewhere.
It just occured to me, is the processer the same? Is it the same stepping version? If not, the latest firmware for your box (Version 2001.08.04) addresses mixed stepping cpus.
Just a thought.
I had used Performance Monitor to view the proc usage during the parsing routine. Like I posted earlier, the results varied. One test, the first proc ran at 60% util and the second at 40%, while another test (on the same data) the first proc ran at 80% util and the second at 20%. As for the processors themselves, they are identical.
etaerine, I will try your suggestion about duplicating the page and data. I'll post the results once I've had a chance to test.
uugghhhh.....Monday morning. Need coffee...