В предыдущих статьях мы рассказали вам о запуске на 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 ноде.
Одним из факторов, почему сайт плохо работает на виртуальном
Для оптимальной работы 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