RocketModule - tuning http://rocket.local/categories/tuning en Speeding up Drupal Forums http://rocket.local/blog/speeding-drupal-forums <div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>The Drupal forum.module has become, well, somewhat infamous for less than awesome scalability. Recently I had a chance to see this firsthand, and track down a solution for managing the long page load times for a <a href="http://wallstreetoasis.com">client</a> who has a highly trafficked forum. This was not a case of a site that was un-tuned - actually this particular site had a lot of good work and performance enhancements already done to it, including block caching and even some modifications to the forum module that were allowing to work better than it would have without them. But still 5-6 second page load times on /forum persisted.</p> <p>As this was my first time working on the site, I began by reviewing all of the main configuration files for Apache, MySQL, and PHP, since they are the foundation for everything else. After making some adjustment there, I headed over to the Drupal admin interface and check /admin/setting/performance/ and made sure all was happy there as well. Finally, I went to the block admin page and double-checked all of the blockcache settings, which as it turns out were set a bit to aggressively, resulting in slow form submission times (every time anyone submitted anything a gazillion blocks were being re-cached whether they need to be or not).</p> <p>With the foundation of the site now looking good and everything, except the forum pages flying along (and the tracker, but that's a story for a later article) - it was just down to forum.module.</p> <p>Here are the steps that led to cutting the page load time in half from what they were:</p> <p>1. Disable the forum.module, rename it to something like "forum.module.orig", make a copy and then rename the copy "forum.module".</p> <p>2. Download the <a href="http://drupal.org/project/advcache">advcache module</a> and apply the forum patch includes to your new copy of the forum.module.</p> <p>3. If want the cleanest solution and are comfortable with coding/debugging at all, instead of just copying the forum module and working on it directly (and thus having a hacked Drupal core file around all the time) - name the copied file something completely different than forum.module and edit all of the hook/function calls with in it with new name and place it where you keep the rest of your contributed modules.</p> <p>4. (Note: this step is an option only if all your forums are public)<br /> Open the module and remove all references to db_rewrite_sql. This will keep Drupal from doing a lot of expensive and uneccesary queries in order to check access rights. (<a href="http://2bits.com/articles/how-drupals-nodeaccess-table-can-negatively-impact-site-performance.html">thanks Khalid</a>)</p></div></div></div><div class="field field-name-taxonomy-vocabulary-1 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Categories:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/categories/drupal" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Drupal</a></div><div class="field-item odd"><a href="/categories/mysql" typeof="skos:Concept" property="rdfs:label skos:prefLabel">MySQL</a></div><div class="field-item even"><a href="/categories/performance" typeof="skos:Concept" property="rdfs:label skos:prefLabel">performance</a></div><div class="field-item odd"><a href="/categories/tuning" typeof="skos:Concept" property="rdfs:label skos:prefLabel">tuning</a></div><div class="field-item even"><a href="/categories/forums" typeof="skos:Concept" property="rdfs:label skos:prefLabel">forums</a></div></div></div> Thu, 28 Feb 2008 18:41:41 +0000 Caleb Gilbert 71 at http://rocket.local http://rocket.local/blog/speeding-drupal-forums#comments Drupal 6: Benchmarking and Block Cache Performance Revisited http://rocket.local/blog/drupal-6-benchmarking-and-block-cache-performance-revisited <div class="field field-name-body field-type-text-with-summary field-label-hidden"><div class="field-items"><div class="field-item even" property="content:encoded"><p>As a follow up to an <a href="http://highervisibilitywebsites.com/drupal-6-performance-and-developer-drupal-release">earlier article</a> I posted about Drupal 6 performance, and please bear with my learning curve for a moment, I figured out by 'accident', and a lot of investigation, that it matters very much the order one uses when they 'generate content' with the devel module for benchmarking purposes. My previous tests were done incorrectly - I inadvertently created a bunch of nodes that weren't assigned to any terms or users and vice versa. The result of correcting this error means that a no-cache-enabled-baseline takes much longer to complete than when I had things setup incorrectly.</p> <p>...happily, the point of this article isn't that I'm a total goof.</p> <p>No, the good news out of this ordeal is that now when block-cache-disabled performance is compared to block-cache-enabled performance the results are MUCH more substantial than previously noted (and thus Drupal 6 is going to be that much faster than it's predecessor Drupal 5 for authenticated users):</p> <blockquote><p>2489.69 ms (request time for auth user, no-caching of any kind)<br /> -878.09 ms (request time for auth user, block-caching on)<br /> --------<br /> 1,611.6 (difference) / 2489.69 =<br /><strong>64.73% improvement w/ block cache on</strong> </p></blockquote> <p>With the block caching on, the mean processing time is 876 ms with a sd of 91.9 ms while the base install results in 2481 ms mean processing time and sd of 91.9. Even at the upper end of the standard deviation, the block-cached processing time is 967.9 ms, which is far below the low end of the standard deviation (2080.1 ms) for the non-block-cached test. Looks like a clear improvement - 64.7 percent improvment using just the means.</p> <p>The benchmarks are posted here so that everyone can do their own math. If you'd like to check the validity of my installation/numbers - feel free to download a tarball which includes all the <a href="http://highervisibilitywebsites.com/downloads/benchmark-files.tgz">files</a> and a <a href="http://highervisibilitywebsites.com/downloads/benchmark-db.sql.tgz">db dump</a>. Username/pass for user 1 = superadmin</p> <p><strong>BENCHMARKS</strong></p> <p>Benchmarks using 10,000 nodes, 5000 comments, 15 categories, 250 terms, 2000 users and with the following blocks enabled:</p> <div class="codeblock"><code>BLOCKS ENABLED<br />Recent comments  <br />User login <br />Navigation <br />Active forum topics <br />New forum topics <br />Who's online</code></div> <p>=====</p></div></div></div><div class="field field-name-taxonomy-vocabulary-1 field-type-taxonomy-term-reference field-label-above"><div class="field-label">Categories:&nbsp;</div><div class="field-items"><div class="field-item even"><a href="/categories/drupal" typeof="skos:Concept" property="rdfs:label skos:prefLabel">Drupal</a></div><div class="field-item odd"><a href="/categories/performance" typeof="skos:Concept" property="rdfs:label skos:prefLabel">performance</a></div><div class="field-item even"><a href="/categories/block-cache" typeof="skos:Concept" property="rdfs:label skos:prefLabel">block cache</a></div><div class="field-item odd"><a href="/categories/tuning" typeof="skos:Concept" property="rdfs:label skos:prefLabel">tuning</a></div></div></div> Mon, 13 Aug 2007 01:49:17 +0000 Caleb Gilbert 59 at http://rocket.local http://rocket.local/blog/drupal-6-benchmarking-and-block-cache-performance-revisited#comments