[Chameleon] performance of drawmap.php

Bart van den Eijnden bartvde at xs4all.nl
Tue Jun 1 13:01:15 EDT 2004 

Hi Paul,

yes the owsclient takes all four layers in 7-8 seconds. If I include 
application loading time the total is around 11 seconds.

Best regards,
Bart

On Tue, 01 Jun 2004 12:01:50 -0400, Paul Spencer <pagameba at magma.ca> wrote:

> Bart,
>
> does the owsview client really get all the layers in 7-8 seconds, or all 
> but 1 layer ... which takes closer to 15 seconds?  Daniel did some work 
> on the WMS client to make it request images in parallel and combine 
> requests for layers coming from the same server if possible.  This 
> should have resulted in it working somewhat faster.  Keep in mind that 
> the start of the drawmap request comes after the chameleon application 
> has finished executing (probably several seconds) whereas owsviewer can 
> start requesting the images immediately.
>
> In version 1.0, there is a mode of operation for the mapdhtmlwidget in 
> cwcjsapi mode that loads the layers into individual DHTML layers.  But 
> we have not implemented anything to output individual DHTML layers 
> requesting the images directly from the WMSs.
>
> There are a lot of complications to doing this :(
>
> Paul
>
> bartvde at xs4all.nl wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> Chameleon mailing list
>> Chameleon at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/chameleon
>>
>



--

More information about the Chameleon mailing list