[mapserver-dev] Re: [mapserver-users] Using Fast CGI with MapServer to alleviate poorperformance

Jim Klassen Jim.Klassen at ci.stpaul.mn.us
Wed Sep 17 15:11:49 EDT 2008


This is all from memory so it might be completely off base, but isn't there some way to get around this with HTTP 1.1 and using chunked-encoding?

Anyway, Firebug is claiming that keep-alive was requested and part of the response from my server with Transfer-Encoding: chunked. This is using mode=map on gif, png, and jpeg that I checked.

Jim K

>>> "Paul Ramsey" <pramsey at cleverelephant.ca> 09/17/08 3:03 PM >>>
Just FYI, I poked through some of the code, and we're using external
libraries to do stream-compressing right to stdout for things like WMS
or mode=map, the result being we have no idea what the content-length
is at the time of header writing, and no easy way to change the
procedure.

P

On Wed, Sep 17, 2008 at 11:36 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> Intriguing stuff!
>
> I found this generic-ish article about perl:
> http://www.perlmonks.org/?node_id=83791
>
> The implication is that unless/until Mapserver starts sending
> Content-Length along with returned images, browsers won't do
> keep-alive for us.
>
> More performance!
>
> P.
>
> On Wed, Sep 17, 2008 at 10:26 AM, Jim Klassen
> <Jim.Klassen at ci.stpaul.mn.us> wrote:
>> I have found there is a fairly large overhead inherent in the HTTP request (per tile) especially if the network round trip times are an issue. Using HTTP keep-alive helped a lot with this.
>>
>> Awhile ago we did some tests at the city when we were looking to go to a tiled interface. What we found was along the lines of a 100x100px tile request takes much more than 1/4 of the time of a 200x200px request so the overall map load time was slowed by using more tiles when getting the tiles from mapserver. This would probably be different if we had used a tilecache. In the end we found not tiling (a.k.a. 1 tile per map) worked best for us from a speed/flexibility focus.
>>
>> JimK
>>
>>>>> "Paul Ramsey" <pramsey at cleverelephant.ca> 09/17/08 11:14 AM >>>
>> John,
>>
>> The idea that CGI is naturally a much slower situation than a
>> long-running process is a bit of a red herring in the case of
>> Mapserver, and I say that as someone who is anal retentive about these
>> things.  Unless your Mapserver installation has some naturally latent
>> components (database connections, primarily) you'll find that moving
>> from CGI to FastCGI is worth about 15ms per request.
>>
>> On Wed, Sep 17, 2008 at 8:40 AM, John Westwood <John.Westwood at port.ac.uk> wrote:
>>
>>> The reason I am trying to get MapServer to work with fast_cgi is because I am experiencing poor performance with OpenLayers. I believe that OpenLayers starts a new MapServer instance for each tile request, thus causing an unnecessary overhead. Am I correct?
>>
>> Yes and no. If you are experiencing noticeably poor performance (you
>> can actually *see* it being slow) the only place that the CGI overhead
>> could be the cause is if you're connecting to Oracle or SDE for some
>> of your layers. If that's not the case, look elsewhere first, the very
>> small gains you will receive from moving to FastCGI will not change
>> your underlying problem.
>>
>> Paul
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>>
>>
>



More information about the mapserver-dev mailing list