<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.6944.0">
<TITLE>RE: [ka-Map-users] Switching over to ka-Map/MapServer</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Hi Chris<BR>
<BR>
Thanks for the recommendations. What would be the preferred method of generating the map tiles, the precache.php script distributed with ka-Mapk, or is there a more efficient approach?<BR>
<BR>
Cheers<BR>
Adam<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Chris Tweedie [<A HREF="mailto:Chris.Tweedie@dli.wa.gov.au">mailto:Chris.Tweedie@dli.wa.gov.au</A>]<BR>
Sent: Thu 17/11/2005 9:18 PM<BR>
To: Adam Ratcliffe; ka-map-users@lists.maptools.org<BR>
Cc: Jonas Ekstedt<BR>
Subject: RE: [ka-Map-users] Switching over to ka-Map/MapServer<BR>
<BR>
The great thing about precaching the tiles in Ka-map is that you<BR>
essentially separate the map server entirely from the web server. The<BR>
overhead in generating any sort of map on the fly from the traditional<BR>
web GIS would, at a guess, account for 90% of the time it takes to view<BR>
the image. Precaching puts the overhead squarely at your web server /<BR>
system configuration and the time it takes to parse the php and retrieve<BR>
the static image tile.<BR>
<BR>
<BR>
<BR>
Because of this, hunt around for some generic web server benchmarks to<BR>
give you some idea of the throughputs of various web servers for your<BR>
configuration. Remember of course that kamap has a dependency on php so<BR>
you will need to factor this in.<BR>
<BR>
<BR>
<BR>
Once you have narrowed down possible combinations of os/web<BR>
server/tweaking you can start looking at theoretical load on your dual<BR>
xeon. You may also need to clarify "1000 concurrent users" in terms of<BR>
actual requests per second in order to be meaningful for a benchmark.<BR>
Sounds like you are looking at a very high load, so precaching would<BR>
almost be a must.<BR>
<BR>
<BR>
<BR>
Hope this helps,<BR>
<BR>
<BR>
<BR>
Regards,<BR>
<BR>
<BR>
<BR>
Chris<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: ka-map-users-bounces@lists.maptools.org<BR>
[<A HREF="mailto:ka-map-users-bounces@lists.maptools.org">mailto:ka-map-users-bounces@lists.maptools.org</A>] On Behalf Of Adam<BR>
Ratcliffe<BR>
Sent: Thursday, 17 November 2005 3:38 PM<BR>
To: ka-map-users@lists.maptools.org<BR>
Cc: Jonas Ekstedt<BR>
Subject: [ka-Map-users] Switching over to ka-Map/MapServer<BR>
<BR>
<BR>
<BR>
Hi,<BR>
<BR>
We've developed a location-based services solution that uses a<BR>
commercial map server, java-based middleware for searching our streets<BR>
and points of interest database, and a javascript client-side API for<BR>
map presentation and interactivity.<BR>
<BR>
The maps are currently served as single raster tiles, unfortunately<BR>
we've run into performance issues with the map server software - on a<BR>
dual xeon server we can achieve a maximum throughput of only about 80<BR>
maps / minute. As you might imagine scaling out this solution would be<BR>
prohibitively expensive.<BR>
<BR>
We'd like to explore using a raster tile based approach and ka-Map looks<BR>
like a great fit.<BR>
<BR>
I'm interested in getting a rough idea of what kind of hardware/software<BR>
configuration we would need to support a ka-Map site with the following<BR>
characteristics:<BR>
<BR>
- Up to 1000 concurrent users<BR>
- Map data in vector format in an Oracle Spatial database and consisting<BR>
of street level and point of interest data for the entire New Zealand<BR>
region<BR>
- Responsive map panning and zooming (presumably pre-caching the image<BR>
tiles would be a good idea)<BR>
<BR>
Any comments much appreciated.<BR>
<BR>
Kind regards<BR>
Adam Ratcliffe<BR>
<BR>
<BR>
This e-mail and any files transmitted with it are intended only for the use of the addressee(s). It may contain information that is confidential and privileged. If you are not an intended recipient, any use, interference with, disclosure, distribution or copying of this material is unauthorised and prohibited. If you receive this in error, please notify the author by Return email to the sender. Information in this message not relating to the official business of DLI shall be understood as neither given nor endorsed by it. While every care is taken, it is recommended that you scan any attachments for viruses. DLI liability is limited to re-supplying affected attachments.<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>