What combination with CloudLinux to run fast shared Magento hosting ?

Forum

Sign In Here

Sign in to your account

If you are new here please register for an account

Username:

Password:

Remember Me

Forgot Password?

Resolved What combination with CloudLinux to run fast shared Magento hosting ?

Hello,

We are looking into offering shared hosting capable of competing with heigh end VPS magento hosting, using CloudLinux. This is still in planning stages and we plan to purchase our first server with this configuration in the next 4 or 5 months.

We will be purchasing a powerfull server to do this. The current specs include 128GB of memory and two Sandy Bridge EP E5-2687W 8x 2x 3.10GHz CPU's + enough hard drive speed to cope with the other specifications.

We also run cPanel on our servers although I do not believe this to be directly related with our question.

I have read the following articles on Cloudlinux's blog :

http://www.cloudlinux.com/blog/clnews/how-opcode-caching-works-with-modfcgid-in-shared-hosting.php

http://www.cloudlinux.com/blog/clnews/perfecting-fastcgi-settings-for-shared-hosting.php

These articles advise low settings for both fastcgid and APC so not to use up too much memory on a shared hosting server.

For Magento we need the following memory specifications :

512 MB memory limit for PHP
256 MB for APC caching per account

Here are the available (or soon available) solutions I have come accross and their different problems :

---
HTTP SERVER SOLUTIONS
---

Apache 2.4 + PHP 5.4 + FastCGID + APC :
This setup is secure and quite fast but has one major problem : Each FastCGI process spawn's it's own memory cache. One User's account could spawn multiple cache's and would not reuse existing cache spawned by another process.

Apache 2.4 + PHP 5.4 + FastCGID + PHP-FPM + APC
This setup allows to setup different pools of users so it could be possible to setup a pool per account on the server just like we setup a virtual host per account. This is more flexable and would allow us to specify different limits per user but fr om what I have read so far has one major drawback ( that I would love to be corrected on !) :

Users fr om different PHP-FPM pools can access each others APC memory cache.

To get around this, I have read that you would need to run individual processes for each account creating a new init.d file for each process of PHP-FPM specifying a different config file.

