[Chameleon] performance of drawmap.php

bartvde at xs4all.nl bartvde at xs4all.nl
Tue Jun 1 11:11:01 EDT 2004 

Hi Tom,

I just redid your test on my machine with the latest Mapscript/Chameleon
and the difference is stunning. In the owsview client a pan at world view
level takes 7-8 seconds, in Chameleon (OGC sample) it takes 15-16 seconds.
This time does not involve loading the context, purely a pan action.

Paul, there must be something pretty slow in Mapserver WMS client or not?
Or can you think of any other cause for this? Can Daniel provide any
insight into this?

Best regards,
Bart

>
> Hi,
>
> I've found this issue as well, and have conducted numerous experiments
> on server side merging /brokering of WMS layers vs. client side (DHTML).
> I have found a ratio of 3/4:1 for performance, and thus prefer the
> latter approach.  I can send out the experiment document if anyone is
> interested.
>
> ..Tom
>
>> -----Original Message-----
>> From: bartvde at xs4all.nl [mailto:bartvde at xs4all.nl]
>> Sent: Tuesday, June 01, 2004 10:28 AM
>> To: spencer at dmsolutions.ca
>> Cc: chameleon at lists.maptools.org; bartvde at xs4all.nl
>> Subject: Re: [Chameleon] performance of drawmap.php
>>
>>
>> Hi Paul,
>>
>> I had a closer look and ofcourse the biggest difference is
>> that Mapserver WMS client is in between in the case of my
>> drawmap.php call. At least in my situation (all data is
>> served through WMS). I found that this is the biggest
>> performance decline, as I did a test on requesting an image
>> from my application MAP file directly through Mapserver CGI.
>>
>> This process takes 1300 ms. This means that Mapserver WMS
>> client takes about 900 ms in the whole process. This is the
>> case when the Mapserver WMS client has to go through a proxy
>> (I use an external URL in my app MAP file). If I just use
>> localhost in my application MAP file, it all boils down to
>> 833 ms (so around 400 ms overhead for the WMS client).
>>
>> Will it increase my performance and keep my download context
>> functionality alive if I use the following:
>>
>> CONNECTION "http://localhost/...."
>> "wms_onlineresource"	"the external URL which goes through the proxy"
>>
>> ???? Then this would be advisable to use or not?
>>
>> Concluding, the drawmap process only takes an additional
>> overhead of around 100 ms.
>>
>> Your option 1 would not suffice for my applications as mostly
>> I need to combine layers from different WMS servers. And as
>> we can see now, the overhead is not that much in drawmap.php.
>>
>> Any possibility that Mapserver WMS client could get faster?
>> Or is this maximum performance? Maybe Daniel has some
>> thoughts about this?
>>
>> BTW: I don't use simultaneous requests in the web stress tool.
>>
>> Best regards,
>> Bart
>>
>> > Bart,
>> >
>> > good question :)  I still have it on my list to look at
>> this problem.
>> > The differences boil down to:
>> >
>> > The drawmap method does the following:
>> >
>> > 1. start apache process
>> > 2. load php
>> > 3. load mapscript
>> > 4. start session
>> > 5. load map object
>> > 6. execute a bunch of php code
>> > 7. draw map
>> >
>> > The mapserv cgi method does the following
>> >
>> > 1. start apache process
>> > 2. start mapserv cgi
>> > 3. load map object
>> > 4. draw map
>> >
>> > I suspect that the load map and draw map steps are roughly the same
>> > within a couple of milliseconds.  Starting apache and loading
>> > mapsc
> ript/mapserv should be roughly the same.
>> >
>> > So the difference lies in:
>> >
>> > 1. loading php
>> > 2. starting the session
>> > 3. execute a bunch of php code
>> >
>> > The code between loading the map object and actually
>> producing a map
>> > image adds some overhead (but I would be suprised if it is
>> more than
>> > 50 ms).
>> >
>> > Note that if the web stress tool does simulatenous
>> requests, they will
>> > all stall because php does session locking.  I had
>> originally intended
>> > to access the session in some read-only mode that would not
>> lock it,
>> > this is difficult to do because we actually trap drawing errors and
>> > put them into the session so that the user can see why
>> layers failed
>> > to draw.
>> >
>> > The reason why we use drawmap is to delay drawing the map until the
>> > page has started loading.  This increases apparent
>> performance while
>> > decreasing overall performance by requiring a second process to be
>> > started to draw the map.  Because of the session locking,
>> the drawmap
>> > request cannot be performed until after the page has been
>> sent to the
>> > browser and the main thread has exited.  Drawing the map as part of
>> > the execution of the application *could* speed up the final product
>> > significantly, but in general I think it would result in a slower
>> > feeling application, especially if you are using WMS sources.  At
>> > least this way, the page loads reasonably quickly and you are left
>> > waiting for the image.
>> >
>> > Alternatives ...
>> >
>> > 1. add a method of requesting the map directly by giving the
>> > mapdhtmlwidget a mapserv cgi and passing it the path to the map file
>> >
>> > - pros: this is probably the absolute fastest way to get the image
>> > without actually drawing it while the page loads
>> > - cons: this is a security risk because it exposes absolute paths.
>> > There may be some ways to limit the security risk, esp on
>> linux systems
>> >        : lose the ability to provide feedback to the user
>> on why map
>> > draws failed.
>> >
>> > 2. add an attribute that would cause the mapdhtmlwidget to
>> render the
>> > image during execution of the application.  I think most of
>> the code
>> > to support this is in the mapdhtmlwidget, it would just
>> need a bit of
>> > tweaking and a new attribute.
>> > - pros: the overall page load time would probably decrease
>> >        : would maintain the ability to report errors to the user
>> > - cons: the responsi
>> > veness of the application would be worse
>> >
>> > 3. write a stripped down drawmap.php, removing some of the
>> extra code
>> > - pros: maintain existing code in mapdhtmlwidget, maintain
>> > responsiveness of application
>> > - cons: minimal speed benefit likely
>> >
>> > Any comments, discussion and more ideas welcome ...
>> personally, I like
>> > option 1 if security is not an issue (or there are work arounds)
>> >
>> > Cheers,
>> >
>> > Paul
>> >
>> > bartvde at xs4all.nl wrote:
>> >
>> >> Hi list,
>> >>
>> >> I have done a test with the Microsoft Web Stress test tool by
>> >> requesting an image to drawmap.php, and requesting the
>> same image to
>> >> Mapserver CGI directly. I only have one visible layer in my
>> >> application. All tests performed on the server itself
>> (localhost), so
>> >> no network traffic involved.
>> >>
>> >> These are the results:
>> >>
>> >> directly to Mapserver WMS:
>> >> 136 hits in 1 minute: average is 438.86 ms.
>> >>
>> >> using drawmap.php:
>> >> 42 hits in 1 minute: average is 1409.50 ms.
>> >>
>> >> Why is there such a big performance loss in this step?
>> This seems to
>> >> be the largest performance bottleneck in Chameleon.
>> >>
>> >> Best regards,
>> >> Bart
>> >> _______________________________________________
>> >> Chameleon mailing list
>> >> Chameleon at lists.maptools.org
>> >> http://lists.maptools.org/mailman/listinfo/chameleon
>> >>
>> >
>> > --
>> >   -----------------------------------------------------------------
>> > |Paul Spencer                           pspencer at dmsolutions.ca   |
>> > |-----------------------------------------------------------------|
>> > |Applications & Software Development                              |
>> > |DM Solutions Group Inc                 http://www.dmsolutions.ca/|
>> >   -----------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Chameleon mailing list
>> > Chameleon at lists.maptools.org
>> > http://lists.maptools.org/mailman/listinfo/chameleon
>>
>> _______________________________________________
>> Chameleon mailing list
>> Chameleon at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/cha> meleon
>>
>
> _______________________________________________
> Chameleon mailing list
> Chameleon at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/chameleon

More information about the Chameleon mailing list