The Z-GPRS3, made and distributed by the Italian Seneca company, is a state-of-the-art logging and control device which has the possibility to report via a GPRS interface. Reporting is based on modern technology which means for communications that the report shown in the browser window will update periodically without refreshing the entire webpage. The technology behind that is provided by a library called jQuery

When looking at the reports via internet we were observing quite a long initial load time. After that time of up to 3 minutes, the reports would function perfectly well without any further waiting required.

This made us look at the web trace within a conventional web browser. As you can see by the screenshot, there are three large files being loaded before the requests will begin. The loading is quite time consuming.

The three files are static files which might only change when the firmware of the Z-GPRS3 would be updated. So, our first thought was what about if we put these three files onto another server (with a better connection) and just load them before loading the constant figures for the reports.

By the first attempt, we had failed for what is called the same origin policy – for security reasons, the data has to come from the same server as from where the script is being loaded.

What to do now? One option is to upgrade the connection for Seneca to something like LTE. For us, this would have had the drawback of consuming more energy in a solar-powered, autonomous environment.

The other way is to connect the Seneca device via an intermediate server which will control loading from different sources. We have decided to run an Apache Webserver in reverse proxy mode so that all requests from the client will be routed via that web server to the Seneca device. Up to that part, the architecture has not been changing much.


But as soon as there is a server in between, it is possible to alter the means of loading for specific addresses.
So what we have done is to place the files in question to a publicly accessible directory on a public webserver and to tell the intermediate apache server to redirect the loading of these files from another directory on the same (! Important) server.

Coming that way, requests for these large files will never hit back to the Seneca device, but the requests for the individual measurements will be routed to the GPRS device every time.

Happy measuring!

Tame the beast – How to increase the performance of Seneca’s Z-GPRS3