Announcement

Collapse
No announcement yet.

What combination with CloudLinux to run fast shared Magento hosting ?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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 CPUs + 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 Cloudlinuxs blog :





    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 spawns its own memory cache. One Users account could spawn multiple caches 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 CloudLinuxs 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.



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

  • #2
    Heres 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…



    I dont 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 its mainly on the memory. In which case I presume that php-fpms 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 accounts settings indivually.

    Is this a bad idea ?

    Comment


    • #3
      Im getting the impression Im 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).

      Comment


      • #4
        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.

        Comment


        • #5
          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 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.

          Comment


          • #6
            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.

            Comment


            • #7
              Yes, its a shame that the individual pools are not enough to seperate the APC caches…

              Comment


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

                Comment


                • #9
                  This is where I read about the problem :



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

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

                  Comment


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

                    Comment


                    • #11
                      Has anything changed regarding mod_ruid2? This is what cPanel is suggesting for shared hosting accounts but Im not sure if you prefer it over FastCGI.

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          Crystal clear Igor, thanks for your confirmation.

                          Comment


                          • #14
                            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 ? :

                            Code:
                            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…

                            Comment


                            • #15
                              Hello,

                              Ive 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 cant access each others data.

                              Comment

                              Working...
                              X