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

[Steve Lime]

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

Steve

Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937

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