[Mapserver-dev] Re: [mapserver-users] fastcgi?

[Steve Lime]

BTW The Oracle folks from Brazil are largely AWOL. The folks from the
Army Corps
of Engineers have also volunteered to take the Oracle Spatial code
over. Don't care
who does it, but I'm glad there are a couple of takers...

Steve

>>> Paul Ramsey <pramsey at refractions.net> 06/16/03 01:06PM >>>
I think the connection pooling issues get a little fiddlier in the
FastCGI case. It depends on whether Jan's pooler is per-map-request or
per-session. In the case of ordinary CGI, 1 session == 1 map request,
so
the cases are identical. In the case of FastCGI, 1 session == X map
requests. Probably this is just one of the things to keep track of
while
writing the FastCGI loop. DB connections (and OGR/GDAL) should not be
closed until the end of the sesssion.

If the Oracle developers are AWOL, we will take on the Oracle Spatial 
maintenance, as we have a substantial amount of Oracle Spatial work
over 
the next few months.

Oracle has a deadly connection overhead.

P.

Frank Warmerdam wrote:
> Jan Hartmann wrote
>> 
>> Great that you are going to do FastCGI support! Regarding database 
>> connections, would you take care of the connection pooling that I 
>> implemented a few months ago? Steve Lime has already put it to work
>> for SDE, and doing the same for PostGIS would be half an hour's
>> work. I'm not sure about Oracle; didn't understand much of how it
>> connected to MapServer. Please let me know if I can do something on
>> that.
> 
> Jan,
> 
> I have taken the liberty of replying mapserver-dev instead of users
> as this is mostly a new development issue.
> 
> I am not prepared at this time to commit to modifying the Oracle or
> PostGIS support to use the connection pooling.  I hadn't realized
> that the Oracle didn't already use it.   Are the Oracle connector
> developers interested in implementing that?
> 
> For PostGIS, I think the connection setup cost is substantially
> smaller than for Oracle or SDE, so it isn't so important.  But if it
> is to be done, it should be done by Refractions since they are
> actively maintaining this component.
> 
> I must admit my main reason for wanting FastCGI support is to ensure
> the best performance for FMEObjects based map serving, and I am
> hesitant to grow the scope of my short term effort too much.
> 
>> Am I right that FastCGI would make it possible not only to pool 
>> connections for one MapFile, but also for a complete session? That
>> would be great!
> 
> Right.  My understanding is that FastCGI will startup one or a few
> long running mapserv daemons and that if the code is structured
> properly initialization costs for database connections and other
> things can just be done once on first use and reused for as long as
> the daemon stays alive.
> 
> Note, I have never used FastCGI before.  I am basing my
understanding
> so far on a quick review of the documents at www.fastcgi.com.
> 
> Best regards,
> 


-- 
       __
      /
      | Paul Ramsey
      | Refractions Research
      | Email: pramsey at refractions.net 
      | Phone: (250) 885-0632
      \_

_______________________________________________
Mapserver-dev mailing list
Mapserver-dev at lists.gis.umn.edu 
http://lists.gis.umn.edu/mailman/listinfo/mapserver-dev