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. 30.10.2013 20:10:40
  2. # 21
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. 30.10.2013 21:10:29
  2. # 22
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. 31.10.2013 03:10:25
  2. # 23
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. 31.10.2013 10:10:02
  2. # 24
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 14:10:17
  2. # 25
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 15:10:27
  2. # 26
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 19:10:40
  2. # 27
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. 01.11.2013 06:11:51
  2. # 28
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. 13.02.2018 04:02:47
  2. # 29
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.
  • 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.