[Chameleon] performance of drawmap.php

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

Continuing the performance discussion ...

HTML compression is not gonna save a lot. My application is around 90 Kb 
without map image, which could in the most efficient form be reduced to 78 
Kb.

Though I see a lot of potential for putting some of the javascript 
functions into js files which can be cached by the browser. The javascript 
is more than 70% of the whole HTML file. As a pure guess I think at least 
50% of this 70% could be "static" js in libraries. Can this be done easily 
Paul, I see you have started this work already with the MapDHTMLWidget? Is 
it your intention to put as much of js code into libraries as possible?

Best regards,
Bart

On Tue, 01 Jun 2004 19:01:15 +0200, Bart van den Eijnden 
<bartvde at xs4all.nl> wrote:

> 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