[Chameleon] performance of drawmap.php
Kralidis,Tom [Burlington]
Tom.Kralidis at ec.gc.ca
Tue Jun 1 13:35:14 EDT 2004
Hi,
Yes, in the client side approach, some WMS layers take longer to get
back, but, while they are returning, other (faster) WMS responses are
returned.
That being said, even when some layers are taking longer, the
*perceived* response is also beneficial.
..Tom
>
>
> > -----Original Message-----
> > From: Bart van den Eijnden [mailto:bartvde at xs4all.nl]
> > Sent: Tuesday, June 01, 2004 1:01 PM
> > To: chameleon at lists.maptools.org
> > Subject: Re: [Chameleon] performance of drawmap.php
> >
> >
> > 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
> > >>
> > >
> >
> >
> >
> > --
> >
> > _______________________________________________
> > Chameleon mailing list
> > Chameleon at lists.maptools.org
> > http://lists.maptools.org/mailman/listinfo/cha> meleon
> >
>
More information about the Chameleon
mailing list