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.
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 :)
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.
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).