optimization

[boice tomlin]

Hi Steve,

I've rebuilt mapserver with the debug option and copied the new  
php_mapscript.so over.

And I've added the debug option in the map file as well.

no luck.

I see this in my configure log.

configure:10254: checking whether we should enable debug features...
configure:10271: result:         Enabling debug features: -g in  
CFLAGS and msDebug() to stderr (-DENABLE_STDERR_DEBUG).

I checked all of my PHP and apache logs and don't see anything.  Do  
you see anything I missed?

thanks,

boice





>
> 2) build mapserver with the debug option in ./configure
>    then add DEBUG TRUE to the map section of you mapfile
>    then render you map and look in /var/log/apache/error.log
>    and you will fine information about how long it takes each layer
>    to render. do this at the various scales you use.
>    if you have huge shapefiles and you are only rendering parts of  
> them
>    then consider using shape2tile to break the data into tiles.





> 3) optimize the slow layers
>    a) reduce the amount of data you are displaying
>       maybe turn off that layer at that scale
>       create a generalize version of that layer for that scale
>    b) reduce the number of labels if you label cache time is large
>       turn off some of the labels you are drawing at that scale
>
> 4) if it is a raster layer that is slow, then post a message asking
>    Frank Warmerdam or Ed McNierney for suggestions on how to improve
>    your reaster performance
>
> 5) if I haven't covered it here or you are sure what to do about a  
> specific performance issue, post a more specific question.
>
> 6) oh yeah, if you are using shapefiles and have problems rendering  
> data mvoing to postgres will generally not help you.
>
> -Steve W
>
> boice tomlin wrote:
>> Hello users,
>> The map located here;
>> http://gisinventory.net/status_maps.html
>> takes a while to load.  At least at the national view where there  
>> is a lot of area to render.
>> I am looking for alternative ways to generate the map that will  
>> significantly improve performance.
>> Currently I am using php and looping through data and turning on  
>> layers as I go.  The PHP part is lightning fast.  But after I get  
>> the map ready mapserver takes several seconds to generate it.
>> I'm curious about alternative ways to handle this problem and  
>> wonder if anyone had comments on any of them.
>> 1) modifying the shape files in some way so the layer information  
>> is in those files.
>> 2) using a db such as postgres with postgis.
>> Right now I have to generate a bunch of dynamic classes in PHP  
>> using the general method below.
>> $lyr = $this->ramona_map->getLayerByName("state_yes");
>>                 $cla = $lyr->getClass(0);
>>                 $cla->setExpression("/".$expression."/");
>>                 $lyr->set("status", MS_ON);
>> I have to do this several hundred times to represent all of the  
>> data.  The time it takes to generate the map seem proportionate to  
>> the amount of layers I make visible.  And again this is on the  
>> mapserver side and not PHP.  PHP does its part of the operation in  
>> thousandths of a second.
>> thanks,
>> -boice tomlin
>> ////////////////////////////
>> Run Skip
>> http://runskip.com <http://runskip.com/> /
>> boice tomlin
>> boice at runskip.com <mailto:boice at runskip.com>
>> 503-528-6204
>> ////////////////////////////
>> Run Skip
>> http://runskip.com/
>> boice tomlin
>> boice at runskip.com <mailto:boice at runskip.com>
>> 503-528-6204
>




////////////////////////////
Run Skip
http://runskip.com/

boice tomlin

boice at runskip.com

503-528-6204


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20061206/d617ba18/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20061206/d617ba18/attachment.sig>