[REBOL] some fixes for fastcgi.dll
From: petr::krenzelok::trz::cz at: 4-Sep-2001 12:43
Hi,
I insert here one email from fastcgi-developers forum. It seems to me,
that problem with pipes seems to be fixed now. If someone manages to
compile/link new .dll from last snapshot, I would not mind :-)
Cheers,
-pekr-
------------------
Hi,
> I don't debug library problems with a Perl application. Use the echox
FCGX
> based program in the examples directory and connect to it with a
debugger
to
> see what its doing when mod_fastcgi seems to be stuck waiting on it.
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
> > For mod_fastcgi I have to change the Makefile.nt to link with the
lib
> > ws2_32.lib and add /I "$(APACHE_SRC_DIR)\os\win32" to the include
> > setting to
> > compile with Apache 1.3.20
>
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