5

I'm moving my projects from Bluehost to GreenGeeks, and I'm concerned about the Drupal (v7) PHP memory limits. Maybe I'm overly concerned, but has anyone experienced any issues with GG or BH about running Drupal for clients' commercial projects requiring more than average PHP memory levels above 64meg to a max 128meg memory requirement. Any comments welcome.

Improve this question
2
  • what do you mean by "most hostings are per-se these days"???
    – iconoclast
    Oct 4, 2012 at 19:03
  • Removed that comment line.
    – Paul B
    Oct 5, 2012 at 15:58

3 Answers 3

Reset to default
35
+200

A 128M memory limit is often not "more than average" for a Drupal project. Also, just because you've specified 128M as the memory limit, that doesn't mean your webhost is giving you that much (or even half as much).

Let me explain. I'll use Commerce Kickstart v2 with the demo store installed as an example (matching a medium-sized Commerce store). It has 10 content types, 6 product types. 146 modules installed, out of that 23 provided by Drupal core, and 123 contrib.

Installing Commerce Kickstart requires 77M of RAM (xhprof peak memory usage). A Kickstart page (frontpage, the view that lists products in a category, faceted search page) takes about 17M (as reported by devel). This number can spike easily on admin pages that show many items, or thanks to a misbehaving module.

Our minimum memory limit requirement for Kickstart is 128M, based on our personal experience developing Drupal sites (it's easy to get "memory limit exceeded" with less than that). Also, if the server doesn't have enough memory when generating the request, it won't give you how much you asked for. I saw it with my own eyes (MacBook Pro, Chrome with a million tabs, only a bit of RAM left. PHP fails to allocate 77M of ram despite the memory limit being 128M). I also saw this complaint from people with shared hosting (I strongly believe that running anything more than a blog on shared hosting is pure masochism without excuse in the age of cheap VPS).

Why does Drupal need so much memory? Among other things, because it has a cache problem (which of course saves your database) Drupal currently likes to cache ALL views in one place, ALL fields in one place, etc. So once you get a site with many content types, fields, views, the caches become huge, and they are all loaded into your memory with each request. Thankfully, this is being fixed as we speak, thanks to people like catch (See this article for details).

The fix to Views got committed a few days ago and is now available in 7.x-3.x-dev. Quoting #29 from that thread, where the memory usage for Views dropped from 34M to 17M:

So, for normal use, there's a 15% improvement in execution time, and 49% improvement in memory usage.

There is also a RTBC fix for fields in Drupal core that should make it into the next Drupal 7 release. Benchmarks showed savings between 1M and 50M (depending on your number of fields).

There's an in-progress fix for the system (module & theme) list in Drupal core that should shave a megabyte or two as well.

So, install Devel, go to admin/config/development/devel, enable "Display memory usage", and find out how much your pages need. Also follow the fixes I mentioned, test them and see how much they help you (they give me a few megabytes of savings on the Kickstart install, which still counts).

And of course, find a decent hosting (I don't know if GreenGeeks is decent, don't have much experience in that field), set a decent memory limit, and don't worry too much :)

Improve this answer
3
  • Thank you for a comprehensive answer! Both providers have/had told that user memory limit (re: Drupal here) where capable of larger. I work at home on a pure Linux Ubuntu LAMP box for my D7 dev and therefore can 'emulate' to some degree a Linux based O/S (and hence set my memory a little higher), but that does not mean my current server provider allows me a massive headroom. I've now taken the chance with GG having been with BH for 6+ years (nothing wrong, purely a price sensitive move), but until I can afford a VPS or dedicated server, I wish to try to eliminate future problems. Cheers.
    – Paul B
    Oct 1, 2012 at 10:12
  • 2
    +1 for mentioning these important memory-saving patches. To everyone: please keep pushing issues like (drupal.org/node/1040790) to get them into core, and follow tags like 'memory' (drupal.org/project/issues/search/drupal?issue_tags=memory) and 'performance' (drupal.org/project/issues/search/drupal?issue_tags=Performance) on drupal.org:
    – geerlingguy
    Oct 3, 2012 at 17:16
  • 2
    And, IMO, ~128MB should be a minimum memory_limit for Drupal 7. On an average site with a few content types, a bunch of fields, some views, and 20-40 modules enabled, cache clears could easily consume 60-80MB. Normal (cached) page loads should stay below 30MB, though.
    – geerlingguy
    Oct 3, 2012 at 17:18
3

Bojan's answer is great, and I gave it a +1.

Although the question was about memory limits, and not php.ini, I wanted to note that I, coming from a virtual-private-server background, initially thought that in a managed / shared hosting environment, I had to take whatever the provider gave me for php.ini.

I don't have any experience with bluehost or greengeeks, but on another managed environment I recently started using for a pro-bono client, the default memory_limit in /usr/local/lib/php.ini (the default, uneditable location) was only 64M. The documentation was not great, but it turned out that if I copied php.ini to my home directory, then the webserver would pick it up and use it, and I could adjust the memory_limit as needed.

So, as Bojan said, just because you set memory_limit to a larger value (I'm using 256M) doesn't mean that you'll necessarily get that much, your fist step should be to figure out how to customize your php.ini. If you haven't already done so for your hosting provider, contact their support service and ask how, or search their documentation. Different providers may have different ways to do it.

Improve this answer
3
  • I think this is the functionality you talk about php.net/manual/en/configuration.file.per-user.php
    – Mike
    Sep 30, 2012 at 21:08
  • In the case of my managed hosting account, php.ini may be placed in the home directory, which is above the document root.
    – greg_1_anderson
    Sep 30, 2012 at 23:12
  • Specifically, I had to put SuPHP_ConfigPath /home/myuser in my .htaccess file. This feature must be enabled by your ISP for this to work, of course.
    – greg_1_anderson
    Oct 3, 2012 at 20:14
3

On WebEnabled.com development servers -- Commerce Kickstart V2 requires at least 99M for a successful install. It varies, depending on the release (e.g. RC1, Beta-01) but the bottom-line is: most Drupal install profiles these days are resource hungry.

You have to put the PHP version into the equation too (although Drupal 7 runs on PHP 5.3 very well) -- sometimes contrib modules for D7 run well with PHP 5.2 and vice-versa (we can't expect all contributors to always optimize for both php versions)

Another observation I have when testing / building Drupal app-bundles for WebEnabled is that some install-profiles run better on a specific Linux VPS template (e.g. Ubuntu, OpenWall, CentOS) -- just my personal observation (I have not yet tried using benchmarking tools / reports).

Improve this answer
1
  • That's true. Newer PHP versions tend to be better with memory (at least PHP 5.4 provides a measurable decrease in memory usage). We've tested Kickstart to ensure all three PHP branches (5.2, 5.3, 5.4) work without errors, but with that many modules the situation constantly changes (-dev modules introduce regressions, they get fixed, and the circle renews).
    – Bojan Zivanovic
    Oct 2, 2012 at 17:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.