We were recently approached by a non-profit site that runs on Drupal.
Major Complaints
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.
Other Configuration
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.
Performance Results
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.
Old New
/ 2,706 572
/about 2,063 430
[redacted] 2,235 455
[redacted] 2,437 457As 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.
Comments
mesch (not verified)
Interesting case study. Just
Mon, 2014/08/04 - 13:12Interesting case study. Just to clarify, did you or the client ultimately move content out of blocks? Also, I'm curious how much RAM you allocated to opcache/apc given the large number of modules enabled, and what happened to PHP RAM usage as a result.
In my experience, Drupal 7 on shared hosting rarely makes sense. With 210 modules enabled in this case, including the heavy hitters, you're going to have a bad time on shared hosting even if everything is properly configured.
Khalid
Answers ...
Mon, 2014/08/04 - 13:21No, we did not get to reorganizing the site, since they got good performance from the optimized hosting setup that did for them.
We used APC, and that is because we are on Ubuntu 12.04. We tried initially with 14.04 (with Zend OpCache), but the site behaved oddly on PHP 5.5 (some things not showing up.
The apc.shm_size is set to 128MB, with only 70% or so of that used. You should use apc.php to check how much memory is used by APC and tune that up or down.
And this is a Drupal 6 site, and performed poorly on shared hosting.
Bob (not verified)
Nice work
Sat, 2014/10/18 - 19:04At least with Linode they can easily add more resources if necessary. I'm curious why the page caching needed to be disabled.
Khalid
Can't remember
Sat, 2014/10/18 - 19:13I can't remember why specifically was the page cache disabled. But the point is, even with that, performance was great.
daganmd (not verified)
About adding APC at the top
Fri, 2015/02/27 - 08:18Excellent answer, but one things that strongly stands out to me, is that you don't have APC at the top. APC is trivially easy to get into place, there are no down-sides, and the gains can be really large. I think it should go to the top.
olivedev (not verified)
Performance and cost are
Tue, 2016/08/23 - 07:05Performance and cost are directly proportional. I don't believe you can improve performance while reducing cost, especially if you are using a LAMP stack. I have hosted my Drupal 8 website with Cloudways (https://www.cloudways.com/en/drupal-cloud-hosting.php ). I have build my website on PHP 7 and I am using Apache, Varnish, Memcached and Nginx stack with Cloudflare CDN. All of this has really improved the performance of my website, while the cost is little high but I can manage. So, you can either get fast website or cheap hosting and shared hosting is definitely not advisable if you want performance.
Khalid
False, and overpriced
Tue, 2016/08/23 - 10:15It is not always true that you need to spend extra money for good performance. If your site is well tuned, it can run on a small inexpensive host. That is what we do for a living: help people tune their sites so they can spend less money month to month on hosting.
Some sites are overly complex and refuse to simplify their code base, or it is very hard to simplify them. Those are the exception though, most sites can be streamlined and become performant on low cost servers.
Also, CloudWays is overly pricey. For comparison, consider Linode, where you can get a 4GB 2 core plan for $20 a month, while at CloudWays 2GB 2 core is $30. Definitely overpriced!
Infirays (not verified)
Drupal Hosting Cost
Thu, 2017/04/20 - 02:54Also experienced the above mentioned drupal website performance issues due to hosting. Was in search of some probable solution for it. Think I found one and going to follow the steps mentioned. Also save the memory cost & monetary. Kudos to the efforts made. Will implement this and share results once done.
David (not verified)
Drupal Hosting on Linode
Tue, 2019/02/26 - 14:59Just out of curiosity, is there any reason in particular you went with linode? While I can't argue with the pricing, I am curious why you opted to configure the server from scratch instead of using a container.
Aside from the caching issue, I can't argue with your results, they're solid. :)
Khalid
Answers
Tue, 2019/02/26 - 15:20Linode offers great performance, continual upgrades (more disk storage, occasional CPU upgrades), and excellent service. Combine that with the price, and you have an overall winner.
As for containers, they are just one more level of abstraction, and if your site will be mainly running just Drupal (or a certain application), then there is no need for yet another layer of complexity.
Works perfectly for us and for our clients.
Pages