Running Magento for multiple clients - single Installaton vs. multiple installations

Question

I am looking to set-up a Magento (Community Edition) installation for multiple clients and have researched the matter for a few days now.

I can see that the Enterprise Edition has what I need in it, but surprisingly I am not willing to shell out the $12,000 odd yearly subscription.

It seems there are a few options available to be but I am worried about the performance I will get out of the various options.

Option 1) Single install using AITOC advanced permissions module So this is really what I am after; one installation so that I can update my core files all at the same time and also manage all my store users from one place. The problems here are that I don't know anything about the reliability of this extra product and that I have to pay a bit extra. I am also worried that if I have 10 stores running off this one installation it might all slow down so much and keel over as I have heard allot about Magento's slowness.

Module Link: http://www.aitoc.com/en/magentomods_advanced_permissions.html

Option 2) Multiple installations of Magento on one server for each shop So here I have 10 Magento installations on one server all running happily away not using any extra money, but I now have 10 separate stores to update and maintain which could be annoying. Also I haven't been able to find a whole lot of other people using this method and when I have they are usually asking how to stop their servers from dying. So this route seems like it could be even worse on my server as I will have more going on on my server but if my server could take it each Magento installation would be simpler and less likely to slow down due to each one having to run 10 shops on its own?

Option 3) Use lots of servers and lots of Magento installations I just so do not want to do this.

Option 4) Buy Magento Enterprise I do not have the money to do this.

So which route is less likely to blow up my server? And does anyone have experience with this holy grail of a module?

Thanks for reading and thanks in advance for any help - Chris Hopkins

Answer 1

We handle a couple dozen magento "installs" using a single code base, but multiple databases. Essentially we've done a rough job of creating a multi-tenanted Magento.

Here's how we're doing it:

1. Use nginx as a reverse proxy to handle some basic routing rules, and to set some server variables (fastcgi_params) based on the request.
2. We hardcode routing rules into Nginx Config based on the requested domain, browser language, and visitor location.
3. Set a server variable using Nginx fastcgi_params as "client-id"
4. Make copies of the app/etc folder with the convention of app/[client-id]/etc
5. override Mage.php variable $etcDir to $etcDir = self::getRoot() . DS . $_SERVER['CLIENT_ID'] .'/' . 'etc'; (You'll have to apply some logic here, to ensure that this can fail elegantly)
6. Edit app/etc/[client-id]/local.xml to point to a fresh db with magento tables and base content already imported. (You'll have to also set the URL in the core_config table, or in the local.xml file for anything to work)
7. Modify the include path of app/code/local/ to be app/code/local/[client-id]/ in Mage.php (yes, shoot me for overriding core code, but it's the only way we could find)
8. Setup Session Handling to be done in a Redis db, with db # unique per client
9. Override getVarDir() in Mage_Core_Model_Config_Options to include [client-id] in the path. (This is to ensure that you aren't sharing cache between clients)

You probably get the gist so far.

Other things you'll want to consider:

Isolation of media by client-id, Consolidating all "Admin Panel" urls, and asking Admin user to select [client-id], Configuring Varnish in a way that is sensible, Setting up CDN in a way that is sensible, Modifying Magento installer to support this method, and handle basic configuration automatically.

Answer 2

We run multiple clients on a single Magento CE installation and use AITOC's Advanced Permissions module to control visibility for our different clients. The module works well, although it has several hiccups and lacks functionality in a handful of areas, which we've had to handle with our own in-house modules. It doesn't seem to have any noticeable effect on performance, as we've been running it this way for months now without any issues. (That said, we do use Amazon EC2 and auto-scaling.)

As I understand it, EE does provide advanced role permissions that would render AITOC's module useless. However, I have also heard that the EULA for EE requires only 1 client per installation. I haven't been able to find hard facts on this, but if it's true, it's truly a deal-breaker, as having an additional EE installation for each client would get tremendously expensive, tremendously quickly. (Maybe someone can confirm yes/no on this, though?)

Answer 3

For my two cents I think you are going to run into more problems than pros by throwing everyone into a single installation of Magento with everyone bumping into one another. Not to mention Customer X on Website Y cant seem to figure out why he can't create an account on Website Z that he has never been to before (that is a configuration issue, but it could happen)

What I would recommend you do is setup a git repository that has your "base" Magento installation and then have all your clients on different versions setup that you could clone from that main install.

This will give you only one real code base to update (database changes are a different story) and everyone is separate.

Answer 4

I think getting a vps account and scaling it up when it becomes necessary will give you the best options for your cost requirements.

Answer 5

Let's get the non-options out of the way right away. You don't want to do #3 and #4 is a non-solution. Magento Enterprise Edition doesn't add any features that will let you run multiple customers from one store.

Now, onto possible options. As you state, #1 will allow you to update one version of the code, but of course this comes with some risks. As I understand it, your customers will need to access the stores? If you have multiple customers running on one database and one codebase, you will always run into issues with them affecting each other. For instance, who will control product attributes, which are by nature global? If one store deletes a product attribute, other stores may lose data as a result. If you solve this issue, what about catalog promotions and product categories, etc. Magento was built to handle multiple websites, but not to insulate them from each other, and you will experience problems because of this. As for performance, a large product catalog or customer base will tend to slow down the site, but you can mitigate this using the flat product catalog and making good use of caching.

For option #2, you can run multiple Magento stores, which brings up two main problems. First, as you state, is updating the sites. If you are using a vanilla installation of Magento and not modifying core files, this should be a nonissue. Magento's updater is pretty simple for those installations, with difficulty increasing as you do more mods and have to use more manual processes for upating.

As far as performance, running multiple magento sites might be slower, but it depends on how you structure them. Regardless of having one or multiple sites, you'll have to load data for each site, so database size won't be terribly different. File size on a server is pretty much a nonissue. In either case, when a customer requests a page, Magento has to spin up the entire framework to serve the request, which is where performance issues start to show themselves. One of the big mitigations for this is to use an opcode cache like Xcache, but with multiple machines you need to give Xcache much more memory to hold all the installations' code. Legitimate problem.

My recommendation? Start on one machine, multiple installs. Work your way up on number of installs, and when the server doesn't support any more, move on. Keep your code changes out of the core and use extensions that can be easily updated, so updates are easy. That should mitigate as many of the concerns as possible.

Hope that helps!

Thanks, Joe