The next step was to switch off the old version of GeoServer and present the new version on its address, minimising transition time. This required changing the port of the new version from 8081 to 8080, so I scoured the internet on how to do this. I found a few threads out there, but none gave me the right answer. They specifically mentioned \etc\jetty.xml and GeoServer’s startup.bat, neither of which configured the port for my installation. In fact the configuration is to be found against the Windows service:

Opening this service reveals the port specified in the command line (here showing after I had changed it):

Changing this command required editing the registry, with these settings found under HKEY_LOCAL_MACHINE\SYSTEM\ ControlSet001\services\GeoServer 2.7.0:

Edit the command-line as follows:

I also edited the previous version to start on port 8081 (in case I needed to run both), then stopped the older version’s service and restarted the new version’s service. Everything worked fine, with an imperceptible transition. And as predicted, the disk quota thing started working too.

So that’s how to change the port for GeoServer running on Windows with Jetty!

Aside: I should say that what follows is not what we normally do in our real applications – we usually use ASP.Net .ashx handlers to relay requests through the root of our web sites, which also helps to avoid cross-domain problems with GetFeatureInfo responses and WFS, but that’s another story! This post is in reaction to Dennis’s request for help, and because I wanted to check this approach is viable.

I’ve posted before on how to use URL Rewrite to give GeoServer a friendly URL on IIS, and we’re going to use the same technique here, so first ensure you have the necessaries installed.

You should also already have a working WMS/WFS – we created this one in the previous post:

http://mapservertest.esdm.co.uk/scripts/mapserv.exe?map=D:\Websites\mapservertest\map\mapfiletest.map

which was fine, but a) the URL reveals some information about the structures on the web server, and b) the URL is a bit ugly.

So decide what address you want for your MapServer service (remembering this will be specific right down to the map file). I’m using “mapservertestwrapper.esdm.co.uk” which I have pointed at the web server in question.

Create a new web site in IIS with this URL as a host header (you’ll first need to create an empty “physical” folder for the site to point at – add a readme.config file explaining what it’s for).

Now open URL Rewrite and create a reverse proxy inbound rule, entering the real service address as the forwarding address:

OK now we should be able to see our MapServer on the new URL. However, when we visit http://mapservertestwrapper.esdm.co.uk/ we get this feedback in the browser:

msLoadMap(): Regular expression error. MS_DEFAULT_MAPFILE_PATTERN validation failed. msEvalRegex(): Regular expression error. String failed expression test.

The fix is to re-edit the inbound rule, and remove the final “/” in the “rewrite URL”, going from:

http://mapservertest.esdm.co.uk/scripts/mapserv.exe?map=D:\Websites\mapservertest\map\mapfiletest.map/{R:1}

to:

http://mapservertest.esdm.co.uk/scripts/mapserv.exe?map=D:\Websites\mapservertest\map\mapfiletest.map{R:1}

Now we should get sensible MapServer feedback in the browser (conditioned by a template specified in the map file).

Now let’s see if we can do a GetCapabilities request… turns out our URL has to be this:

http://mapservertestwrapper.esdm.co.uk/?service=wms&version=1.3.0&request=getcapabilities

Yes it works, but a) that’s a slightly odd URL with “/?”, and b) the response contains the original service addresses, again revealing information about our server.

To fix a), we go back and edit our inbound rule again, and change the “pattern” from “(.*)” to “map1(.*)” (without the quotes of course). Now our service URL becomes:

http://mapservertestwrapper.esdm.co.uk/map1?service=wms&version=1.3.0&request=getcapabilities

Ah yes that’s much nicer, and now of course we see we can manage lots of .map files within one web site simply by setting up in inbound rule for each, with an appropriate pattern and target.

To fix b) we can edit the metadata in the .map file to set this:

"wms_onlineresource"    "http://mapservertestwrapper.esdm.co.uk/map1"

This works fine, returning this within the GetCapabilities:

<OnlineResource xlink:href="http://mapservertestwrapper.esdm.co.uk/map1?" xmlns:xlink="http://www.w3.org/1999/xlink"/>

