some fixes for fastcgi.dll

FCGX

debugger to

So I start with echo-x.exe and run ab with concurrency = 20 and the first thing I noticed is that my NT was unuseable while the test runs. The load goes up to 100% and even displaying the task manager took about 20 secs, but a request was only serviced every 4 seconds :-( I started debugging this and came to the WaitNamedPipe call in the open_connection_to_fs function. The function always fails with "File not found" and therefore causes an endless loop which generates the high load. The reason for the file not found, is that it gets an invalid path, something like \\.\pipe\FastCGI\/cf04a12ed0cddede6790a861aaaa04ad you see the forward slash before the hash value. A forward slash is not allowed in a win32 filename. After doing some more searching, I found that this slash comes from ap_make_full_path. Apache uses internaly only the forward slash as path separator. The OS dependend functions converts it to the right format. Since mod_fastcgi accesses the win32 API directly, it has to use the backslashs in filenames, but Apache and therefore ap_make_full_path is not aware of backslashes and still uses the forward slash. The solution is to replace the ap_make_full_path function for win32 with a slightly modified one, which makes sure all path separators are backslashs. After I have dones this, everything works fine. The load has gone down to a normal level. The next step was to test it against my Perl application and now this also runs without problems :-) There is one thing I noticed: To make some more stress testing I have made the Perl application so, that it exits after 3 requests. Now the process manager seem to get in trouble when the -maxProcesses is too low. It was 3 in my case, but the cocurrency level of ab was 5. So there are more coccurenty request, then fcgi servers. This shouldn't be a problem normaly, but in my case sometimes the process manager seems to kill fcgi server processes to keep the max limit, also the other processes had terminated by itself, so the overall number of processes went to zero. Processes that are started, just directly exited without waiting for a new request. This isn't a problem for me at the moment, because my app isn't so highly loaded, but seems to be something that should be fixed in the future. I append the patch for the new make_full_path function on win32. Gerald P.S. There is one change in the Makefile.nt I forgot to mention in my last email

lib

The ApacheCore.lib, doesn't reside anymore in CoreR/CoreD, but in Release/Debug directories, therfore mod_fastcgi must be linked agianst $(APACHE_SRC_DIR)\Release\ApacheCore.lib and $(APACHE_SRC_DIR)\Debug\ApacheCore.lib Note: These directory changes are apply to Apache 1.3.20, earlier versions of Apache still have the layout, as it is in the Makefile.nt that comes with the last snapshot. Addtionaly I had to convert all /ZI to /Zi, because /ZI isn't know in VC++5 and I still have to use VC++5. Maybe it's a good idea to distribute with /Zi switch, because that compiles with VC++5 and VC++6, while the /ZI switch only works with VC++6. I append my new Makefile.nt for convenience ------------------------------------------------------------- Gerald Richter ecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [richter--ecos--de] Voice: +49 6133 925131 WWW: http://www.ecos.de Fax: +49 6133 925152