If you have configured Apache as a web server in front of the Tomcat application server for ExtraView, you will have configured a minimum of two JkMount lines.

JkMount /evj/ExtraView tomcat1
JkMount /evj/ExtraView/* tomcat1

When configured in this manner, all requests flow through Apache and to the Tomcat identified as tomcat1 in the worker.properties file.  This Tomcat may be a single tomcat, or it may be a loadbalanced set of Tomcat application servers.

If you have multiple Tomcat instances configured, another option you can implement, simply by changing the configuration here, is to route all API requests – including Perforce or SalesForce integration requests – to a particular Tomcat instance.

All other requests – which are generally the interactive end-user requests through their browser – will be routed though another Tomcat instance (or set of loadbalanced Tomcats).

To implement this, we take advantage of the fact that we can identify all API requests based on the parameters that will be appended to the URL.  All ExtraView API requests match the pattern “/ExtraView/ev_api.action” so we can configure the JkMount configuration such that all requests that match this pattern, are directed to a particular tomcat:

JkMount /evj/ExtraView/ev_api.action tomcat2
JkMount /evj/ExtraView/0* tomcat1
JkMount /evj/ExtraView/1* tomcat1
JkMount /evj/ExtraView/2* tomcat1
JkMount /evj/ExtraView/3* tomcat1
JkMount /evj/ExtraView/4* tomcat1
JkMount /evj/ExtraView/5* tomcat1
JkMount /evj/ExtraView/6* tomcat1
JkMount /evj/ExtraView/7* tomcat1
JkMount /evj/ExtraView/8* tomcat1
JkMount /evj/ExtraView/9* tomcat1
JkMount /evj/ExtraView/evSignon tomcat1
JkMount /evj/ExtraView tomcat1
JkMount /evj/ExtraView/ tomcat1

With the above configuration, all requests that end in “/evj/ExtraView/ev_api.action” will be routed to tomcat2 – and all other possibilities for URL requests are then itemized, and routed to tomcat1.

Why do this?

In many cases, API requests are generated programmatically, hit the server often and potentially quite hard in a regular pattern.  The Perforce and SalesForce daemons are a good example – they “hit” the application every 10 seconds or so, to poll the system and see if there is any work to do.  Data warehouse integrations can perform large queries to pull back all the changes to all tickets in the last 12 or 24 hours.  Subversion integrations can have a trigger than runs every night to close all tickets that have been open and untouched in more than 30 days.

End users of the human variety, on the other hand, are much more unstructured in their use of the application, and tend to access the tool in a less systematic way . Because they are staring at the screen, waiting for a response to their mouse click, end users are also more sensitive to any delays than a script or daemon.

By splitting out the workload in this way, we can reduce the potential effect of any API calls on the response time for your end users who are interacting with ExtraView through the forms and screens – which makes for happier users!

You can also accomplish the same thing by providing different URLs for daemons and API users – but this method allows you to publish a single URL to access ExtraView, and still retain the option of splitting API traffic – either now, or in the future.