If you are looking for DotKernel 3 related posts, go here.
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.
WURFL has cache providers for APC and memcache as well, which we’ve tried, but the results weren’t impressive.
We realized that we had the wrong approach, especially for use. The WURFL entry for a device has lots of fields that we didn’t use.
Our solution involved adding a second cache layer, on top of WURFL’s, that only cached the fields we were interested in. This second cache layer make use of APC, storing arrays of data in User Cache Entries.
This small change (under 10 lines of code), decreased our response time by an order of magnitude, to 20-30ms.
Looking for PHP, Laminas or Mezzio Support?
As part of the Laminas Commercial Vendor Program, Apidemia offers expert technical support and services for:
Leave a Reply