Many things come into play to make the response time of MapServer long or short. But at a basic level the time required to get just the part of the image required in the source file(s) and the CPU time required to decode that part if compressed, are major factors in performance. ECW is wavelet, and I maybe wrong but nowadays I think that means its just jp2 from the perspective of GDAL so its not going to be fast in comparison to other formats like GTIF. That just because decoding the jp2 just takes a lot more time than say decoding GTIF with jpeg compression.
I know from other sid file based projects that I have done, something like 3 seconds would not be surprising, especially if you are talking a largish image and travel time to browser. Our only solution to that to achieve any real speed was to go to a TMS structure (now WMTS) using jpeg. which means you go to about 5-6 compression ratio rather than 15 as you would get from jp2. so your 150GB would be more like 500GB? But a lot faster. 2010/8/2 Cédric MOULLET <[email protected]>: > Hi Andy, > Thanks for your answer. > The dataset is composed of several ECW files, that's why we use TILEINDEX. > The data are hosted on EBS (http://aws.amazon.com/ebs/). It's supposed to > have normal I/O performance, but probably not fantastic performance. Of what > I have observed, I would say that the CPU is probably the bottleneck. > My goal is to have a 1s response time. Do I dream too much ? > Cédric > > 2010/8/2 Andy Colson <[email protected]> >> >> On 8/2/2010 5:06 AM, Cédric MOULLET wrote: >>> >>> Hello, >>> We've got a 150 GB ECW dataset (aerial imagery) and the LAYER >>> configuration uses a TILEINDEX. >>> We can observe a WMS request time of about 3 seconds (on a server with >>> this configuration: 7.5 GB RAM, 4 core, 64 bits / MapServer 5.4.3). >>> I'd like to know if 3 seconds is considered as a normal response time >>> for this kind of WMS request. >>> What could be done in order to improve this performance (I'm aware of >>> http://www.mapserver.org/optimization/raster.html) ? >>> Thanks ! >>> Cédric >>> >> >> Wow, that's a big file. Is that all in one file? I dont really know the >> answer, I've never used anything over 4 gig, but I do have a few questions: >> >> 1) I assume you are IO bound, do you have this on a raid, or something >> with fast IO? Can you check to see if you are CPU bound or IO bound? >> >> 2) if it is one big file, how would you feel about trying it broken up >> into smaller files? >> >> -Andy > > > > -- > Welcome to my world: http://www.cedricmoullet.com/ > My Linked In profile: http://www.linkedin.com/in/cedricmoullet > Twitter: http://twitter.com/cedricmoullet > Home sweet home: > http://map.geo.admin.ch/?crosshair=bowl&zoom=11&X=185241.24219&Y=561288.90625&bgOpacity=0&selectedNode=node_ch.swisstopo.fixpunkte-lage1 > > _______________________________________________ > mapserver-users mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/mapserver-users > > _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
