XINS performances are regularly measured. An old article about XINS performance shows that XINS could be even faster than the competition.
The number of logs written per call is one of the important factor that can slow down or increase the performance of an API. You are advice to only log necessary messages.
Since XINS 3.1, GZip compressed data are also accepted. If not already done, you are adviced to configure the HTTP Server or the Servlet container to return compressed data.
If the Servlet container runs in a HTTP Server, it's better to configure the compression on the HTTP Server. For example for Apache server, use mod_deflate.
For Tomcat add to the server.xml
<Connector> element the following attributes:
compression="on" compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,application/xhtml+xml,text/javascript,application/json".
For Jetty, you need to add a
Servlet Filter. This is done in impl.xml
with the following code:
<web-app element="filter">
<web-app element="filter-name">GzipFilter</web-app>
<web-app element="filter-class">org.eclipse.jetty.servlets.GzipFilter</web-app>
<!-- <web-app element="filter-class">org.mortbay.servlet.GzipFilte</web-app> for Jetty 6-->
<web-app element="init-param">
<web-app element="param-name">mimeTypes</web-app>
<web-app element="param-value">text/html,text/xml,application/xhtml+xml,application/javascript,application/json</web-app>
</web-app>
</web-app>
<web-app element="filter-ampping">
<web-app element="filter-name">GzipFilter</web-app>
<web-app element="url-pattern">/*</web-app>
</web-app>For other servlet containers, you can add in a the Jetty filter by adding jetty library as dependencies and the code above or use the pjl-comp-filter project.
There are a lot for cases in web services where getting data is much often called than creating or updating data. For example, getting the data of the top 100 products of the catalog of getting the data of the currently logged users.
XINS 3.1 adds the possibility to specify how long the data for a
function could be cached on the client side. This is done by adding a
cache attribute to the
function element in the fnc
file. The value being the number of seconds that the result could be
cached.
<?xml version="1.0" encoding="US-ASCII"?> <!DOCTYPE function PUBLIC "-//XINS//DTD Function 3.1//EN" "http://xins.sourceforge.net/dtd/function_3_1.dtd"> <function name="FastData" cache="60"> ... </function>
If the client is a browser the data will be cached automatically in the browser cache.
To use the cache system for the XINS client API of with the XINSServiceCaller, you will need to set the CachingHttpClient in XINSCallConfig:
XINSCallConfig config = new XINSCallConfig(); config.setHttpClient(new CachingHttpClient(config.getHttpClient())); capi.setXINSCallConfig(config); // or in the XINSCallRequest: request.setXINSCallConfig(config);
Note that HttpClient cache is not included in XINS, so to use it you need to download it and add it to the dependencies.
HttpClient cache has support for advanced cache such as ehcache and memcache. You can then for example use a shared or distributed cache. If the same software is updating the data, you can remove the cache entry when after the update function is called.
There are also cases where data should be accurate but is not often updated. For example the price or availability of a product. In this case the server is returning all the time the same data, using unneeded resources such as CPU and bandwidth.
XINS 3.1 add the notion of returning not modified to the client. In this case the HTTP status code 304 is returned and no data is including in the body of the message.
To return not modified, just add return new
NotModifiedResult(); in the implementation class when you know
that the result is identical to the last request of the same
client.
On the client side, a isNotModified()
method has been added to XINSCallResult.
For the CAPI a NotModifiedException (which
extends XINSCallException) will be thrown.