Increase performance of caching
Dear Developers, I’ve been working with a few modifications to the caching system of Drupal, and have found a simple way to speed it up by about 5% across the board ( more with pages that use the cache system more) with only adding five lines of code. I found that Drupal was calling the cache table multiple times to get the same data so I put the data in a static array. At the top of cache_get function in includes/cache.inc I added these four lines on line 15: static $cache_array = array(); if ($cache_array[$key] != null){ return $cache_array[$key]; } Right before $cache is returned I added this line on line 45: $cache_array[$key]=$cache; I am sure there are lots of other ways to do this, but the reason that I modified the core code directly is that I felt that this type of increase should not a matter of adding a new module, if it is even possible with another module. Although this will increase the overall size of the apache children during runtime I felt that it was a small price for the speed of the application and overall user throughput. Also are there any other places that we could do something similar. For instance cache the menus in memory for the ‘drupal_lookup_path’ for instance. Because this is in the caching for registered and anonymous users the benefit is across the board. Although the increase will diminish over the size of the site, it should be a rather substantial increase for about 70-80% of the drupal installs out there. I am curious to hear feedback as to what you guys think of this addition, and the overall speed increase and offsets. And potentially other increases that would be of similar avenues and if we should pursue them. Thanks Jeff Fillmore HYPERLINK "mailto:jfillmore@sublimenet.com"jfillmore@sublimenet.com Sublimenet INC 208-323-9451 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.2/781 - Release Date: 4/30/2007 9:14 AM
Hi Jeff - Do you have any benchmarking data to demonstrate how you arrived at the 5% figure?
On 30 Apr 2007, at 19:22, Jeff Fillmore wrote:
I’ve been working with a few modifications to the caching system of Drupal, and have found a simple way to speed it up by about 5% across the board ( more with pages that use the cache system more) with only adding five lines of code.
That's interesting, Jeff. Are you using a stock Drupal installation? I'm wondering what these duplicate cache lookup (or queries) are ... do you happend to have a list of those? -- Dries Buytaert :: http://www.buytaert.net/
That's interesting, Jeff. Are you using a stock Drupal installation? I'm wondering what these duplicate cache lookup (or queries) are ... do you happend to have a list of those?
Dries, I'm using a stock installation. Here is the list (This is taken from the http://www.example.com/node): variables 0:en views_with_inline_args:en content:45:45 1:d41d8cd98f00b204e9800998ecf8427e content_type_info fieldgroup_data fieldgroup_data fieldgroup_data fieldgroup_data content:41:41 1:d41d8cd98f00b204e9800998ecf8427e fieldgroup_data content:40:40 1:8eab40327f397b49b80fd45500fb61ce fieldgroup_data content:39:39 fieldgroup_data content:38:38 1:d41d8cd98f00b204e9800998ecf8427e fieldgroup_data content:37:37 1:d41d8cd98f00b204e9800998ecf8427e fieldgroup_data fieldgroup_data As you can see fieldgroup_data is called 10 time, and 1:d41d8cd98f00b204e9800998ecf8427e is called 4 times Thanks Jeff Fillmore jfillmore@sublimenet.com Sublimenet INC 208-323-9451 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.2/782 - Release Date: 5/1/2007 2:10 AM
i think "stock" in this case refers to plain drupal core. every duplicate query you listed comes from a contributed module. it is quite possible that the right fix is in those modules, and not in cache layer. fieldgroup particularly needs a cleanup. -moshe On May 1, 2007, at 5:21 PM, Jeff Fillmore wrote:
That's interesting, Jeff. Are you using a stock Drupal installation? I'm wondering what these duplicate cache lookup (or queries) are ... do you happend to have a list of those?
Dries, I'm using a stock installation. Here is the list (This is taken from the http://www.example.com/node):
variables 0:en views_with_inline_args:en content:45:45 1:d41d8cd98f00b204e9800998ecf8427e content_type_info fieldgroup_data fieldgroup_data fieldgroup_data fieldgroup_data content:41:41 1:d41d8cd98f00b204e9800998ecf8427e fieldgroup_data content:40:40 1:8eab40327f397b49b80fd45500fb61ce fieldgroup_data content:39:39 fieldgroup_data content:38:38 1:d41d8cd98f00b204e9800998ecf8427e fieldgroup_data content:37:37 1:d41d8cd98f00b204e9800998ecf8427e fieldgroup_data fieldgroup_data
As you can see fieldgroup_data is called 10 time, and 1:d41d8cd98f00b204e9800998ecf8427e is called 4 times
Thanks
Jeff Fillmore jfillmore@sublimenet.com Sublimenet INC 208-323-9451
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.6.2/782 - Release Date: 5/1/2007 2:10 AM
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Fillmore schrieb:
That's interesting, Jeff. Are you using a stock Drupal installation? I'm wondering what these duplicate cache lookup (or queries) are ... do you happend to have a list of those?
Dries, I'm using a stock installation. Here is the list (This is taken from the http://www.example.com/node):
variables 0:en views_with_inline_args:en content:45:45 1:d41d8cd98f00b204e9800998ecf8427e content_type_info fieldgroup_data fieldgroup_data fieldgroup_data fieldgroup_data content:41:41 1:d41d8cd98f00b204e9800998ecf8427e fieldgroup_data content:40:40 1:8eab40327f397b49b80fd45500fb61ce fieldgroup_data content:39:39 fieldgroup_data content:38:38 1:d41d8cd98f00b204e9800998ecf8427e fieldgroup_data content:37:37 1:d41d8cd98f00b204e9800998ecf8427e fieldgroup_data fieldgroup_data
As you can see fieldgroup_data is called 10 time, and 1:d41d8cd98f00b204e9800998ecf8427e is called 4 times
1:d41d8cd98f00b204e9800998ecf8427e is probably a filtered value (check in the cache_filter table). Caching makes probably sense in this case. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGN7uufg6TFvELooQRAtp2AKC+VuHUBdQbVvsZcUkWg3EVJx/pVACcDrtz anaKsEkrFlzz7yrE//MJPYQ= =AYz6 -----END PGP SIGNATURE-----
participants (5)
-
Dries Buytaert -
Gerhard Killesreiter -
Jeff Fillmore -
Moshe Weitzman -
William Smith