And I can confirm this creates a working map in QGIS, with map requests like this visible in Fiddler:

http://mapservertestwrapper.esdm.co.uk/map1?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=52801.44371538766426966,3347.3560407145996578,657116.82161524775438011,428145.51874091033823788&CRS=EPSG:27700&WIDTH=1020&HEIGHT=717&LAYERS=grid&STYLES=&FORMAT=image/png&DPI=96&MAP_RESOLUTION=96&FORMAT_OPTIONS=dpi:96&TRANSPARENT=TRUE

And a quick test shows that info clicking (GetFeatureInfo) and legends work too:

e.g. http://mapservertestwrapper.esdm.co.uk/map1?version=1.3.0&service=WMS&request=GetLegendGraphic&sld_version=1.1.0&layer=grid&format=image/png&STYLE=default

gives this:

There you go Dennis, we have working OGC services from MapServer with nice clean URLs, a simple architecture for adding new services with their own map files, and no leaking of details about our directory structures.

Footnote…

I’m not completely keen on the last bit, having to change the wms_onlineresource, as this means the original service is now broken (depending on whether the mapping client makes us of this, which QGIS likes to). Another way should be  to create an outbound URL Rewrite rule to rewrite any references to the original URL with the new one. However, after a bit of pfaffing with this, I’m pretty sure there’s a bug in URL Rewrite that means outbound rewriting doesn’t work for attributes containing colons, and ours is “xlink:href”. Incidentally setting up the outbound rules for custom tags is a bit of an adventure through the UI, and there is a bit of escaping to do for the backslashes and question mark in the URL (highlighted below) as URL Rewrite is doing regular expressions so you might as well get down and dirty in the web.config located in the “dummy” folder we created for the new web site we created earlier. So this is my outbound rule that doesn’t work, but should when someone fixes the bug!

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule2" stopProcessing="true">
                    <match url="map1(.*)" />
                    <action type="Rewrite" url="http://mapservertest.esdm.co.uk/scripts/mapserv.exe?map=D:\Websites\mapservertest\map\mapfiletest.map{R:1}" />
                </rule>
            </rules>
            <outboundRules>
                <rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsXML" enabled="true">
                    <match filterByTags="CustomTags" customTags="OGC GetCapabilities" pattern="^http(s)?://mapservertest.esdm.co.uk/scripts/mapserv.exe\?map=D:\\Websites\\mapservertest\\map\\mapfiletest.map(.*)" />
                    <action type="Rewrite" value="http{R:1}://mapservertestwrapper.esdm.co.uk/map1{R:2}" />
                </rule>
                <preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                    <preCondition name="ResponseIsXML">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/xml" />
                    </preCondition>
                </preConditions>
                <customTags>
                    <tags name="OGC GetCapabilities">
                        <tag name="OnlineResource" attribute="xlink:href" />       
                    </tags>
                </customTags>
            </outboundRules>
        </rewrite>
    </system.webServer>
</configuration>

The red bit is the bit affected by the bug I think, unless someone can point out how this should be escaped/expressed to make it work?

The tests that did not immediately pass were:

Request validation: Fail

OK so we find <pages validateRequest="false" … in web.config.

But we are assured this is deliberate and acceptable in mojoPortal because, as Joe Audette explained,

validateRequest is false because we do our own validation of inputs and setting it to true causes problems/errors when posting back html content from a wysiwyg editor.

Excessive headers: Warning

So our IIS server and site are revealing several pieces of information about the technologies behind the site, and we are better concealing these http headers.

Specifically we have:

• Server which can be turned off with URLscan by setting RemoveServerHeader=1 in UrlScan.ini (there are other ways, but this is by far the simplest).
• X-Powered-By which can be turned off in IIS Manager: select the web site, then open HTTP Response Headers and remove this one.
• X-AspNet-Version which can be suppressed by adding this attribute to the httpRuntime setting in web.config: <httpRuntime … enableVersionHeader="false" />

Secure cookies: Fail

In line with the mojoPortal documentation on SSL we already had the attribute in bold:

