Setting the per user limit is nice, but you may want to have a more fine-grained control on how requests are processed by GeoServer. For instance, you may want to have some service, for example, WMS, be given priority over WFS or WCS.
The control flow module lets you set specific limits for each service and you can also configure limits at the request-type level, as we will do in this recipe.
In this recipe, we need to test the control flow module against a higher number of concurrent requests. Unless you're running this recipe on a GeoServer production site, where several real users run ten or more requests each second, you may find it difficult to send many requests by your browser just interactively.
Hence, I want to introduce you to an open-source tool that can help you in creating a stress test. Although there are many similar tools available, JMeter is the most famous and probably the simplest one to use.
JMeter is an open source project from the Apache foundation (http://jmeter.apache.org/). The installation is really easy; it being a Java ™ application, you just need to have a JDK or JRE installed on the same machine. If you're going to use the same machine that hosts GeoServer, that is a nice idea; you of course have already installed a Java ™ environment.
So download a recently released archive, at the time of writing Version 2.11 is the latest, from http://jmeter.apache.org/download_jmeter.cgi. Then, extract the files to a folder and you are done.
Note
JMeter is a desktop application with a clean and powerful interface. In this recipe, you will be only asked to use a test suite we created for you, but you may be interested in exploring its features. If this is the case, we want to point you to two extremely useful sources of information:
First of all, the official project documentation that you may find online at http://jmeter.apache.org/usermanual/index.html.
Secondly, if you are more comfortable with books, you can refer to Performance Testing with JMeter 2.9, Packt Publishing.
- Using your favorite text editor, open the previously created
controlflow.propertiesfile and modify its content according to the following snippet:# Maximum number of concurrent requests to all services ows.global=30 # Maximum number of concurrent WMS GetMap requests ows.wms=20 # Maximum number of concurrent WCS GetCoverage requests ows.wcs=4 # Maximum number of concurrent WFS GetFeature requests ows.wfs=6 # Maximum number of concurrent requests per user user=6
- Now save the file, close it, and then restart GeoServer.
- From the Packt site for this book (https://www.packtpub.com/hardware-and-creative/geoserver-cookbook), download the
ch08_workflowTest.jmxfile and save it to a folder on the same machine where you installed JMeter. - Launch JMeter using the
jmeter.batorjmeter.shscript according to your operating system. - From the File menu, select Open, and browse for the folder where you saved the JMX file. You should see a test suite loaded in JMeter, as shown in the following screenshot:
- Start the test suite by selecting the item Run, and then click on Start from the JMeter menu.
- Open the
geoserver.logfile. If the control flow is running properly, you should see many rows similar to the following:2014-06-18 23:11:11,577 INFO [geoserver.flow] - Running requests: 9, processing through flow controllers: 0 2014-06-18 23:11:11,862 INFO [geoserver.flow] - Running requests: 7, processing through flow controllers: 0 2014-06-18 23:11:11,683 INFO [geoserver.flow] - Running requests: 8, processing through flow controllers: 0 2014-06-18 23:11:12,216 INFO [geoserver.flow] - Running requests: 6, processing through flow controllers: 0 2014-06-18 23:11:12,268 INFO [geoserver.flow] - Running requests: 5, processing through flow controllers: 0 2014-06-18 23:11:12,439 INFO [geoserver.wms] - Request: getServiceInfo
When you run the test suite, especially if JMeter is on the same machine where GeoServer is installed, you would have surely seen a lot of CPU activity. In fact, this test runs many requests on GeoServer.
In the test suite, there is an element called Thread Group; if you click on it in the tree view, the right panel shows its content, as shown in the following screenshot:
The Number of Threads (users) field is where you set the number of concurrent users you want to run in the test suite, 10 in this case. The Ramp-Up Period (in seconds) field is the time JMeter takes to reach the full number of concurrent users. You may set a longer time duration if you experience problems with your machine, as starting many concurrent threads is very challenging for your system.
The Loop count field is the number of times the test suite has to be repeated; this may prove useful when you want to test the reliability of a system in the long run.
In our test, we simulate 10 users sending all the requests 10 times. In fact, as the test starts, you may control how many users are running from the JMeter toolbar; to its right end, there is a control that shows you the running / total number of users, as shown in the following screenshot:
Just under the Thread Group item, there is another element, the User Defined Variables item. It is a place where you can set values common to all the requests inside your test; it is a convenient way to change them easily according to your needs, as shown in the following screenshot:
We use two variables: one for the hostname of the server where GeoServer is installed and one for the TCP port. You may want to change them if, for instance, you're running JMeter from a different machine.
Then, there are a set of HTTP Request items, each named with a string referring to what the request is designed for.
The first one is WMS-World, which unsurprisingly send a WMS GetMap request asking for a full extent view of the NaturalEarth:blueMarble layer.
In the preceding screenshot, we can see the two variables defined before, for hostname and port, and a path for the request. Then, a set of parameters define exactly what we want GeoServer to represent in this map.
You may browse the other requests to check the differences.
The bottom element, called View Results Tree, is a fundamental one to control if all is okay with your test. As requests are fulfilled by GeoServer, the results are listed in this control, with a green icon for the successful entries and a red one for the errors.
When you click on an item in the right panel, you can see all the details about the request performed, the response from GeoServer, and also the data itself, for example, a map for a WMS request or GML code for a WFS request.
I hope this brief tour raised your curiosity about this wonderful tool. When you're in need of performing a functional or performance test on a web service, JMeter is your friend!