Note:for an updated version of this and other articles, we recommend you to check our knowledge base here

How to optimize your GpsGate Server performance and user experience!

The first signs of that you have performance problems on your server is that the daily ErrorLog is full of "Waiting for a free connection timed out." messages. If you have a few now and then it is no harm, but if you have a constant stream you need to do something about it. Here is a list of things that will make your server run faster. Tips on how to improve the user experience are also included. Improved performance and user experience often go hand in hand!

Keep your server up to date. We constantly include new features, make optimizations and removes problems. By keeping your server up to date you will avoid running in to problems we have already solved. And you will have the best possible user experience.

Avoid Internet Explorer. Microsoft makes a lot of great software, but not a great browser GpsGate works using IE, but it is hard to avoid the fact that it is a very, very slow browser. For the best possible user experience it is recommend to use Firefox or Chrome. GpsGate will continue to support IE, but it is not the browser for the best user experience. If you "must" use IE, use IE9 or later.

Email reports instead of displaying them in the browser. Report data needs to be processed before a user can view a report. GpsGate process report data every night, which means that reports displayed for yesterday and earlier are fast. But to display a report for today requires data to be processed first. This can sometimes cause an annoying delay for the user.

Often it is a better approach to setup report to be emailed daily, weekly or monthly to the user. In this way the user always gets the right report at in a comfortable way. To setup reports to be emailed saves server resources, and gives a better user experience!

GPS tracker update rates. Do not set the update rates to a higher value than you actually need. If you setup the trackers to send a report more often than once every 60 seconds it is important that you read this about best practices for track recorders here: http://forum.gpsgate.com/topic.asp?TOPIC_ID=15055

Disable Event Rules Used for reporting only. In Step 1. of the Event Rules Wizard you can specify if the event rule will be used live (in real time), or only for v3.0 reports. You should set Enabled for all event rules you only use for reports to "No".

The Event Rule will now be marked with a red icon in the list. It will no longer be executed live, and can only be used in reports.

Use the "Offline reports" instead of "live offline events". If you are using the "Off line expression" to get a notification when a device is off line, for example an email or SMS, consider changing this to having a report emailed to the user daily which lists all off line incidents.

The live off line event rules consumes a lot of CPU and database resources. Using reports requires much less resources. The report also have the benefit of just getting one email per day which gives a summary you can take action on.

Keep tight control over user privileges. One common way of get your server overloaded is to give inexperienced user access to creating reports and event rules. They typically create too many.

If you use the old "Event Rule" method, you will typically get "Waiting for a free connection timed out." messages. In particular if your geocoder provider is slow.

Check which event rules consumes most resources. In the ProfilerLog you find under C:\GpsGateServer\ProfilerLog one new log file is created each day which writes down performance statistics about the server. There is a % which tells you how much resources an individual feature or operation consumes. You can for example see which live event rule in which applicaiton is a performance eater.

You also find a list under "CommandNotifier" which users receives most email and SMS notifications. If there are to many you might want to switch to an event report, or make the event rule less sensitive, see example about "Avoid to many speeding alarms" above.

And set the value MaxDatabaseConnections to the number of cores you have on your server.

If you installed your server Jan 2011 or earlier

Migrate from using v2.3 reports to using v3.0 reports. The older v2.3 reports are slow and eats up server resources. If you use 2.3 reports on your server the user interface will sometimes be unresponsive, and you can get a "yellow error message" back when the web server times out. 2.3 reports also makes NMEA Service slower.