We were recently approached by a non-profit site that runs on Drupal.
Their major complaint was that the "content on the site does not show up". The other main complain is that the site is very slow.
Diagnosis First ...
In order to troubleshoot the disappearing content, we created a copy of the site in our lab, and proceeded to test it, to see if we can replicate the issues.
The site is on the heavy side, with 210 modules and themes enabled. The site uses the Domain Access to server multiple sites from the same Drupal instance, each with its own sub-domain. It also has a full e-commerce store using Ubercart. And of course, other widely used modules are on the site, including Panels, Views and Organic Groups.
We found that indeed, on many pages of the site, the content did not show up. That is, anything in the "Content" region of the theme did not show up. Also, some other blocks were not showing as well.
Investigating further revealed the main issues was a totally inefficient way the site was developed: many pages were created as blocks (instead of nodes), all of them in the "Content" region. Then the Block Visibility setting is set to a different URL for each page.
Because of the way Drupal processes blocks, it has to go through all blocks that are enabled, and create the content for each, then only display the ones that visibility settings say are visible.
This was confirmed because of the high memory usage. Even a setting of 192 MB for memory_limit for PHP did not work. Only having it to 256MB did work. Finally the site was functional!
As for the speed issue, we tuned the entire LAMP stack to have the optimal performance possible with Drupal. This is something we do as a service for clients: Drupal Server Provisioning Service: Installation, Configuration and Tuning.
Old Hosting Setup
The hosting that was used by the site previously was on a shared host using cPanel. cPanel imposes specific versions of the LAMP stack, and therefore is hard to tune well for complex applications like sites created with Drupal.
Moreover, the shared host was charging a substantial amount per month for filtering SPAM emails.
Inexpensive Hosting With Optimal Tuning
Because the site is for a non-profit entity, they did qualify for free Google Apps, with Gmail handling the email for the site, and filtering spam at no cost.
We then recommended a very inexpensive, $20 a month, VPS at Linode, installed the LAMP stack from scratch (Linux, Apache, PHP, MySQL), configured it all for Drupal, and tuned it optimally.
We also included some performance and resource monitoring tools (including Munin), web statstics (Awstats), and the latest Drush version.
Due to the memory constraints (2GB), we decided to configure the web site without Varnish, as we do occasionally. The page cache being disabled, as the client needs, contributed to that decision. We did configure memcached though, so as to speed up the other non-optional cached parts in Drupal.
Simple and Fast
We also did not use any complicated or expensive components or services, such as a Content Delivery Network (CDN), since we already achieved very good performance with minimal complexity and cost.
Here are the results of the old server, and the new server after we configured and tuned it optimally for Drupal. The times are in milliseconds.
/ 2,706 572
/about 2,063 430
[redacted] 2,235 455
[redacted] 2,437 457
As you can see, this is significantly faster than before, and the client is very happy with it.
If you, or any of your clients need to have an inexpensive and fast hosting setup, as per our Drupal Server Provisioning Service: Installation, Configuration and Tuning, please contact us today.