What combination with CloudLinux to run fast shared Magento hosting ?

[jmanuel]

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 caches don share their information.

[clm]

> 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 caches dont 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.

cPanels point of view about this is that if you want to use fcgid you need to be able to administer it. If you cant administer it then go for suPHP.

----

Ive just done some reading on Litespeeds 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 ?

Ive 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 others code ?

Thanks

[jmanuel]

Thats a great question Richard, we are also considering LiteSpeed.

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

[clm]

Ive 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 users wont have a way of changing this value (with ini_set) or something similar. I dont think they will and I hope PHP-Selector wont allow users to change php.ini values that we dont 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 ?

Heres 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 =        ""

[clm]

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

[clm]

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

Weve 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 dont think it was comaptible with SuExec. Since weve 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 didnt 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…). Unixys 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. Its 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 cant 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… Ill 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, Im actually been quite impressed with both Atomics and Litespeeds support. Not a fast as cPanels or CloudLinuxs but perfictly acceptable for products that can easily be disabled while waiting for a solution.

[clm]

Im 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 !

[jmanuel]

Thats great news! Hopefully anyone is able to test this out and share results.

Defaults cPanel support for FastCGI required by CloudLinux is not optimal and could be greatly improved.

[clm]

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 like big server wide cache.

[iseletsk]

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.

[clm]

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 dont 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.

[iseletsk]

Well, this is not bad, as most memory is used for disk caches.

[steven]

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!

[clm]

Hello Steven,

We havent 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 havent 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 Im 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. Its 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.

[clm]

Gary Brooks - I dont see how your company could be provisioning 20,000 new sites a month, neither do I see how your low specd server with 32GB RAM could be hosting 5,000 sites. Porkies.