For a given level of hardware speed and capacity, performance for a Manifold IMS map server page depends upon Windows system settings (including IIS settings) as well as the configuration of the map server and the .map file it uses.
The map server uses Manifold to generate images served via the web page. The basic performance of the map server will be similar to that of Manifold during interactive usage and is subject to the same optimization tips suggested for Manifold in the Performance Tips topic. Make sure you follow all the performance tips listed in that topic.
Additional performance tips of special interest to IMS:
Manifold IMS Performance Tips
§ Use 64-bit Windows and 64-bit Manifold - 64-bit operation is significantly faster than 32-bit operation in IIS applications because larger amounts of memory can be more effectively used.
§ Export smaller sized web pages - Generating a map server image of 400 x 300 requires less computation than an image of 800 x 600. Larger views will usually include more objects and so require greater display computation. In addition, serving larger images means moving larger amounts of pixels into the created image and then transmitting those larger numbers of pixels down the Internet pipes connecting the server to the user's browser.
§ Avoid use of very large .map files - The larger and more complex the component the slower will be the response of the map server. Just as with interactive use of Manifold, performance of the map server will improve as the user zooms in so that fewer objects participate in the display.
§ Avoid unnecessary use of images and surfaces - Images and surfaces can be slower than drawings for the information they provide. The Manifold map server will happily serve images and surfaces but these should not be used as casual substitutions for drawings when a drawing will do as well and will provide higher performance.
§ Use Compressed Images - Using a linked image with an ECW or JPEG 2000 file is vastly faster than ordinary images, a difference of virtually instantaneous zooming and panning as opposed to possibly minutes for very large images.
§ Use Oracle Spatial or a spatial DBMS for Images - Images linked from an Oracle Spatial server or from a spatial DBMS managed by Manifold will be extremely fast at virtually any size. Linking images from Oracle requires Enterprise Edition, but any Manifold edition can link images from spatial DBMS managed by Manifold.
§ Install Ample RAM - As components in the .map file are used, they are read off disk and brought into RAM. Once a component is in RAM, it stays there unless the RAM must be freed for some other purpose. The map server can work faster if the components it needs are already in RAM. As the parts of the .map that are served are brought into RAM and stay there (as a result of normal Windows RAM caching) access speed will increase. This only works, of course, if there is enough RAM so that the cached .map data is not flushed from RAM because some other Windows application needs the RAM. RAM is cheap: install many gigabytes if you can do so. Choosing a server motherboard that can host 16 or 32 GB of RAM is much less expensive than having to use more than one server machine.
§ Run Multi-core Processors - Almost anything that can be done to avoid having to scale out to multiple server machines is worth the cost and effort. Choose a motherboard with two or more processor sockets and then install quad-core processors to get eight or more processor cores in action. If you have multiple processor cores don't forget to configure multiple worker processes. For example, if you have a quad core processor and want to max out all four cores, configure your web application to have four worker processes.
§ Eliminate initial load lag - The first time a very large map is served the map server will be slow to respond while the .map is opened and loaded for the first time. After creating a site the webmaster should browse the site and choose Zoom to Fit with all layers turned on. This will load the entire .map file into RAM. Thereafter, server response will be faster.
§ Match component projections to maps - If a map is served, all layers in that map should have exactly the same native projection as used by the map. This will eliminate any need to re-project on the fly. This is especially important for images and surfaces.
§ Delete unused components from the .map file - If the .map file contains many components other than those published in the web page the map server will respond slightly more slowly than if the .map file contained only those components being published. Delete any unused components from the .map file. This is normally a very minor impediment to maximum performance. However, if the .map file contains very large components that are not used the performance difference may be noticeable.
§ Delete unused data from components - If the web site does not enable the Find tool or use queries there is no point in publishing a drawing that contains data attributes. Delete the columns in the drawing's table. When publishing maps that contain more than one drawing the Find tool will list all fields in all drawings in the map. Delete all fields that you do not want users to be able to employ in Find. This will reduce the size of the .map file.
§ Avoid use of unnecessarily detailed data - A web site that provides overall, national data should not use extremely detailed high-resolution drawings. Use Normalize Topology with appropriate Location Precision settings to simplify drawings. This is often a key step to increasing the speed of redisplay, pan, zoom, etc.
§ Use Zoom Ranges to present the level of detail required - Suppose we would like to show a national map for user orientation when zoomed out but we would also like to show very detailed shorelines when users zoom in. Create a map using two drawings: a highly detailed drawing plus a second, low resolution drawing created from the first by generalizing with Normalize Topology to a lower Location Precision value. Assign zoom ranges to the drawings so that the low-resolution drawing is the only drawing displayed when zoomed out and the high-resolution drawing is the only drawing displayed when zoomed in. When users browse the map in a zoomed out view the display will be fast because a fewer number of coordinates need be used to display the low-resolution drawing. When users are zoomed in the high-resolution drawing will become visible; however, only a portion of the high-resolution drawing will be seen in a zoomed in view so the display will still be fast.
§ Store the .map file used on a fast, local hard disk - When the Manifold map server operates it accesses the .map file that was used with File - Export - Web Page to create the web page. If the .map file is located on a slow hard disk or on a different machine that must be accessed via a local area network then performance will not be as fast as if the .map file was immediately available on a local, fast hard disk.
§ Avoid using intrinsic fields in queries. For example, if the length of a road line must be used, do not compute the length on the fly via the Length (I) intrinsic field. Instead, create a new column called Length and copy the contents of the Length (I) intrinsic field into this new column using the transform toolbar Copy command. When an intrinsic field is used in a query a small computation must be performed for every record for every query. If the intrinsic field is copied to a regular column the computation is done only once. The query can then use the regular column for faster operation.
§ Avoid unnecessary refreshes. Depending on the technology employed, the speed of the communications channel and the amount of data involved each refresh can impact performance. There is no need to refresh every minute if data can only change significantly once per hour.
§ Avoid slow linked components. While linked components are the perfect solution in many applications, at times it does not make sense to use them. At other times it makes sense to use linked components but only if used correctly, such as by an informed, expert choice of which type of linked component to use. For example, it may be tempting if we need a background image for a web site to simply link in an image from an OGC WMS server to which we have access. However, thereafter whenever we refresh links our web site will be at the mercy of whatever performance is provided by the OGC WMS server. It would be faster and better (assuming the background image does not change, as they rarely do) to convert that image into a local image such as an ECW image. See the discussion of refresh issues in the Map Server Overview topic.
§ Use EPSG projections for OGC WMS. If the coordinate system (projection) used by a served component is not supported by the EPSG schema used by the OGC WMS community, Manifold will have to re-project the component on the fly into Latitude / Longitude, most likely killing performance. When setting up a Manifold application as an OGC WMS server we must check the projections used by the components being served and we must make sure that they are coordinate systems that can be expressed using the EPSG schema. See the Map Server Overview topic.
§ Use fast database technology. Manifold works with virtually all DBMS technologies, which is great for flexibility but also gives us the ability to choose either very slow or very fast technologies. For example, some ADO .NET connections can be 600 times faster than an ODBC connection to the very same data source. Since many Manifold IMS web sites will include the use of some database technology (for example, if linked tables are used or linked drawings) it is important that we choose such technology wisely. In the case of linked tables if the data originates in a slow technology such as an Excel .xls file it will usually make sense to upgrade to a very fast technology, such as a SQL Server table accessed via ADO .NET or an Oracle table that can be accessed via OCI. As a rule of thumb, the fastest connections for storing attributes are to use ADO .NET with SQL Server or to use Oracle (which automatically uses OCI). The fastest geometry storage for large applications is to use a spatial DBMS such as SQL Server 2008 spatial, the Manifold spatial extender with SQL Server 2005, IBM DB2 with Spatial Extender, PostgreSQL/PostGIS or Oracle (taking advantage of Oracle Spatial or Locator services in Oracle XE or in standard Oracle).
§ Very Important: If you create a default_admin.asp page for your IMS site, make sure to change access permissions on it so that ordinary Internet browsers cannot use it. To do this, in Windows Explorer right click on the default_admin.asp file, choose Properties and choose the Security tab. Remove all entries for allowed user names except Administrator or whatever other login name you wish to allow access to the administration page. Apply the settings and press OK. Neglecting this important step will not create a security breach in that hackers will be able to steal your data, but it will allow a malevolent user to effectively shut down your map server by repeatedly causing it to Reload .map files.
IIS Configuration Performance Tips
§ Create an application and consider using High (isolated). - Create an application on the directory in which the web page is located and run it with high isolation. This runs the map server process as an isolated process outside of the IIS process and separate from any other applications running on IIS. This helps performance slightly (albeit at the cost of creating temporary files for every user), and also isolates the application so any errors in the scripts or map server application won't bring down IIS or any other application. For performance reasons, don't run more than ten IIS applications as High (Isolated). To run additional map server applications beyond ten, if the map server application is well debugged (that is, the scripts used in default.asp and other files are well debugged), use Medium (pooled) for the additional applications. Medium pooling might also be a good idea to reduce the creation of per-user temp files (see comments below).
§ Don't enable session state - Within the IIS manager, in Properties - Configuration - App Options uncheck Enable session state. The Manifold map server does not use sessions so this can be unchecked if desired to eliminate the overhead of maintaining session state. In the same dialog it is a good idea to also uncheck Enable parent paths if desired. This has no impact on performance but it does improve security. Unchecking this box means the application can not refer to anything in higher directories. The map server application itself only refers to files within its own directory or subdirectories such as the images folder.
§ Enable object pooling - If there are more than about 10 simultaneous users, enable object pooling. This is done in the Control Panel - Administrative Tools - Component Services manager. Drill down into COM+ Applications and find your map server application. Drill down into Components for that application and right click on the component there and choose Properties. Object pooling settings are on the Activation tab. Check the Enable object pooling box. The pooling parameters may be left on default settings.
System Configuration Performance Tips
§ Store the .map file used on a fast, local hard disk - When the Manifold map server operates it accesses the .map file that was used with File - Export - Web Page to create the web page. If the .map file is located on a slow hard disk or on a different machine that must be accessed via a local area network then performance will not be as fast as if the .map file was immediately available on a local, fast hard disk.\
§ Configure temp folders on a separate, fast hard disk - Putting temp folders on a separate hard disk allows "overlapping head seeks" so that the disk drivers can command a head movement on the disk(s) hosting the temp folders at the same time heads are moving on whatever disk(s) host the rest of what is going on in Windows. This is a fine point, but not one to be overlooked if you are trying to wring maximum speed out of your system. Head motions are the slowest thing in the system so we don't want to waiting around for one head motion to finish before we get going on the next.
§ Use Large Disks and RAID - Large disks are faster than smaller disks. Use modern interfaces such as SATA and configure several hard disks in a striped RAID array for speed.
§ Install lots and lots of RAM - Installing plenty of dynamic RAM is often the most efficient way to enable a server to serve more users faster. RAM is now so inexpensive (under $60 for a gigabyte) that it makes sense even for a hobbyist to install two or three gigabytes of RAM. If you are running an older motherboard that can hold only one and a half gigabytes, fill it up with the maximum amount of RAM right away it even if you don't feel you need it because eventually memory for older motherboards will be difficult to get.
§ Use a fast processor - A faster processor will be able to serve more users. Upgrade to a gigahertz class processor.
§ Use a Quad Core 64-Bit Processor - Quad-core processors do not cost significantly more than dual-core or single-core processors. Use 64-bit hardware with 64-bit Windows and 64-bit Manifold. Using 32-bit software and hardware in a web server application is a terrible waste.
§ Use multiple processors or multi-core processors - Each new release of Manifold adds more functions that are multi-threaded. For example, Manifold will use more than one thread to render image libraries if more than one processor or processor core is available on the computer system. Therefore, image libraries will render faster on multiprocessor or on multi-core processor systems such as those using two sockets to host a quad-core processor in each socket.
§ Use Windows Server 2003 or XP - Windows Server 2003 provides the best performance. Windows XP provides slightly better performance than Windows 2000. Do not use older Windows releases. Vista is cool, but at the present writing it is not as fast as Windows Server 2003 or XP x64.
§ Deploy a server farm - Like any web application, given enough users even a fast IMS application can be overwhelmed if only a single machine is used. Novice webmasters are sometimes surprised to learn that large sites serving many visitors like Google, airline reservation sites or mapping sites don't just run on a single computer but are hosted by hundreds or even thousands of computers configured in a server farm. If we want to compete with a huge site hosting millions of visitors per hour, no matter how fast Manifold may be we too may need to deploy a warehouse full of servers.
§ Plan to use NVIDIA CUDA - Try to choose a server motherboard that can support at least one NVIDIA CUDA-capable GPU. Although this technology is just getting started, each new release of Manifold is expected to make more and more use of it. May as well be ready.
About IIS Applications
An IIS application is any file that is executed within a defined set of directories in a web site. Creating an application designates a particular directory in the web site as the starting point directory (also referred to as the application root). All files and directories under that starting point directory are considered part of that application until another starting point directory is encountered. See the About Applications topic in the IIS documentation.
Different components from the same .map file can be used with different map server pages. However, all map server pages must be part of the same Application.
About Object Pooling
Manifold components support object pooling, which avoids the overhead of creating new objects in highly loaded servers. Normally, when a process needs an object it is created on the fly using the component's class factory to create a new object. When object pooling is turned on objects that are created are retained in a pre-built pool of objects. When an object is needed an object from the pool is activated if one is available. Pooled objects are returned to the pool when no longer needed.
Suppose 20 users at once hit the web site. The first time the server experiences this peak load enough objects to service the 20 users will be created. As load drops, objects will be returned to the object pool. Thereafter as long as the load stays under 20 simultaneous users no objects need to be created: they will simply be activated from the pool. If load grows again and peaks at 25 users, a few more additional objects will be created since the objects in the pool will not be enough to service demand. Thereafter, enough objects will be in the pool to serve up to 25 simultaneous requests.
Manifold IMS supports logging. To enable logging, edit the config.txt file for a page and add the following line:
logfile = c:\mapserver.log
where "c:\mapserver.log" is the fully qualified path name to the desired log file. The log file will be written in CSV format using field names that are self-describing. ticks is the number of 1/1000ths of a second spent serving the image. It's safe to use the same log file for different instances of the map server.
Be careful when enabling logging. It is always easy to turn on a logging function and then forget it has been enabled until the log file grows to a huge size.
Microsoft IIS is a secure and highly reliable web server when correctly configured by the system administrator. Nonetheless, the many options made available within IIS to support the needs of experts can result in security problems if administered improperly. Because an IIS web server connected to Internet can be attacked by any Internet user from anywhere in the world, a few general IIS security measures should be applied to any web server connected to the Internet. These measures are not specific to Manifold IMS: they should be applied to every web server.
We recommend the following elementary steps:
§ Use Windows 2003, 2000 or XP. Windows XP configures IIS by default with more security than does Windows 2000. Windows Server 2003 has the most default security.
§ Use NTFS file systems.
§ Do not allow anyone to work interactively, to read mail or to browse web sites on the machine that hosts your web site. If you must use the same machine interactively, make sure that user logins you employ do not have Administrator privileges. If a user with Administrator privileges just once opens a malevolent email attachment the web server itself could be infected with a wide variety of "backdoor" viruses or Trojan Horse attacks. Never read email or browse the web when logged in as Administrator.
§ Install the latest Service Pack for Windows. Service packs include many security patches.
§ Configure Windows Update to automatically download and install the latest Windows updates.
§ Very Important: If you create a default_admin.asp page for your IMS site, make sure to change access permissions on it so that ordinary Internet browsers cannot use it. To do this, in Windows Explorer right click on the default_admin.asp file, choose Properties and choose the Security tab. Remove all entries for allowed user names except Administrator or whatever other login name you wish to allow access to the administration page. Apply the settings and press OK.
§ Use an Administrator password that is called something other than "Administrator". Brute-force password cracking attacks have half the problem solved if they can assume there is a login called "Administrator" to attack.
§ Use a seriously long (over 16 digits), randomly constructed password to make it difficult for brute-force password cracking assaults to guess your password.
§ Install any supplemental security patches published by Microsoft after the last Windows Service Pack. Microsoft now has tools that can scan your system to determine if there are security patches published that have not yet been installed. Visit Microsoft TechNet at http://www.microsoft.com/technet/default.asp and drill down to their Security pages for information on the latest security tools and patches.
§ Install anti-virus software. Keep your anti-virus software updated with regular downloads from your vendor.
§ Install Microsoft URLScan (a free download from Microsoft TechNet) or similar tool. URLScan is an ISAPI filtering tool for IIS that rejects a wide variety of malformed URL requests before they can hit IIS. It is very easy to use. It was published by Microsoft in 2001 and is an absolutely essential tool to prevent many different types of Denial of Service attacks. No doubt the functions provided by URLScan will continue to be offered by Microsoft either as independent tools or built into IIS. Manifold IMS works perfectly with URLScan.
§ Apply Microsoft's IIS Lockdown Tool (a free download from Microsoft TechNet), or its successors, using Advanced Lockdown. Uncheck the box that disables support for Active Server Pages (.asp) and otherwise accept all of the defaults suggested by Advanced Lockdown. Manifold IMS works perfectly with Advanced Lockdown settings so long as Active Server Pages are still enabled. This tool is also very easy to use. Some recent editions of IIS may be shipped by Microsoft in lockdown mode by default.
§ Do not run unnecessary services. If your server runs a web site only, do not install or enable additional services such as FTP, NNTP or others. If such services are already installed, use Internet Services Manager to stop them. Do not install any accessory software or Windows components that are not required.
§ Do not install unnecessary applications on your web server. Every application you install increases the attack surface that an adversary can exploit. For example, don't install things like Microsoft Office on a machine that will only be a web server.
§ Do not use your web server, ever, for Internet browsing or other applications. Some people press into use as a web server an otherwise underutilized machine that is occasionally used (out of boredom while waiting for some administrative task to complete, etc.) to browse the web or for other purposes. Dedicate a machine to web serving and don't use it for other purposes.
§ Do not connect your web server on a local area network to other machines unless you really know what you are doing with security. It is safest to keep it isolated and to use a USB drive to exchange files with other machines.
§ If you use Remote Desktop to work with your server, change the port it uses to some port other than the default. (Don't forget to leave this port open in your firewall.)
§ Learn to use Advanced TCP/IP settings for the Internet Protocol in Network properties for the network card in use. If your web site is intended only for specific machines (such as those on an Intranet), use IP security to deny access to any unauthorized machines (IP addresses). If you are connected to Internet, use TCP/IP filtering to permit only those TCP ports absolutely required to service your web site (typically, port 80 for HTTP and port 443 for HTTPS). Strict IP filtering will not allow services such as DNS (used if you are browsing from the web server) so a truly secure regime will limit utilization of the system to a web serving only.
§ Install a firewall such as Windows Firewall and learn to use it. Use a hardware firewall and/or software solution such as Microsoft's Internet Security and Acceleration Server. Hardware firewalls now cost well under $100. Configure your hardware firewall so that only those ports required for serving web pages are enabled, with all other ports disabled.
§ Install the latest updates for Manifold System from manifold.net.
§ Get a good book on Windows and IIS security. Read it carefully and apply the recommendations. Surf the web and read the many free resources on Windows and IIS security.
§ Participate in Manifold-L (email discussion list format) and the Georeference Forum at http://forum.manifold.net for Manifold System users. Ask questions of your more experienced colleagues and as you gain expertise yourself give back to the community by assisting newbies with security questions.
Very important: Although Manifold IMS can work with Microsoft security tools for IIS such as URLScan and the IIS Lockdown Tool, it is possible that other IIS applications installed on your system cannot work with these tools or require modifications to the default settings of these tools. It is critically important to read the documentation for these security tools.
Minimizing Per-User Temp Files
When using a High isolation level in IIS, a new process will be created for each user accessing IMS. When this is done the multiple instances of IMS can not share data with each other and will be forced to create a separate set of temporary files for each user. This provides high isolation but results in a large number of temporary files in the system TEMP folder.
One way of reducing the number of temporary files created is to lower the isolation level applied to the web application that uses IMS so that multiple instances of IMS can operate in the same process. This does create a risk in that a crash of one instance of IMS will likely crash all other instances, but given that it is relatively difficult to crash IMS in the first place, this might be a good tradeoff in the case of well-debugged .asp files.
See the troubleshooting topic Problems with the Internet Map Server for detailed checklists of what might be wrong.
You must be running Manifold System Professional Edition or greater to have the capabilities discussed in this topic. All Manifold editions except Personal Edition include the map server. If you are running Manifold System Personal Edition you will not have the capabilities discussed in this topic.
Map Server Overview
Creating a Web Site
Publishing Multiple Pages
Problems with the Internet Map Server