Thanks Howard and Paul<br><br>I think incorporating ArcSDE / FastCGI in the Buildkit for MS4W would be great as this is the only real method of getting it working in a satisfactory manner - speed wise.<br><br>We seem to be bombing out around every 6th or 7th request so within our
wrappers we've allowed it to re run MapServer up to 5 times - not the
best method but should suffice. I guess the fun part now is to see how
we can DEBUG this to find out where the memory issues may lie. Saying
that it may be our configuration of FastCGI / ArcSDE and not MapServer - I'll have to look into this further.<br><br>
We'll definitely pass back our findings regarding the IIS / FastCGI /
ArcSDE / MapServerCGI but will also try everything running on Apache /
Windows to see if that is better.<br>
<br>
Does anyone know of any good process / memory monitoring software to
try and understand where these leaks could be (if they exist)???<br><br>For some background we use the MapServer CGI which is all wrapped up in some C# wrappers that has an XML template (as opposed to an HTML Template) of all the parameters returned by MapServer. We did this for two reasons - simplicity / stability due to the pure speed of the CGI (great being able to test why something hasn't worked if you have the whole query / url string) but also that the CGI is so flexible. We have recently realised that using nquery you can specify lots of layers with their own template and their own query types / to9lerances - we used to query every layer one by one by re running the CGI but when we hit ArcSDE the speed dropped from about 6 seconds (we hit about 30 layers for information) to over 30 hence why we really needed FastCGI. We now hit MapServer with all thirty layers in one go and testing against shape files the results are returned in around a second (from the 6) - we're hoping that ArcSDE should be about 3 seconds.
<br><br>As always - much appreciated<br><br>Regards<br>Mike<br><br><br><br> What we have now done is that is we get an error back when <br><div><span class="gmail_quote">On 21/12/06, <b class="gmail_sendername">Howard Butler
</b> <<a href="mailto:hobu@iastate.edu">hobu@iastate.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Dec 20, 2006, at 5:29 PM, Mike Saunt wrote
<br>><br>> Hi All<br>><br>> Wondering about the users out there who have had experience with<br>> ArcSDE +<br>> FastCGI with IIS or with Apache<br>><br>> We got it all going today which we were very happy about!
<br>><br>> I'm wondering if anyone has experience with the setting up of the<br>> FASTCGI /<br>> IIS - we got there eventually (and we'll document and post our<br>> experiences)<br>> but we're now wondering whether the combination of the three will
<br>> be the<br>> best or whether we should move ArcSDE / FastCGI / MapServer CGI<br>> across onto<br>> Apache - still running on Windows. Bascially FastCGI processes<br>> seem to bomb<br>> out every now and then (says SDE client memory errors, network
<br>> errors) and<br>> I'm wondering whether the FastCGI on IIS is the most stable. When<br>> looking<br>> at the mapserv.exe processes in the Task Manager they increase in<br>> memory<br>> until they drop out.
<br>><br>> There seems to have been alot more experiences of FastCGI on Apache...<br>><br>> Any thoughts / insights appreciated.<br>><br><br>On Dec 20, 2006, at 6:17 PM, Paul Ramsey wrote:<br>> I am pretty sure FastCGI + Apache is the more-tested combination, so
<br>> probably more stable.<br>> Growing processes is Bad News (tm). Mapserv.exe shouldn't be leaking<br>> but perhaps it is. As a stopgap, set your fcgi workers to shut down<br>> after 50 or 100 accesses. That way they shut down cleanly sooner
<br>> rather than nastily later. You'll spawn workers slightly more often,<br>> but the penalty isn't too bad amortized over a few hundred requests.<br><br>Mike,<br><br>I have also had the experience of FastCGI+Apache+SDE hangup and
<br>crash. My experience was on Linux, and<br>while it wasn't always pleasant, the speed improvements were well<br>worth it. I also used Paul's strategy of having<br>FastCGI shutdown the mapserv processes after about 200 requests. Use
<br>a reasonable combination of the<br>number of requests x the number of clients you expect to service to<br>come up with a good number.<br><br>There are many places MapServer could be leaking memory, including in<br>the SDE code. MapServer's natural
<br>environment is not in long-running processes. Another thing to<br>consider is each mapserv.exe will eat a license<br>seat and connection to your SDE server. This may cause problems for<br>other clients you may have connecting
<br>to the server.<br><br>It would be greatly appreciated if you could document your<br>experiences as far as what you had to do to get<br>MapServer + FastCGI running on IIS in a comment on <http://<br><a href="http://mapserver.gis.umn.edu/docs/howto/fastcgi">
mapserver.gis.umn.edu/docs/howto/fastcgi</a>>. I will<br>make sure to incorporate them into the document. If it is<br>straightforward enough, Jeff and I might copy what you<br>did into the Buildkit, so that support for this makes it into MS4W in
<br>a future release.<br><br>Howard<br></blockquote></div><br>