On one of our recent projects that used WURFL, response time was an important factor. Profiling revealed that the greatest chunk of response time (up to a few hundred milliseconds) was taken up by WURFL. We realized that its default filesystem cache was too slow for our needs, especially with a relatively high traffic application.
If you're not familiar with how WURFL's caching works, here's a brief introduction:
- The device data is stored at first in a large, zipped XML file, with one entry for each device.
- When first called, WURFL unzips the file and reads each device entry.
- It then serializes the data and writes it to the cache, using and MD5 signature for the file name (or key name if the cache is not on the filesystem)
- When a user agent is looked up, its MD5 signature is computed and then searched in the cache.
- For a number of reasons, the data in the data file is stored as a tree, each device being a node and inheriting all the properties of the nodes above it. So, for each look-up, a number of files have to be read and their capabilities merged to get all the capabilities of the requested device.