<forms name=".mysitecookiename" protection="All" timeout="50000000" path="/" cookieless="UseCookies" requireSSL="true" />

but we were still failing the test until we also added this into the system.web section:

<httpCookies httpOnlyCookies="true" requireSSL="true" />

Joe Audette said:

Adding the <httpCookies element as you have just means that any other cookies issued for the web site would also be kept secure, but as far as I know any other cookies we are creating are only for cosmetic purposes such as the one to toggle the collapse state of the admin toolbar etc.

So I think we were secure anyway, but it’s nice to pass the test.

Clickjacking: Warning

This was easily blocked by preventing our site from being run in an iframe. This is achieved in IIS Manager: select the web site, then open HTTP Response Headers, and add a new one as follows:

If we are using an iframe within the site, for something like a keep-alive, another value for this setting is "SAMEORIGIN" - this allows iframes in the site to host content that is within the same domain. If we want our site to be displayed in an iframe within a known other site, we can use "ALLOW-FROM uri".

View state MAC: Not tested

Not tested apparently because the viewstate is encrypted in mojoPortal, but it turns out versions of mojoPortal before 2.4.0.2 had enableViewStateMac="false" which is not what we want. This has been removed, meaning it is set to true by default, in version 2.4.0.2, but if running an earlier version we should ensure this setting has only the following attributes:

<pages validateRequest="false" viewStateEncryptionMode="Auto" maxPageStateFieldLength="500" controlRenderingCompatibilityVersion="4.0" clientIDMode="AutoID">

So on sites running mojoPortal 2.4.0.2 or later, no change needed.

Summary

So we needed to make two changes in web.config, remove one http header and add another one. Plus install and configure URLscan if it's not already present. These are one-off changes for a server and/or site except the web.config settings. mojoPortal upgrades generally involve overwriting the web.config, so it’s important to keep separate notes about what default settings need to be changed again after an upgrade. We always keep these notes for each site in a UpgradeNotes.config file in the root folder of the site.

*** UPDATE ***

Further testing of some sites with ZAP and https://securityheaders.com identified two more http headers (in italics below) that should be set to improve security. Overall the header settings can be wrapped up by including this section in system.webServer:

  <system.webServer>
...
        <httpProtocol>
            <customHeaders>
                <remove name="X-Powered-By" />
                <add name="X-Frame-Options" value="SAMEORIGIN" />
                <add name="X-XSS-Protection" value="1" />
                <add name="X-Content-Type-Options" value="nosniff" />    
                <add name="Referrer-Policy" value="no-referrer-when-downgrade" />
                <add name="strict-transport-security" value="max-age=31536000; includeSubDomains" />
            </customHeaders>
        </httpProtocol> 

...

And it also pointed  out that auto-complete was not disabled on the login screen (which leaves accounts vulnerable where more than one user may share a machine). This can be suppressed with the following in user.config:

<add key="DisableAutoCompleteOnLogin" value="true"/>

We found that our Remote Desktop Web Access didn’t work with IE11. Browsing to the /RDweb page produced this message:

“Browser Not Supported

This Web browser is not supported by RD Web Access. RD Web Access requires Internet Explorer 6.0 or later.”