I do not have an idea of what the over head would be to run 600 or more PHP-FPM proceses on the same server but I can see a reeboot being very long and the setup of new accounts being quite complicated (I suppose a hook on account creation could create a new config file and init.d file…

Mod_ruid2
I contacted CloudLinux in Feburary about Mod_ruid2 and was advised against it for the following reasons :

- Not concidered as secure as FastCGID or SuPHP
- CloudLinux Memory lim its would not work with it
- CloudLinux CageFS would not work with it

cPanel seem to encourage people to use Mod_ruid2 and say they are not aware of CloudLinux's memory lim its not working wih Mod_ruid2.

Has this changed ? Do you still think Mod_ruid2 to be insecure and not working completly with CloudLinux ?

Would using Mod_ruid2 allow each user to have a single shared APC cache accessible by multiple different processes owned by the same user but not accessible by other users ?

Fastcgi + APC
It seems that Fastcgi does everything that is needed but has not been upd ated since 2006. I would prefer to not use obsolete software if it can be helped.

The following article explains how to set up Fastcgi to use individual APC cache size se ttings per user and individual php.ini files if required.

http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/

Litespeed

On the litespeed site, the last release in the news on their main page was in August 2011. This gives me the impression that the project was abandonned or at least not beeing worked on for quite some time.

Is Litespeed still a recommened solution by CloudLinux ?

NGnix
NGnix is not a solution here, as it is not yet supported by cPanel and htaccess files are needed by our customers.

---
OPCode cacheing
---

I have also looked at different OOPCode caching systmes and have chosen APC because :

- Eaccelerator :

The last release was in 2010, Their website only works in https and has an expired SSL certificate. Project abandonned ?

- Xcache :

Xcache is supposed to be a bit faster than Eaccelerator but also doesn't seem to be so popular on cPanel, lots of people say it does not install well.

- APC :
APC is not currently suppored directly by EasyApache but is supported by cPanel by installing it through PECL. APC is a maintained project and will be part of the PHP6 project.

----

We are looking for suggestions about how to make the best use of our new configurations. We are not looking into putting thousands of sites on these servers nor to only host Magento sites.

We will be hosting both Magento and non Magento sites but are looking for a secure way to have fast page loads with Magento sites, with or without having a specific hosting plan for these sites.

The ideal would be to be able to have fast loading Magento sites for low volume trafic sites on our standard plans and have a more expensive plan offering more CPU and Memory.

For the hardware, we could slightly lower the CPU specs and get 192 GB of memory by in theory, if the right solution can be found 128 GB should be plently for hosting arround 800 sites.

Rate this post:

Responses (29)

10.05.2012 03:05:06
# 1

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

Here's some reading about php-fpm where they suggest that to use APC and php-fpm on shared hosting you need to launc php-fpm multiple times…

http://groups.drupal.org/node/198168

I don't know what the impact would be to have 1 process running per pool/user.

If we wanted to host 600-800 sites on a server with 128GB of memory could this be a solution ?

I have no idea about how much impact running 800 processes of php-fpm would have on CPU and Memory… I presume it's mainly on the memory. In which case I presume that php-fpm's overhead is small and I also presume that running 800 processes of php-fpm could require less memory than having multipe opcode caches per account… and would also have the advantage of being able to set each account's settings indivually.

Is this a bad idea ?

15.05.2012 13:05:54
# 2

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

I'm getting the impression I'm hitting a brick wall with these questions. I have asked around but seem to be almost the only one looking for a solution to get APC running with a single cache per user… :(

I might try asking CloudLinux support about this although I do not feel that it is their job to answer this type of question as it is not strictly related to CloudLinux, just to a usage we want to do with CloudLinux (Magento needing to be contained because of the large amount of ressources it could use in some cases).

15.05.2012 13:05:06
# 3

Igor Seletskiy Accepted Answer

Posts: 1194
Joined: 09.02.2010

Votes

Undo

Richard,

The best I have seen so far is mod_fcgid with single cache per process.
When well tuned it gives good performance with moderate memory usage.
If you need cache per user, you will most likely be looking at php-fpm + mod_proxy_fcgi (not mod_fastcgi) -- I think (though might be incorrectly) it should be able to configure it so that there is one cache per customer.

15.05.2012 15:05:26
# 4

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

Thanks !

I have read that php-fpm when run with APC allows all users to access each others APC cache.

PHP-fpm allows multiple processes to share a single cache, but it seems that the only way to prevent users from different pools from accessing each others APC cache is to launch multipe instances of PHP-fpm.

If I had 400 accounts on a server it doesn\'t sound optimised to run 400 times PHP-fpm (400 php-fm files in /etc/init.d) but maybe it would not take that long to launch 400 times php-fpm and that php-fpm would not use up much ressources per instance so long as it is set to have 0 instances of PHP running when there are no visites on a site.

PHP-fpm seems to be the perfect solution except that APC cache seems to be shared on a lower level then the php-fpm pools.

15.05.2012 15:05:48
# 5

Igor Seletskiy Accepted Answer

Posts: 1194
Joined: 09.02.2010

Votes

Undo

400 php processes might not be an issue -- if they are sleeping (needs to be tested). Majority of the memory between those processes will be shared, as long as they sleep.
Either way to run different php with different user id per customer, you would need to setup separate php-fpm pool per customer.

15.05.2012 16:05:37
# 6

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

Yes, it's a shame that the individual pools are not enough to seperate the APC caches…

15.05.2012 18:05:15
# 7

Igor Seletskiy Accepted Answer

Posts: 1194
Joined: 09.02.2010

Votes

Undo

Are you sure about that? It sounds to be that they should be.

16.05.2012 04:05:48
# 8

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

This is where I read about the problem :

http://groups.drupal.org/node/198168

The solution that appears to be the most appealing right now is to run two instances of php-fpm with one pool each.

"just launch php-fpm -y /path/to/php-fpm.conf with different path to php-fpm.conf. The FPM master process consumes almost no CPU and some memory. So multipliing FPM instance is not a big deal. go ahead."

I'm looking into having up to 800 to 1000 sites on a large server.

If I have to launch multiple instances then I think I should put all the instances in the same init.d file to not fill up the init.d folder…

To integrate this in cPanel I would have to create a hook that both creates the config file, adds the launch command the the php-fpm init file and see how long it would take to restart all instances of php-fpm.

php-fpm seems to be the way to go to have an optimised setup allowing more memory per APC cache than if I had multiple APC caches per user/pool.

16.05.2012 08:05:29
# 9

Igor Seletskiy Accepted Answer

Posts: 1194
Joined: 09.02.2010

Votes

Undo

You would also need to modify VirtualHost config files to inject configuration for each php-fpm.

22.05.2012 00:05:16
# 10

Juanzo Accepted Answer

Posts: 2
Joined: 22.05.2012

Votes

Undo

Has anything changed regarding mod_ruid2? This is what cPanel is suggesting for shared hosting accounts but I\'m not sure if you prefer it over FastCGI.

22.05.2012 00:05:08
# 11

Igor Seletskiy Accepted Answer

Posts: 1194
Joined: 09.02.2010

Votes

Undo

Imho: mod_ruid2 sucks from security and stability standpoint.
It will not have memory limits with CL, and it will not be compatible with CageFS due to the fact that the same process serves many users.
Its chroot mode brakes a lot of php scripts.
I would strongly recommend not using it, and using mod_fcgid instead.

22.05.2012 00:05:32
# 12

Juanzo Accepted Answer

Posts: 2
Joined: 22.05.2012

Votes

Undo

Crystal clear Igor, thanks for your confirmation.

27.07.2012 04:07:05
# 13

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

Hello,

Do you know how mmap works ?

Would adding the following configuration for APC in php.ini make each pool use a different memory location ? :

apc.mmap_file_mask=/apc.shm.XXXXXX

If this is the case then maybe it would be safe to only create different pools instead of creating different instances…

27.07.2012 12:07:18
# 14

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

Hello,

I've just tested with two users in two pools and they can access each others records.

I have even tried to set different apc.mmap_file_mask values using :

php_admin_value[apc.mmap_file_mask]=user1.shm.XXXXXX
php_admin_value[apc.mmap_file_mask]=user2.shm.XXXXXX

But both users can still access each others data :(

It rearly seems like I will have to launch different processes to make sure different users can't access each others data.

03.12.2012 10:12:45
# 15

Duplika Accepted Answer

Posts: 8
Joined: 03.12.2012

Votes

Undo

cPanel is insisting with mod_ruid2 and their default configuration with mod_fastcgi requires special configuration.

It would be great if you guys worked together so that EasyApache provides a working configuration with FastCGI so that we can use CLN advantages without requiring special configurations, like adding a custom cronjob to kill old PHP procceses or making sure opcode cache\'s don\'t share their information.

13.01.2013 12:01:48
# 16

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

It would be great if you guys worked together so that EasyApache provides a working configuration with FastCGI so that we can use CLN advantages without requiring special configurations, like adding a custom cronjob to kill old PHP procceses or making sure opcode cache's don't share their information.

Fcgid setup varies a lot depending on what you want to host and how many sites etc. As each configuration varies you would need to be able to work out the settings your self for this.

cPanel's point of view about this is that if you want to use fcgid you need to be able to administer it. If you can't administer it then go for suPHP.

----

I've just done some reading on Litespeed's website, am I correct in concluding that Litespeed already manages oopcode in a secure way and allowing only one cache per user while having multiple processes for that user ?

I've read this here :

http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:php:opcode_cache

By using the PHP_LSAPI_CHILDREN method, only a single shared memory slice will be created and shared by all children.

Am I right in saying that litespeed will allow me to completly replace the usage I wanted to do with PHP-FPM ? Or will there still be an issue with users being able to access each other's code ?

Thanks

13.01.2013 12:01:46
# 17

Duplika Accepted Answer

Posts: 8
Joined: 03.12.2012

Votes

Undo

That\'s a great question Richard, we are also considering LiteSpeed.

Hopefully migrating a live server doesn\'t cause much trouble with active websites.

18.01.2013 06:01:43
# 18

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

I've got some more info about this.

LiteSpeed has the same problem as PHP-FPM (in CageFS compatible suexec devel mode at least) it creates a single root process which it forks to create user processes so APC is currently a no-go unless there is a way to deactivate the APC-Store functions which would be a shame.

There does however seem to be a solution. The latest version of Xcache (3.x.x) supports namespace that can be set to uid or gid in the php.ini.

I just hope that user's won't have a way of changing this value (with ini_set) or something similar. I don't think they will and I hope PHP-Selector won't allow users to change php.ini values that we don't want users to…

Igor, in future versions of PHP Selector when users will be able to to define personal settings in their php.ini, will it be possible to disallow users to change certain settings ?

Here's the namespace configuration section in the xcache.ini file :

; mode:0, const string specified by xcache.var_namespace

; mode:1, $_SERVER[xcache.var_namespace]

; mode:2, uid or gid (specified by xcache.var_namespace)

xcache.var_namespace_mode =    0

xcache.var_namespace =        ""

18.01.2013 07:01:22
# 19

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

A quick note for those interested :

Seems Xcache is definetly the solution (for both php-fpm and litespeed) ! :

http://www.litespeedtech.com/support/forum/showthread.php?p=44288#post44288

22.01.2013 12:01:59
# 20

Richard Hordern Accepted Answer

Posts: 212
Joined: 19.03.2011

Votes

Undo

Just a [S]quick[/S] long note to say we think we have found the right combination for our servers and customers. We're still waiting for some answers fr om ASL and litespeed but are gradually getting there.

We've got litespeed with PHP in Suexec devel mode
PHP with Xcache 3.0.1 with user id namespace setting for variables
ASL

Xcache kept crashing with Fcgid, I don't think it was comaptible with SuExec. Since we've moved to litespeed it seems to have been very stable and just as fast as APC, faster if you take into account that each user has his own cache (thanks to namespace support) and only once cache per us er (thanks to litespeed Suexec deamon mode).

Litespeed is a bit complicated to configure beacause of loads of settings, configurable limits for each aspect, great when you get to know what needs tuning because the orignial settings too low for some servers or usages. But the install procedure is very easy, the cache system (that I still need to explore a bit more) seems to be amazing, completly configurable by each user with .htacess and very fast (at least when placed on a ram disk). I love the private and public cache notions and the possibility to set how long cache should last for on a per file / URL / Cookie basis.

We tested Varnish but didn't like the overhead of Apache + Varnish (pages not in cache are a bit slower (about 15ms) than with just Apache and Apache seems slower than litespeed…). Unixy's integration of varnish is good, and corresponds very well to some hosts and sites, it is a lot cheaper than Litespeed and brilliant for a non sharred hosting environement wh ere the user is the administrator. It's only lacking the ability for each user to choose to have cache or not, choose how long each type of file is cached.

We might still go back to Varnish if we can't fix the two remaining problems :

1 : PHP processes been stopped and started upon a gracefull restart of litespeed, I might have found the setting that was causing this just a few minutes ago… I'll check the logs tomorrow to see it if was the CPU limitation for CGI processes that was killing PHP or not…

2 : Litespeed is behind ASL T-WAF (tortixd) but T-WAF is not blocking anything, hopefully we might have an answer how to fix this tonight.

About ASL and Litespeed companies :
I was a bit worried about support with both companies to begin with, but now I understand the way they work, I'm actually been quite impressed with both Atomic's and Litespeed's support. Not a fast as cPanel's or CloudLinux's but perfictly acceptable for products that can easily be disabled while waiting for a solution.