What combination with CloudLinux to run fast shared Magento hosting ?
Forum
  1. Forums
  2. General
  3. General Discussion
  1. Richard Hordern
  2. Tuesday, 08 May 2012
  3.  Subscribe via email
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:
  1. 13.02.2018 04:02:47
  2. # 1
Quentin Accepted Answer
Gary Brooks - I don't see how your company could be provisioning 20,000 new sites a month, neither do I see how your low spec'd server with 32GB RAM could be hosting 5,000 sites. Porkies.
  1. 01.11.2013 06:11:51
  2. # 2
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
Votes
Undo
Hello Steven,

We haven't validated a setup yet as no oopcode cache worked with a large shared cache.

In a couple of weeks we will be updating litespeed to 4.2.5 and will activate the new suexec workergroup option as described on litespeeds blog :

http://blog.litespeedtech.com/2013/10/31/php-suexec-workergroup-means-even-more-efficient-opcode-caching/

We haven't validated a cache engine but are pleased with ZendOpcache that comes with PHP 5.5 on our own website so will probably go with that.

We will also be testing object cache capabilities like APCu to see if they are rearly isolated unlike with php-fpm pools (not sure if the person who wrote the litespeed blog article new that php-fpm pools share the same cache…).

We are aiming 800 accounts on this server (maybe less, maybe more depending on the ressource usage as will fill up the server). This is a large configuration but we allow alot of ressources per account so our setup may be different then yours.

We have more than 100GB of memory to spare so we will be testing with the recommended php.ini settings that you can see here :

http://us3.php.net/manual/en/opcache.installation.php
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1
128MB * 800 =  102400 MB = 100 GB

We will be testing to ensure that functions like opcache_reset  only reset cache for the account the cache is used on and if not will disable such functions.

To calculate the maximum extra memory that will be needed simply multiply the number of accounts by the opcache.memory_consumption variable, you might want to set it to 16, 32 or 64MB and not 128MB. Also the number of accounts * the cache memory consumption limit is the maximum, in reality you should never hit this usage as most accounst will use up less than 32MB.

We will also be playing with the Max Idle Time setting. We will probably choose something between 5 minutes and one hour but on a memory constrained server a setting like 30 or 60 seconds would be advised.

I will update this thread once we have run our tests, validated the new Suexec WorkerGroup and watched our logs for a bit to make sure everything is running as it should.

While I'm very impatient to try this out, we have to play it safe and wait for the product to be stable. Litespeed fixe bugs quickly as they appear without changing the version number. The latest release has a huge number of important features so we concider it needs a bit of time before being concidered as production worthy for our customers. It's easy to downgrade litespeed but php lsapi could need to be downgraded to and compiling PHP again takes a bit of time so I will wait a bit.

If everything woks as well as we hope, this will mean that hosts can have the option to invest in more memory to accelerate thier customers scripts.
  1. 31.10.2013 19:10:40
  2. # 3
Steven Accepted Answer
Posts: 5
Joined: 31.10.2013
0
Votes
Undo
Hey Richard,

Would you mine sharing what setting you used to setup Litespeed and XCache within CloudLinux to make it secure and fast? If you can it would be great to share as much as you can, as we want to speed our our shared hosting as well.

Thanks!
  1. 31.10.2013 15:10:27
  2. # 4
Igor Seletskiy Accepted Answer
Posts: 1194
Joined: 09.02.2010
0
Votes
Undo
Well, this is not bad, as most memory is used for disk caches.
  1. 31.10.2013 14:10:17
  2. # 5
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
Votes
Undo
Currently (without any opcache) :
             total       used       free     shared    buffers     cached
Mem:           251        174         77          0         42         96
-/+ buffers/cache:         34        216

The original idea was to have fcgid with a cache per instance but we abandoned that idea in favor of litespeed.

We then discovered that most cache systems don't like going over 256MB and slow down instead of speeding up when you allow figures like 2GB of cache.

So allowing an opcode cache per accout would allow us to use up some more memory.

The server is far from full, but we are looking for any ways to use up more ram in order to speed up websites or reduce CPU load. 
  1. 31.10.2013 10:10:02
  2. # 6
Igor Seletskiy Accepted Answer
Posts: 1194
Joined: 09.02.2010
0
Votes
Undo
I cannot imagine how to use up 256 GB of ram on shared hosting server - even with opcode caching.
I wonder what does free -g output looks like on your server.
  1. 31.10.2013 03:10:25
  2. # 7
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
Votes
Undo
I always wait a few weeks before installing an update with lots of new features on a production server. This will use more memory but we invested in alot of memory for our last server (256 GB) but were unable to put much of it to use as oopcode caches didn\'t like big server wide cache.
  1. 30.10.2013 21:10:29
  2. # 8
Duplika Accepted Answer
Posts: 8
Joined: 03.12.2012
0
Votes
Undo
That\'s great news! Hopefully anyone is able to test this out and share results.

Default\'s cPanel support for FastCGI required by CloudLinux is not optimal and could be greatly improved.
  1. 30.10.2013 20:10:40
  2. # 9
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
Votes
Undo
I\'m very excited about Litespeed 4.2.5 that has just been released with a new per account suexec mode!

Not tested yet but it should solve all issues with apc object cache and play much better with other oopcode cache engins !
  1. 22.01.2013 12:01:59
  2. # 10
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
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.
  1. 18.01.2013 07:01:22
  2. # 11
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
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
  1. 18.01.2013 06:01:43
  2. # 12
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
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 =        ""
  1. 13.01.2013 12:01:46
  2. # 13
Duplika Accepted Answer
Posts: 8
Joined: 03.12.2012
0
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.
  1. 13.01.2013 12:01:48
  2. # 14
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
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
  1. 03.12.2012 10:12:45
  2. # 15
Duplika Accepted Answer
Posts: 8
Joined: 03.12.2012
0
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.
  1. 27.07.2012 12:07:18
  2. # 16
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
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.
  1. 27.07.2012 04:07:05
  2. # 17
Richard Hordern Accepted Answer
Posts: 212
Joined: 19.03.2011
0
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…
  1. 22.05.2012 00:05:32
  2. # 18
Juanzo Accepted Answer
Posts: 2
Joined: 22.05.2012
0
Votes
Undo
Crystal clear Igor, thanks for your confirmation.
  1. 22.05.2012 00:05:08
  2. # 19
Igor Seletskiy Accepted Answer
Posts: 1194
Joined: 09.02.2010
0
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.
  1. 22.05.2012 00:05:16
  2. # 20
Juanzo Accepted Answer
Posts: 2
Joined: 22.05.2012
0
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.
  • Page :
  • 1
  • 2


There are no replies made for this post yet.
Be one of the first to reply to this post!
Quentin
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,zip,rar,pdf
• Insert • Remove Upload Files (Maximum File Size: 2 MB)
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.