The solution (thanks to http://www.edugeek.net/forums/windows/127594-ie11-rd-web-access.html and repeated here in case that site vanishes) is to make a minor change to the configuration on the web server. The fix only works on RDS Gateway servers with 2008 R2 SP1 installed.

1. In IIS Management Console, open the Sites node and then select the RDweb node.
2. On the right-hand side double-click on HTTP Response Headers.
3. In the right hand panel click “Add…”.
4. In the dialogue that appears enter Name: X-UA-Compatible and Value: IE=9 as shown below:
    
5. Re-start IIS (and possibly reboot the server) and test RD Web Access again.

Recently we have found that some external users cannot see the mapping, and it appears something at their end is blocking requests to our address. We are not sure exactly what is being blocked, but a solution was needed. We need to run these services over port 80, and with a friendly domain name instead of an i.p. address.

However we also run IIS web sites on the same servers, and while it is possible to reconfigure the port used for Jetty, I’m pretty sure it would not be possible to have both IIS and Jetty handling requests on the same port.

The solution was to configure an IIS web site to route traffic through to GeoServer on its old address. I thought it worth making some notes of the procedure.

1. This required installing two extensions to IIS 7.5:
   URL Rewrite: http://www.iis.net/download/URLRewrite
   Application Request Routing: http://www.iis.net/download/ApplicationRequestRouting
2. I created a new web site in IIS, on the same server as the GeoServer instance. I added a new subdomain, that I had created earlier, as a binding (host header) for the site; this will be the new external address for our GeoServer service. Let’s say it’s mygeoserver.exegesis.com or something.
3. In IIS, select the site, and double-click the “URL Rewrite” icon which should be visible in the IIS section of the Features View.
4. Right-click in the “Inbound rules” area, and “Add Rule(s)…”.
5. Choose “Reverse Proxy” and click OK.
6. Enter the address of the GeoServer instance. Using my hypothetical server above, I would enter 123.345.67.321:8080/geoserver. Click OK.  The “geoserver” bit was not strictly necessary, but including this shortens the final addresses a bit.
7. Test.  For any original request to GeoServer, simply replace http://123.345.67.321:8080/geoserver with mygeoserver.exegesis.com (or whatever), and you should get the same response. For external users, traffic is now going over port 80, and there are no server i.p. addresses to get grumpy about.

For us, it means our clients can now see their map of fly-tipping incidents in the Valleys again:

This also has a number of other benefits that I’ve not fully thought through yet… for example, it means we can use IIS i.p. filtering to restrict access to our GeoServer mapping where needed, we can analyze IIS logs, etc.

http://www.hanselman.com/blog/EnablingDynamicCompressionGzipDeflateForWCFDataFeedsODataAndOtherCustomServicesInIIS7.aspx

Aside: the problem with running an application pool under its own user account is that MapServer CGI will not run within the site – I’ve no idea why, though it must be a permissions issue. When the app pool runs as ApplicationPoolIdentity then MapServer works fine.

As you’ll see from a previous post about how to install a mojoPortal site, it is necessary to secure the web site folders. When I came to do this I found there was no user account called ApplicationPoolIdentity, and no user with the name of the application pool either.

It turns out there is a virtual user account, and it can be entered as

IIS APPPOOL\ApplicationPoolName  (obviously replacing ApplicationPoolName as appropriate):

Folder permissions can then be granted/revoked for this user.

Creating the site

1. Download the latest release from https://www.mojoportal.com/download
2. Unpack the zip and find the wwwroot folder. Copy the contents to wherever you want your web site files.
3. On your SQL Server create an empty database, and give a login dbowner access to it.
4. In the web site folder, rename user.config.sample to user.config and alter the MSSQLConnectionString to point at your new database. Better still copy in a user.config from another working site and adjust.
5. In IIS Manager, we like to create a dedicated application pool per site:
   
6. Then create a web site:
   
7. On a PC, browse to your web site… you should see lots of messages appear like this:
   Welcome to mojoPortal Setup
   Probing system...
   File system permissions ok.
   MSSQL database connection ok.
   database permissions are sufficient to alter schema.
   database initial schema needs to be created.
   Running script mojoportal-core - 2.3.4.8 - 00:00:00.0700000
   Running script mojoportal-core - 2.3.4.9 - 00:00:03.2250000
   Running script mojoportal-core - 2.3.5.0 - 00:00:03.2820000
   Running script mojoportal-core - 2.3.5.1 - 00:00:03.3130000
   etc etc
8. Your site should now be up and running. Assuming it is, there are a couple more things to do to secure the site.

Securing the site

1. Sign in as admin@admin.com / admin
2. Got to Administration > Security Advisor – it will be warning you about the machine key. Click “Generate a new key”, copy the result, and paste it into your web.config on the web server (replacing the existing machine key – search the file for “machineKey”). This will make your site restart so you will have to log in again.
3. Next visit the “Member List” page (using the link at the top of the page), and click “Add new user”. Create a new account for yourself, and after clicking “Create User” go to “Role Membership” and add the new account to the Administrators role. Sign out, and sign in again with your new account.
4. Go to the Member List, “Manage” the “Admin” account, and delete it.
5. Go to Administration > Site Settings > Security, and change the password format from “Clear Text in DB” to “Hashed in DB…”
6. Screw down the permission on the web site folders as instructed here. We like to make the application pool run under a specific user account, then give this account the permissions described.

That’s it – you have a secure mojoPortal web site.

Useful settings

We like to add the following settings to user.config (remembering to touch web.config to make these take effect):

    <!-- to allow extensionless URLs -->
    <add key="AllowChangingFriendlyUrlPattern" value="true" />
    <!-- Set these to false during design work -->
    <add key="CacheCssOnServer" value="false"/>
    <add key="CacheCssInBrowser" value="false"/>
    <!-- To prevent startup scripts running. Change to false when upgrading mojo -->
    <add key="DisableSetup" value="true" />
    <!-- make sure admins put content files in same place as non-admins -->
    <add key="ForceAdminsToUseMediaFolder" value="true" />
    <add key="AllowForcingPreferredHostName" value="true" />
    <!-- EMAIL -->
    <add key="DisableDotNetOpenMail" value="true" />
    <add key="SMTPServer" value="myserver" />
    <add key="SMTPRequiresAuthentication" value="true" />
    <add key="SMTPUseSsl" value="false" />
    <add key="SMTPPort" value="25" />
    <add key="SMTPUser" value="mymailserver" />
    <add key="SMTPPassword" value="mypassword" />
    <add key="SMTPTimeoutInMilliseconds" value="30000" />
    <!-- Leave this blank for ASCII encoding. Allowed values are utf-8, utf-32, and unicode -->
    <add key="SmtpPreferredEncoding" value=""/>
    <!-- END EMAIL -->

Skinning the site

Big topic, with plenty of guidance on www.mojoportal.com, and we are now going over the 10 minutes! The easiest way to get started is to choose the shipped skin that is closest to your layout/behaviour requirements, clone this skin, then work on the CSS, layout.master and graphics. We usually review the extra skins that are available for each mojoPortal release (as well as the ones in the release folders). These are also found on the Codeplex download page (see above) as “extra-skins.zip”. If you drop the unzipped skin folders into \Data\skins in your web site folder they will be available for all child sites. If you have already create a site, you can drop them into \Data\Sites\N\skins (where N is the number of your site).

I ran the test against a single page in the new site that loads a record from the web service, with a query on the record ID.

http://nhe.no-ip.org/glossary?uid=TNF2069

I didn’t mention in the previous post that you need to watch the “errors” figure. You can see this in the console during the test run, and also at the top of the results html. The first time I ran the test, I got a huge error rate – something like 5000 errors out of 6000 transactions. Therefore I lowered the number of threads to 4, ramping up over 100 seconds.

This time I got 474 errors out of 627 transactions, and an interesting pattern emerged:

Timer Summary (secs)

Interval Details (secs)

Graphs

Response Time: 10 sec time-series

Response Time: raw data (all points)

Throughput: 10 sec time-series

I think what’s happening here is:

First 50 seconds we get consistent response times around 1 second with no errors. Not sure why no change at 20-30 seconds transition, because I would have expected M-M to add a virtual user at this point.

After 50 seconds, we clearly have more virtual users, and the site slows down with average responses 2.25 seconds.

At 75 seconds (presumably 3 virtual users), the response times become much faster… eh? Well because I was watching the console output I knew this is also when the errors starting happening – pity M-M’s analysis doesn’t reveal this.  I also “manually” uses the site during this period, and found that mojoPortal was returning it’s standard “something’s bust” page (and doing so very rapidly!).

Examination of the mojoPortal system log showed that our plug-in component that talks to the web service was throwing an unhandled exception, along the lines that the root XML element was missing in the response from the HBSMR Gateway web service. This is turn was causing mojoPortal to output it’s standard error page.

2011-12-28 10:41:16,125 ERROR 82.31.27.48 - en-US - /glossary?uid=TNF2069 - mojoPortal.Web.Global -  Referrer(none) useragent Mozilla/5.0 Compatible
System.Xml.XmlException: Root element is missing.
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
   at System.Xml.XmlDocument.Load(XmlReader reader)
   at System.Xml.XmlDocument.LoadXml(String xml)
   at ESDMmojoPortal.NHE.Business.GatewayResult.get_BBox()

I’ll need to investigate this further, but it suggests the HBSMR Gateway web service was returning an error response or perhaps empty XML when put under this load. This has to be improved of course, because it can come under very heavy load when used from the national Heritage Gateway site as well as applications like the Norfolk Heritage Explorer.

So Multi-Mechanize has been incredibly useful in highlighting a weakness that could otherwise have rumbled on causing occasional problems for months.

However, note that at first glance the graphs look as though the site was performing better as the load increased, because erring transactions were included into the analysis undifferentiated. In this case it was extremely obvious this was not really the case, because once the page started giving errors it basically stopped working at all; but this could be far less clear-cur, and the verdict has to be to remember to look at the number of errors first, and if there are any then bear this in mind in any interpretation of the figures and graphs. It would be useful if M-M could represent the errors in the results analysis, perhaps including them into the tabular stats, and offering graphs with the errors filtered out.

UPDATE 14th March 2012: now moved to http://testutils.org/multi-mechanize

Multi-Mechanize is an open source framework for API performance and load testing. It allows you to run simultaneous python scripts to generate load (synthetic transactions) against a web site or API/service. 

In your scripts, you have the convenience of mechanize along with the power of the full Python programming language at your disposal. You programmatically create test scripts to simulate virtual user activity. Your scripts will then generate HTTP requests to intelligently navigate a web site or send requests to a web service.

…

You should be proficient with Python, HTTP, and performance/load testing to use multi-mechanize successfully.

Installing Multi-Mechanize

First time around I got this horribly wrong, probably through not being proficient with…. actually my problem was installing Python 3.2 for Windows 64 bit; it turns out Multi-Mechanize only works with Python 2.6 and 2.7, and if you install the wrong version you get loads of syntax error messages; so I had to start again. Here is the correct sequence:

1. First install Python 2.7
   http://www.python.org/download/releases/2.7.2/ 
   specifically
   Windows X86-64 MSI Installer (2.7.2) [1](sig)
2. To install mechanize, download
   http://pypi.python.org/pypi/distribute#distribute-setup-py 
   and run 
   C:\Python27\python C:\blah\Downloads\distribute_setup.py
   then
   C:\Python27\scripts\easy_install mechanize
3. Install Numpy from http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy 
   specifically numpy-MKL-1.6.1.win-amd64-py2.7.‌exe [8.7 MB] [Python 2.7] [64 bit] [Oct 29, 2011]
4. Then install Matplotlib from http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib 
   specifically matplotlib-1.1.0.win-amd64-py2.7.‌exe [4.4 MB] [Python 2.7] [64 bit] [Oct 06, 2011]
5. Finally download Multi-Mechanize
   http://code.google.com/p/multi-mechanize/downloads/list
   and copy the unzipped folder somewhere (no installation).

Using Multi-Mechanize

It’s pretty simple. Use a command like this to start a session:

>c:\python27\python multi-mechanize.py testMySite

This refers to a “project” (in this case “testMySite”) which is a folder under \projects under your Multi-Mechanize folder.  To create a project I just copied and adapted the “default_project” that came in the download.

In the project folder there is a config.cfg text file that specifies some global settings and some details about what scripts to run on and how many simultaneous sessions to run. There is some sparse information on the config settings here: http://code.google.com/p/multi-mechanize/wiki/ConfigFile

You can specify any number of “user groups”, each representing one sequence of actions on your web site/service (e.g. loading the home page, or executing a search). Each user group is associated with a python script defining the actions. Each user group has a number of threads, i.e. virtual users attempting the sequence of operations.

TODO: insert some information about the actual Python script - how to perform simple and more complex operations on a web site.

The global settings include how long to run the test for, the time series interval for results analysis, and how long to “rampup” the number of users, presumably from one up to the maximum number of threads specified in the user groups. The ramp-up is to see within one test how the site performs under low and then progressively higher loads.

The results of the test are output into a folder below the project, with a time-stamped name like \results\results_2011.12.27_16.32.07

This contains the raw results as CSV, plus some graphs as PNG images, and an HTML page that brings the numbers and images together into a report.

Example tests

I ran simple tests on the following sites:

• www.esdm.co.uk (main exeGesIS web site built in DotNetNuke and running on one of our older Telehouse servers)
• www.esdm.no-ip.co.uk (draft replacement exeGesIS web site built in mojoPortal and running on our newer Telehouse hosting stack)
• www.breconfans.org.uk (a site I run at home, using mojoPortal on Arvixe hosting)
• www.wikipedia.org (a high availability global site as a control)

The test script simply loaded the home page and checked for some text on the page. I tested with two user groups undertaking the same actions, with 50 virtual users in each, ramping up throughout the 5 minute test period.

www.esdm.co.uk

Timer Summary (secs)

Interval Details (secs)

Graphs

Response Time: 30 sec time-series

Response Time: raw data (all points)

Throughput: 30 sec time-series

www.esdm.no-ip.co.uk

Timer Summary (secs)

Interval Details (secs)

Graphs

Response Time: 30 sec time-series

Response Time: raw data (all points)

Throughput: 30 sec time-series

www.breconfans.org.uk

Timer Summary (secs)

Interval Details (secs)

Graphs

Response Time: 30 sec time-series

Response Time: raw data (all points)

Throughput: 30 sec time-series

www.wikipedia.org

Timer Summary (secs)

Interval Details (secs)

Graphs

Response Time: 30 sec time-series

Response Time: raw data (all points)

Throughput: 30 sec time-series

Analysis

I am no expert in load testing, so I do not pretend to be able to analyse the results in any meaningful way. Looking to learn though…!

But bringing together the most significant statistics from these tests…

These identical tests put the web sites under heavy load, particularly after the first minute or so. It is clear that the two mojoPortal sites dramatically out-perform our old esdm.co.uk, with average response times of 2.9 and 2.2 seconds compared with 12.8 over the full test period. The reasons for this are far less clear though.  esdm.co.uk and esdm.no-ip.co.uk have about the same amount of content, but this is not really a fair comparison between DotNetNuke and mojoPortal, because esdm.no-ip.co.uk is running on faster servers. Also, we are running the latest version of mojoPortal (2.3.7.5) compared to an ancient version of DNN.

Interestingly the minimum response time was 0.48 for esdm.co.uk, significantly faster than the 0.78 seconds for breconfans.org.uk, perhaps because the latter is on US hosting meaning a longer round-trip regardless of other factors; esdm.no-ip.co.uk gave 0.21 seconds minimum, perhaps demonstrating the inherent responsiveness of our new hosting stack.

I was surprised that breconfans.org came out better under load than esdm.no-ip.co.uk, but I suspect this is because the latter is a much larger site, with hundreds of pages (and so a much larger mojoPortal database) compared to about 25 pages for breconfans.

Testing wikipedia was an afterthought, and of course it is not quite the same because it is always under heavy load; nonetheless it was reassuring to find that my mojoPortal sites performed better, and that the wikipedia performance also degraded through the test as more virtual users were added (though this does make me wonder whether some of the performance degradation is client-side, e.g. inherent bottle-neck in processing http requests in Windows?).

Conclusion

Multi-Mechanize was simple to set up and use (admittedly in a limited manner). It quickly demonstrates what kinds of load web sites can sustain before degrading.

More advanced configuration of the test scripts, e.g. to perform form-based operations, should be reasonably easy for our developers. This should give real power for load-testing our web applications.

Aside: I found when running the longer tests with lots of threads (e.g. 100) that the routine would not complete after the allotted time, and would stick saying “waiting for all requests to finish”.  Usually it would complete after a minute or two extra waiting. If not, no outputs were produced, but killing the python.exe process sometimes caused the output files to be created. This issue has been encountered by others, with no apparent resolution (e.g. http://groups.google.com/group/multi-mechanize/browse_thread/thread/706c30203c568d61)

and CGI install: http://blogs.iis.net/thomad/archive/2010/04/04/how-to-run-a-cgi-program-under-iis-7-0-or-iis-7-5.aspx

Note:  setting paths and env variables is not normally necessary and in fact can be dangerous on systems hosting multiple versions of mapserver  or related applications.

Getting MapServer to work on IIS7.5 Server 2008

For some reason there doesn't seem to be a lot of documentation on how to install MapServer on IIS7 +. This entry will only cover installation on Windows Server 2008 R2 SP1 (x64) with IIS 7.5.

1. First install Microsoft Visual C++ 2008 SP1 Redistributable Package (x86).Even though the machine is running Server 2008 (x64) the MapServer binaries that I am using is from MS4W which is for x86. (I have not tried to get the 64 bit version working yet).

2. From Server Manager select Roles and add the web server role with the following Role services: 
 

·                     Application Development

·                                             .NET Extensibility

·                                             CGI

·                                             ISAPI Extensions

3. Get the MS4W zip file (ms4w_3.0.1.zip)and extract it to the root directory, (i used C:\ms4w)

4. Following the instructions here, I created a separate folder (c:\MapServer) and copied the follow folders into this directory: c:\ms4w\Apache\cgi-bin, C:\ms4w\gdaldata, C:\ms4w\gdalplugins, C:\ms4w\proj and C:\ms4w\tools.

5. Copy the C:\ms4w\setenv.bat file into c:\MapServer and modify it as follows and then run it.

@ECHO OFF
 

set PATH=c:\MapServer\\cgi-bin; C:\MapServer\tools\gdal-ogr; C:\MapServer\\tools\mapserv; C:\MapServer\tools\shapelib; C:\MapServer\proj\bin; C:\MapServer\tools\shp2tile; C:\MapServer\tools\shpdiff; C:\MapServer\tools\avce00;
echo GDAL, mapserv, PROJ, and shapelib dll paths set

set GDAL_DATA=C:\MapServer\gdaldata
echo GDAL_DATA path set

set GDAL_DRIVER_PATH=C:\MapServer\gdalplugins
echo GDAL_DRIVER_PATH set

set PROJ_LIB=C:\MapServer\proj\nad
echo PROJ_LIB set

:ALL_DONE

6. Right click the C:\MapServer folder, go to the security tab and add the IIS_IUSRS account with Read & execute permissions.

7. In IIS create a new Website. I called mine Mapping and turned off the default Website. To get CGI working I used the instructions from here.

8. In IIS click on the machine node and select the "ISAPI/CGI restrictions" icon from the Feature view. Select Add and choose C:\MapServer\cgi-bin\MapServ.exe as the "ISAPI or CGI path" and tick the check box for "Allow extension path to execute".

9. In the Mapping website add a virtual directory (I called mine "cgi") and set the physical path to C:\MapServer\cgi-bin.
  
10. Select the newly created cgi virtual directory and select the "Handler Mappings" icon in the Feature view. Click the Edit Feature Permissions link in the action menu and check the box "Execute".

11. If you now navigate to http://localhost/cgi/mapserv.exe you should see the message:

No query information to decode. QUERY_STRING is set, but empty

which means you map server is up and running.

12. To try out a demo, I created C:\MapServer\apps\Sample directories and then added the example1-1.map file from "MapServer Itasca Demo Application". I also added a Data directory inside sample and added states_ugl.dbf, states_ugl.shp and states_ugl.shx into it. The paths in example1-1.map file needed to be updated to point to the right locations and then you can browse to it using 
http://localhost/cgi/mapserv.exe?map=C:/MapServer/apps/sample/example1-1.map&layer=states&mode=map

Hopefully these instructions may help somebody out. There maybe security issues with this setup so its up to you to figure it out and fix them.