Оптимизация веб-окружения на платформе Jelastic для проектов на PHP

    Бесплатное бета-тестирование облачной платформы Jelastic на хостинге InfoboxВ предыдущих статьях мы рассказали вам о запуске на Infobox облачной платформы Jelastic.Cloud, а также о том, как мы создавали каталог CMS для развертывания их в один клик на платформе Jelastic.Cloud и каких высоких результатов производительности мы добились, оптимизировав веб-окружения.

    Но, конечно, в нашем каталоге есть не все существующие CMS, поэтому сейчас мы расскажем о том, как самостоятельно развернуть на Jelastic.Cloud свой PHP-проект и оптимизировать под него окружение. Мы сделаем это на примере UMI.CMS.

    Начнем с создания окружения. Для большинства проектов будет достаточно связки Apache + MySQL.



    О том, как загрузить файлы проекта на созданное окружение, писалось уже неоднократно, поэтому мы ограничимся ссылкой на инструкцию. А вот с базами данных вопрос не так очевиден. При создании ноды MySQL на почту приходит пароль пользователя root. Самая частая ошибка – использовать этот пароль для подключения сайта к серверу баз данных. Для этого лучше создать отдельного пользователя в PhpMyAdmin:



    Еще одна распространенная ошибка — указывать в поле «Хост» локальный хост. Дело в том, что в Jelastic сервер приложений и сервер баз данных разделены, а значит доступ пользователя будет только через интерфейс PhpMyAdmin и неоткуда больше. Можно указать в этом поле «Любой хост», а можно уточнить у технической поддержки внутренний адрес вашего сервера приложений и разрешить доступ с него.

    Для простоты настройки можно также поставить отметку «Создать базу данных с именем пользователя в названии и предоставить на нее полные привилегии» или «Предоставить полные привилегии на базы данных подпадающие под шаблон (имя пользователя\_%)», в противном случае нужно также настроить разрешения созданному пользователю.

    Следующая трудность, с которой можно столкнуться при деплое проекта на Jelastic – подключение сайта к БД. Для подключения нужно сначала посмотреть адрес сервера баз данных:





    И использовать при подключении именно этот адрес и данные ранее созданного пользователя:





    Когда проект размещен, можно подумать об оптимизации окружения. Начнем с MySQL.
    В панели управления Jelastic выберите пункт «Конфигурация» ноды MySQL и откройте для редактирования файл my.cnf:



    У нас на сайте 96 таблиц. Чтобы не тратить время на их открытие, разрешим держать их все открытыми в кэше, изменив значение параметра table_open_cache на 100. При установке этого параметра существенно большим, чем количество таблиц, вы повышаете количество оперативной памяти, резервируемой под кэш, что ведет к повышенному ее потреблению, а значит большим затратам без какого-либо выигрыша в производительности.

    Теперь разрешим кэшировать запросы, добавив переменную query_cache_size со значением в 16М. Это усредненное значение, которого будет достаточно большинству сайтов (за исключением интернет-магазинов), но для конкретного проекта может быть оптимальной и другая цифра.
    Помимо запросов желательно кэшировать потоки. Сделать это можно, добавив строку thread_cache_size = 16 (можно 8, если не ожидается высокой посещаемости ресурса).

    Так как на рассматриваемом проекте используется InnoDB, то нужно установить частоту сброса логов на диск с помощью параметра innodb_flush_log_at_trx_commit. На этапе отладки проекта можно использовать значение 1, но после завершения основных работ лучше перевести параметр в 2: это обеспечит максимальную скорость работы сервера БД.

    С InnoDB связаны еще 2 важных параметра:

    innodb_flush_method = O_DIRECT позволит избежать ситуации, когда кэширование будет производиться и операционной системой, и MySQL-сервером;

    innodb_buffer_pool_size по умолчанию устанавливается в 512 Мбайт, что для небольших баз данных излишне. При статическом содержимом базы этот параметр стоит установить чуть больше размера БД. Если же в базу постоянно добавляется информация, то параметр может быть в 1,5-2 раза больше размера БД и периодически пересматриваться.

    Внеся все эти изменения, сохраним файл my.cnf и перезапустим MySQL-сервер.

    Теперь перейдем к оптимизации сервера приложений, для этого аналогичным образом откроем php.ini на Apache ноде.
    Одним из факторов, почему сайт плохо работает на виртуальном хостинге, часто становится акселератор PHP, а точнее – его отсутствие. В Jelastic уже предустановлено 4 акселератора, вам остается только включить нужный, раскомментировав нужную строку в php.ini. Практика показывает, что наилучший результат дает включение apc, поэтому далее речь пойдет про его использование. При этом ничто не мешает вам использовать другой акселератор или даже установить свой, загрузив SO файл в папку modules и также подключив его в php.ini.

    Для оптимальной работы APC добавим в php.ini следующие строки:

    realpath_cache_size = 4M — объем памяти, выделенный для кэширования реального пути;

    apc.ttl = 1800 — устанавливает время кэша в 30 минут (оптимальное значение может быть другим в зависимости от частоты обновления контента на сайте);

    apc.max_file_size = 4M — файлы больше указанной величины не будут кэшироваться во избежание роста потребления ОЗУ;

    apc.shm_size = 128M — максимальный размер блока кэша (количество блоков может быть увеличено с помощью apc.shm_segments);

    Сохраним php.ini и перейдем к настройке самого веб-сервера. Файл настроек находится в директории conf и называется httpd.conf.

    Большая часть этого файла на быстродействие не влияет, нас будет интересовать только секция:

    <IfModule prefork.c>
    StartServers 1
    MinSpareServers 1
    MaxSpareServers 2
    ServerLimit 256
    MaxClients 256
    MaxRequestsPerChild 100


    Ее стоит заменить на:

    <IfModule prefork.c>
    StartServers 5
    MinSpareServers 5
    MaxSpareServers 10
    ServerLimit 256
    MaxClients 256
    MaxRequestsPerChild 10000



    Чтобы не перегружать статью, мы не будем описывать значение каждой из переменных, только отметим, что такая конфигурация увеличивает скорость работы, но вместе тем приводит к повышенному расходу оперативной памяти.

    После внесения изменений необходимо сохранить httpd.conf и перезапустить Apache:



    Результатом не слишком долгой работы стал «прекрасный результат» индекса производительности UMI.CMS.



    Надеемся, что данная статья поможет и вашим проектам работать быстрее! Ну, а веб-приложения из нашего каталога CMS для установок в 1 клик на Jelastic и так все летают.

    Вы можете сами в этом убедиться, приняв участие в бета-тестировании платформы до 15 октября.
    Infobox
    0,00
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 18

      0
      А как у Вас обстоят дела с другими SQL решениями, Например Postgres
        0
        На данный момент платформа Jelastic поддерживает следующие SQL серверы: MySQL 5.5, MariaDB 5.5 и 10.0, PostgreSQL 8.2 и 9.2.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Скоро будет SSH доступ к каждому компоненту… А пока Вы можете подключить Public IP и попроcить хостинг провайдера включить Вам SSH доступ. Или просто купить Elastic VDS и использовать там SSH. Такой вариант решает вопрос?
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Затраты будут такие же как и на любом другом стандартном хостинге. Но в этот же момент вы получите преимущество вертикального масштабирования и будете платить только за реально используемые ресурсы. Плюс можно использовать плюшеки по клонированию и остановке окружения.

                Давайте начнем с того — а зачем Вам нужен SSH доступ? Пример с Drupal понятен. Еще какие-то конкретные нужды?
                • НЛО прилетело и опубликовало эту надпись здесь
            0
            Такой вопрос, а как у «Jelastic.Cloud» обстоят дела с uptime? Т.е. вопрос в следующем: есть проект, у которого не должно быть простоя вовсе, т.е. uptime желательно 100%, на облако хотелось бы вынести main сервер (mysql master, nginx, php, apache), как я понял для этого понадобится брать «Elastic VDS», что бы можно было настроить nginx, mysql.
            + если брать «Elastic VDS» будет ли динамически выделятся ресурсы по мере их потребления?

            Спасибо
              0
              Спасибо за хороший вопрос.
              uptime желательно 100%

              Uptime зависит от SLA конкретного хостинг провайдера, в данном случае от Infobox.

              на облако хотелось бы вынести main сервер (mysql master, nginx, php, apache)

              Все перечисленные стеки поддерживаются как стандартные шаблоны, т.е. не нужно покупать VDS
              Ссылки по теме
              jelastic.com/ru/docs/nginx
              jelastic.com/ru/docs/http-load-balancing
              jelastic.com/ru/docs/nginx-caching
              jelastic.com/ru/docs/apache
              jelastic.com/ru/docs/database-master-slave-replication

              Есть также shared resolver jelastic.com/ru/docs/shared-resolver
              но для Вашего случая рекомендую использовать внешний IP jelastic.com/ru/docs/public-ipv4

              + если брать «Elastic VDS» будет ли динамически выделятся ресурсы по мере их потребления?

              Но в любом случае если вы возьмете Elastic VDS — ресурсы будут выделяться динамически и не нужно платить за то, что не используется
                0
                Если говорить официально, то SLA предполагает доступность сервисов 99,99%, что является очень высоким показателем.
                По факту на уровне дата-центра за 4 года существования его аптайм составил 100%.
                Jelastic в продакшне еще всего месяц судить рано, но пока и его доступность составила 100% даже во время беты.
                0
                Как Вы понимаете, 100% аптайм гарантировать не может никто, но в целом Jelastic как раз подходит для отказоустойчивых решений. Настроить MySQL как master для репликации с другими серверами можно и без VDS. Более того, ведомые ноды также можно разместить на Jelastic, на сайте вендора есть инструкция. Конфигурация Nginx также доступна для изменения.

                Для Elastic VDS также работает масштабирование ресурсов, вот наша статья об этом.
                  0
                  Еще такой вопрос возник: какое кол-во IOPS можно получить с дисковой подсистемы?
                    0
                    На время беты ресурс IOPS Limit установлен на 100 операций в секунду, в индивидуальном порядке можем увеличить этот параметр для Вашего аккаунта по заявке в техническую поддержку.
                  0
                  А что на случай ддоса предусмотрено?
                    0
                    скорее всего что Ваше окружение вынесут на внешний IP jelastic.com/ru/docs/public-ipv4 и будут уже дальше думать чем и как Вам помочь
                      0
                      Сама платформа не включает средства для борьбы с ДДОСом. С атаками мы боремся на уровне нашего дата-центра. Как правило, успешно и оперативно справляемся.
                      При сложных случаях рекомендуем Клиентам использование внешнего айпи и пропуск трафика через специализированные сервисы.
                      0
                      Без иронии, это движение в правильную сторону. Но, а) тема сисек не раскрыта, и б) ох уж эти унылые «особенности» джеластика для LAMP-стэка.

                      Во-первых, использовать неебическую хренотень, чтобы ручками редактировать innodb_flush_method — это за гранью добра и зла. Могу поспорить, что даже внутри команды Юми никто толком не знает, чего эта штука делает.

                      Во-вторых, Jelastic это инструмент для менеджмента окружений. Гораздо правильнее было бы рассмотреть кейс, когда с помощью Jelastic реализуется процесс непрерывной интеграции сайта на UMI.CMS через dev-stage-prod-окружения. Как вносятся изменения в конфигурацию, как они мигрируют по этому процессу от дева к проду. Как осуществляется деплой проекта, откат, работа с feature-branches, их тестирование и вывод в продакшен.

                      Вот это было бы круто и по делу. А так — нет.
                        0
                        На самом деле мы получили много вопросов как мы добились таких результатов производительности для разных CMS, поэтому и рассказали немного про процесс.

                        А за идею для будущего поста спасибо! Приглашаем в соавторы-соиспытатели.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое