Image Web Server can now serve your vector data at the same blazing fast speed it serves image data!
Next Tuesday, 25th of August, Richard Orchard, Product Manager of Image Web Server, will be hosting a webinar previewing this exciting, upcoming feature of Image Web Server.
The webinar will show you how you can effectively serve both image and feature data with Image Web Server at unbelievably fast speeds. In particular, new features of the "optimized tile delivery" functions of Image Web Server will be reviewed. A comparison of the new technology against a "tile cache server" setup will also be made.
If your organization is interested in creating a public access website, this webinar will show you how easy and inexpensive the most powerful geospatial serving engine is to implement....
J2i files speed up the delivery of JPEG 2000 files.
J2i files are an "index" of the JPEG 2000 file. Indexes of JPEG 2000 files can be many hundreds of megabytes in size. J2i files are automatically created by Image Web Server and used to speed up decoding and lower the memory overhead....
You may have noticed that over the past few years the sizes of hard-disk drives has grown tremendously. If I look on Amazon.com today, i can see 1.5 Terabyte hard-drives for around $150. Wow! That is pretty cheap.
So, you may ask yourself, do I still need to compress imagery? I have got these massive hard-disks, maybe I don't have to worry about it. But there is something you need to be aware of....
Disk speed is pretty much the same as it was 10 or more years ago
Overlooked by many, particularly hard-ware vendors and IT departments that like spending (your) money, is that whilst there has been massive growth in the capacity of hard disks drive, they are pretty much the same SPEED that they were years ago. Speed increases have been a lot slower in coming about than the increase in disk size.
There have been some "trivial" movements with "SCSI" and SATA drives. 5400 or 7200 revolutions per minute compared to 10,000 or 15,000. Not much of a comparison when you compare it to 80GB to 1.5 Terabytes.
The constant rate of disk speed is no better emphasized that with "seek time". "Seek time" is the time it takes to "find" your information on your disk. This has stayed "static" for the most part in the last 10 or more years.
The relative slowness in hard-disk speed means that, among other things it will still take the around the same amount of time to "read" your images today as it did 10 years ago.
This means that the larger the "data" on the disc, the slower it will be to "read", regardless of having a "big hard-disk".
How does compression help?
So where does this leave "compression"? Well, there are a few factors that help speed up imagery access when using compression - Less data needs to be read from disk....
WMS or Web Mapping Service is a popular way of distributing geospatial data.
However, something that has been showing up more recently is that people may overlook the performance gains they get with simply using client-side asychronous access. Instead, they make one of their server components work really hard and subsequently slow down their entire application. Cascading Services through a single server.
In the diagram you can see one WMS Server requesting information from another WMS Server, then sending the combined information onto the client application. Whilst this may seem "convenient" to a system administrator, the solution is also likely to underperform. One service is going to be dependent on the other service, and do some unnecessary extra work. On top of this, often the requesting server doesn't just pass through the information, it saves the information to its own system, then passes on the data. This doubles up the work needed to be done to present the information.
A better way to get the data to people faster, is to make "asynchronous" requests to the different services, from the client. Asynchronous delivery of geospatial data 
In this instance, neither service is dependent upon each other, and neither service has to do more work than it needs to. By saving your system resources, you get to save time, with faster responses. And, by conserving your system resources, you can do more with your existing hardware....
ECWP is a high-speed streaming imagery protocol provided by Image Web Server.
ECWP allows a single, entry-level server, to provide 1000's of gigabytes of image data to thousands of concurrent users that are using different web, desktop, GIS, server or mobile applications....
In the case of Image Web Server - 600 clients can be requesting maps, from a repository of 500GB+ of imagery - and all get sub-1 second response times. In fact, the number of clients can grow into the thousands before the response time begins to go over the 1 second mark. The server hardware: A dual Xeon CPU, 2GB of RAM and SATA discs (7200 RPM). So, your typical entry level server. In fact, maybe now it might be lower than entry level.......
When you deploy your web mapping application, you want it to run as fast as possible. There are a number of "tricks" you can use to make it even faster. Many of these tricks seem to be missed when people deploy websites (GIS based or otherwise).
HTTP compression. This can really shrink the size of your HTML, Javascript or CSS files. usually to about 20% of what they were originally. With GIS Mapping sites, there is usually quite a bit of logic going into the JavaScript end - so making your JavaScript files as small as possible is a real benefit. For example - iws.js - one of the main JavaScript files went from 140KB to just 29KB!
Minification of JavaScripts, CSS and HTML. Minification indicate the removal of excess or unnecessary whitespace or comments in your JavaScript or CSS files. Cutting out this space can reduce the size of a text based file by around 30%. With this size, I also strip out excess whitespace in the HTML files.
Minification often extends to renaming variables in JavaScript files to "shorter names", saving on size of data. I have had mixed success with this - sometimes it seems to create errors in my code.
Combine CSS and Javascript files. Reducing the number of individual requests for files speeds up data access. So, where possible I have grouped CSS and Javascript into one larger file, rather than separate files. Each file request can take up to 200 miliseconds. So, if you have 10 or more external scripts, it can quickly add to your total loading time.
Settings a long expires header on resources that don't change often. This means that a browser doesn't have to keep requesting the same resources over and over again - even if it is just to find out the resource hasn't changed. I have set a long expires on my icon images, as well as base JavaScripts, CSS files.
R....
| |