<br><br><div><span class="gmail_quote">On 5/1/07, <b class="gmail_sendername">Jeff Fillmore</b> <<a href="mailto:jfillmore@sublimenet.com">jfillmore@sublimenet.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dear Developers,<br><br>I got some requests for the Benchmarks on the changes that I made to the caching so here are the benchmarks:<br><br>Before:<br>Queries: 113 DB time: 120ms Page Execution Time: 495ms<br>Memory:
11.4 / 12.17<br><br>After:<br>Queries: 102 DB time: 105ms Page Execution Time: 484ms<br>Memory: 11.41 / 12.29</blockquote><div><br>I would be interested in the same benchmark but with MySQL <br>restarted before each run, to eliminate any query cache effects.
<br></div><br>It seems there is some overhead in PHP now that offset the 15 ms <br>gain in database access, and made that 11 ms gain out of 495 (only<br>2% gain).<br><br>Memory usage is a tad higher, but not significantly.
<br><br>Try using ab or ab2 with 500 requests and 5 concurrency, to see if <br>that adds up for multiple requests or what.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Let me know what you think and it would be nice to get some feed back from some other test sites. This data help me to know if I should continue on this path.<br><br>Thanks<br><br>Jeff Fillmore<br><a href="mailto:jfillmore@sublimenet.com">
jfillmore@sublimenet.com</a><br>Sublimenet INC<br>208-323-9451<br><br>-----Original Message-----<br>From: <a href="mailto:development-bounces@drupal.org">development-bounces@drupal.org</a> [mailto:<a href="mailto:development-bounces@drupal.org">
development-bounces@drupal.org</a>] On Behalf Of Larry Garfield<br>Sent: Monday, April 30, 2007 12:28 PM<br>To: <a href="mailto:development@drupal.org">development@drupal.org</a><br>Subject: Re: [development] Increase performance of caching
<br><br><br>Drupal uses a lot of static caching, so in concept I don't see a problem with this. Benchmarks would be useful, though, both on speed and memory usage.<br><br>That said, this should be submitted as a feature request patch against Drupal 6 so that it can be reviewed in the issue queue rather than on the dev list. See:
<br><br><a href="http://drupal.org/node/320">http://drupal.org/node/320</a><br><a href="http://drupal.org/patch/create">http://drupal.org/patch/create</a><br><br>Thanks!<br><br>--Larry Garfield<br><br>On Mon, 30 Apr 2007 11:22:04 -0600, "Jeff Fillmore" <
<a href="mailto:jfillmore@sublimenet.com">jfillmore@sublimenet.com</a>> wrote:<br>> Dear Developers,<br>><br>><br>><br>> I've been working with a few modifications to the caching<br>> system of Drupal, and have found a simple way to speed it up by about 5%
<br>> across the board ( more with pages that use the cache system more) with<br>> only adding five lines of code.<br>><br>><br>><br>> I found that Drupal was calling the cache table multiple times
<br>> to get the same data so I put the data in a static array.<br>><br>> At the top of cache_get function in includes/cache.inc I added these four<br>> lines on line 15:<br>><br>><br>><br>> static $cache_array = array();
<br>><br>> if ($cache_array[$key] != null){<br>><br>> return $cache_array[$key];<br>><br>> }<br>><br>><br>><br>> Right before $cache is returned I added this line on line 45:
<br>><br>><br>><br>> $cache_array[$key]=$cache;<br>><br>><br>><br>> I am sure there are lots of other ways to do this, but the reason that I<br>> modified the core code directly is that I felt that this type of increase
<br>> should not a matter of adding a new module, if it is even possible with<br>> another module. Although this will increase the overall size of the apache<br>> children during runtime I felt that it was a small price for the speed of
<br>> the application and overall user throughput. Also are there any other<br>> places that we could do something similar. For instance cache the menus in<br>> memory for the 'drupal_lookup_path' for instance.<br>
><br>><br>><br>> Because this is in the caching for registered and anonymous users the<br>> benefit is across the board. Although the increase will diminish over the<br>> size of the site, it should be a rather substantial increase for about
<br>> 70-80% of the drupal installs out there.<br>><br>><br>><br>> I am curious to hear feedback as to what you guys think of this addition,<br>> and the overall speed increase and offsets. And potentially other
<br>> increases that would be of similar avenues and if we should pursue them.<br>><br>><br>><br>><br>><br>> Thanks<br>><br>><br>><br>> Jeff Fillmore<br>><br>> HYPERLINK "mailto:
<a href="mailto:jfillmore@sublimenet.com">jfillmore@sublimenet.com</a>"<a href="mailto:jfillmore@sublimenet.com">jfillmore@sublimenet.com</a><br>><br>> Sublimenet INC<br>><br>> 208-323-9451<br>><br>>
<br>> No virus found in this outgoing message.<br>> Checked by AVG Free Edition.<br>> Version: 7.5.467 / Virus Database: 269.6.2/781 - Release Date: 4/30/2007<br>> 9:14 AM<br>><br>><br>><br><br><br>No virus found in this incoming message.
<br>Checked by AVG Free Edition.<br>Version: 7.5.467 / Virus Database: 269.6.2/781 - Release Date: 4/30/2007 9:14 AM<br><br><br>No virus found in this outgoing message.<br>Checked by AVG Free Edition.<br>Version: 7.5.467 / Virus Database:
269.6.2/782 - Release Date: 5/1/2007 2:10 AM<br><br></blockquote></div><br><br clear="all"><br>-- <br><a href="http://2bits.com">2bits.com</a><br><a href="http://2bits.com">http://2bits.com</a><br>Drupal development, customization and consulting.