This page is intended for discussion of the Trackwork Server with a focus on issues and concerns of scalability, performance, maintenance and day to day operations.

After a few weeks of testing with the Vasco Road/Teichert job we are closing in on 3 million GPS data points all in one database table. It makes me wonder how the product will scale if we have several of these jobs running in parallel on several systems. Since all the GPS data lives in the database it would be hard if not impossible to rebuild the DB if it were to become corrupt. We could try and fallback to a backup (are we running backups)?

No backups - Mike Clapp

If we re-implement the server I would think moving to a system where the GPS data was stored external to the database might not be a bad idea. In fact, having all the data written to the filesystem first as primary storage then inserted into the database for application access might be a better solution. This would allow us to re-build the database from raw data at any time.

There are several performance issues with the current system mostly surrounding the fact that database access is unbounded. There is no throttling or concept of locking/transactions surrounding the update of data for a single device. I created a bug that caused the server to become overloaded and slow to respond. The TMMs responded by constantly dropping the connection and trying to reload their data. This caused the server to try and process multiple requests simultaneously from a single device for the exact same data! Suffice to say…this caused some problems.

At the very least any re-implementation should take into consideration the following:

1. Throttling of connections so as not to overwhelm the database.
2. Transaction support in case an operation fails part way through an update
3. Transaction/locking support so that multiple operations on the data for a single device are protected.

64 bit Vista compatibility has tested ok on view and download as of V 2.05C (4-10-09).

• should test upload (G-ray)

1. Unit Tests
   1. Full suite of unit tests to support regression testing
   2. App to simulate a TMM for unit testing, error injection and load testing.

Basic administration tasks are not addressed by the C implementation. A Java administration tool has been written to address a few of the basic tasks such as customer creation, removal and module configuration and assignment. Following is a list of items that are not covered or require manual configuration:

1. Project archiving (Backup)
2. Server version upgrade per customer
3. Load balancing/moving customer data to new servers
4. Firewall port allocation and configuration
5. More robust logging
   1. Log for each TMM per customer
   2. Log file rolling (log files are currently unbounded)
   3. Improved log messages

This is the current Trackwork functionality. It does not have the API functions being called and that should probably be added. These are all currently contained within the Server Tab of the Import dialog with the exception of Upload.

• Delete Project (RM menu)
• Add (Name, Description(O), Bounds(O), Start Date)
• Modify (Name, Description, Status (inop), Bounds, Start Date)
• Delete Project (Button)

• Partial download of tracks from a single project

• Read Tracks
• Download Points (based on selected tracks)
• Delete (RM Menu)
• Move to other Projects)
• Select (and Download)

• Add New Vehicle
• Rename Vehicle
• Delete Vehicle
• Assign to GPS Device (Association)
  • Set Time Range
• Modify Time on Association
• Delete Association

• Upload Tracks