Friday. Log Out! Shut down! Get out!

Locale cache in memory for Drupal

March 8, 2011by Adrian Șchiopuin DevelopmentNo Comments

A few months ago, due to the week performance of the Amazee application for some pages, the need for a speed improvement came up. So, we tried to think about some ways of improving the overall speed of the Amazee site. A very good idea came from Liviu: caching the locale in memory. The locale functionality is one or maybe even the most used in the Amazee application, and in general in all Drupal based sites so a good way of caching the localization strings is vital for a good speed of the application. This was even more vital in this case, because at the moment, in Amazee there are over 3500-4000 strings. Also, at the moment there are 2 languages enabled, but the number could increase.
As I mentioned, a good way of caching this data is vital.

The default Drupal cache is stored in database, and after the first load of the cache, this is stored in a static variable. But there is still the need to access the hard-disk in order to retrieve the locale data. This cache is also good, without it any Drupal application that uses the locale functionality will have actually a bottleneck due to it.  So, a much better way of storing the locale cache is the RAM. RAM is much much faster than the hard-disk. The access time for RAM is measured on the order of 10ths of nanoseconds, while the access time is measured on the order of milliseconds. So, we could approximate that the RAM is over 100 thousands time faster that the hard-disk ( – this is an old article, but the proportions of the numbers are almost the same today)

So, I made an implementation of this feature, and now the locale for Amazee is cached in RAM. For this, I used the concept of shared memory ( Basically, it is about a block memory where I put a serialized version of the locale. Because it is a shared memory, that means that any application that knows a certain key, can access that block. So, there is no need to fetch the locale from database anymore, because the RAM is not flushed between multiple requests, so no access to the lazy hard-disk is made. For 4000 strings, in two languages, that means a total of 8000 (a rough approximation), the size of the block varies between 600 and 700 KB, which is not a very big value.

The speed improvement is very good. For the “Dashboard” page, for the “All projects” option the PHP script is now faster with 30-40% (from ~1.7 seconds to ~1.3 seconds). Of course, this depends on each page, but as far as I have seen until now, on almost each page, the script is faster with ~0.4 seconds. I would say this is quite a big value, if we talk about the speed at the script level.

Adrian Șchiopu

What do you think?