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

Steve Lime steve.lime at dnr.state.mn.us
Mon Jun 16 17:20:56 EDT 2003

Jan's stuff *should* be persistent as long as the mapObj lives. It was
really intended to work within the
typical use context of MapServer- 1 map. The mapObj is not re-usable,
portions are changed as features
are processed (auto styling or labelcache are examples). 4.0 does add a
copy function though. So even
with fast-cgi your connections would even persist for 1 map.

In the big scheme of things reading the mapfile or loading the CGI  is
minimal compared to reading the 
GIS data and rendering it. So while there is some overhead there I
can't imagine you'd save much time
with fast-cgi...


Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155

>>> 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,
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
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
the next few months.

Oracle has a deadly connection overhead.


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
> 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 

More information about the mapserver-dev mailing list