[mapguide-users] RE: Studio Enterprise and Web Studio Cannot Connect Randomly

[Jason Birch]

Yes, setting StartServers = 4, MaxServers = 4 seems to have at least reduced considerably (I haven't seen one yet) the connection errors.  At least, unless I do something stupid like killing a mapagent.exe process manually...
 
I just went back to my server after a couple hours of quiet time, and all of the MapAgent processes had died off and I had a pop-up error message about the IIS worker process being killed.  In the event log there's a message "Reporting queued error: faulting application w3wp.exe, version 6.0.3790.1830, faulting module isapi_fcgi.dll, version 0.0.0.0, fault address 0x000042c0."
 
This doesn't seem to have had an effect on the application though; I didn't get an FCGI connection error when loading my test page.
 
Jason

________________________________

From: Trevor Wekel [mailto:trevor.wekel at autodesk.com]
Sent: Thu 2006-11-16 4:31 PM
To: Jason Birch; users at mapguide.osgeo.org
Subject: RE: [mapguide-users] RE: Studio Enterprise and Web Studio Cannot Connect Randomly


Hi Jason,
 
Does setting StartServers = MaxServers eliminate the connection errors?
 
Here's some more background on the IIS FastCGI extension.  Isapi_fcgi.dll does recycle the processes.  Memory leaks will accumulate for a while but resource consuming php-cgi.exe and mapagent.exe processes should drop off after a while.  The only catch is that isapi_fcgi gives no control over how long the processes should stay alive.  For PHP, setting the following environment variables may help roll the processes a little quicker:
 
PHP_FCGI_MAX_REQUESTS=500
PHP_FCGI_CHILDREN=1
 
These can be set by adding a registry setting under FASTCGI/.php
Environment REG_BINARY (0x0D delimited set of environment variables, terminated with 0x00)
 
eg.  PHP_FCGI_MAX_REQUESTS=500 0x0D PHP_FCGI_CHILDREN=1 0x0D 0x00
 
Thanks,
Trevor
 

________________________________

From: Jason Birch [mailto:Jason.Birch at nanaimo.ca] 
Sent: Thursday, November 16, 2006 5:12 PM
To: users at mapguide.osgeo.org
Cc: Trevor Wekel
Subject: RE: [mapguide-users] RE: Studio Enterprise and Web Studio Cannot Connect Randomly


For anyone who's keeping track...
 
Setting the StartServers to a higher number did not seem to help me.
 
What has seemed to help was setting the StartServers and MaxServers to the same number.  I guess this is OK if you're not worried about memory leaks or dynamic resource allocation on your server.
 
It looks to me like any time a MapAgent child process is killed on Windows, the FastCGI ISAPI handler doesn't get informed about it, and the first request fails. If you restart IIS after killing a process, you don't get the error; a new process is just started up.
 
Jason

________________________________

From: Jason Birch [mailto:Jason.Birch at nanaimo.ca] 
Sent: Wednesday, November 15, 2006 12:41
To: users at mapguide.osgeo.org
Cc: Trevor Wekel
Subject: RE: [mapguide-users] RE: Studio Enterprise and Web Studio Cannot Connect Randomly


Thanks, I'll give that a try.
 
Apparently these can be set on a per-service level, under
 
HKEY_LOCAL_MACHINE\SOFTWARE\FASTCGI\.fcgi
 
And there is an "Environment" setting.  Maybe this could be used to overcome the problem with the PROJ_LIB variable not getting picked up?
 
http://viewcvs.php.net/viewvc.cgi/fastcgi-isapi/readme.txt?view=markup
 
Jason

________________________________

From: Trevor Wekel
Subject: RE: [mapguide-users] RE: Studio Enterprise and Web Studio Cannot Connect Randomly


Hi Jason,
 
Telling isapi_fcgi and mod_fastcgi to spin up two servers might help but I've had trouble forcing them to spin up agents.  mod_fastcgi is especially obstinate.  Even under load it doesn't like to spin up more than one agent.  Here are the appropriate settings:
 
For IIS:
 
Increase the registry setting HKEY_LOCAL_MACHINE\SOFTWARE\FASTCGI
StartServers REG_DWORD 1 
 
 
For Apache, modify httpd.conf and increase -minProcesses:
 
Change
 
FastCgiConfig -idle-timeout 120 -minProcesses 1 -maxClassProcesses 4 -multiThreshold 100 -singleThreshold 100 -killInterval 600
 
to
 
FastCgiConfig -idle-timeout 120 -minProcesses 2 -maxClassProcesses 4 -multiThreshold 100 -singleThreshold 100 -killInterval 600
 

Note:  PHP uses a different configuration line and should already be spinning up 4 processes:
 
FastCgiServer "C:/Program Files/MapGuideOpenSource/WebServerExtensions/php/php-cgi.exe" -processes 4 -idle-timeout 120 -
initial-env PHP_FCGI_MAX_REQUESTS=500 -initial-env PHP_FCGI_CHILDREN=1^M