ГлавнаяБитриксБитрикс прекомпилятор

1С-Битрикс и PHP 7: ускоряем сайт в 2 раза за 5 минут. Битрикс прекомпилятор


Мифы о Битриксе - нагрузка на хостинг

Один из самых древних и популярных мифов – Битрикс всегда съедает очень много ресурсов хостинга, и вам неизбежно придется много платить хостеру.  И если в начале эры сайтостроения эта мысль имела под собой основание, сейчас эта информация полностью устарела.Системные требования и возможности по производительности уже давно догнали и обогнали все остальные системы, как коммерческие, так и условно-бесплатные. И после правильной настройки система способна держать максимальные нагрузки.

646

Пример нагрузочного тестирования сайта Битрикс с имитацией нагрузки в 2000 посетителей в секунду

Причины

Интересно, что,  несмотря на то, что у Битрикса есть в документации очень четкая и понятная инструкция, как следует сконфигурировать хостинг, у большинства проэктов все равно мы видим сконфигурированную с ошибками систему. Увы, большинство компаний, предлагающих услуги полного администрирования сайтов, не имеют в штате профессионального администратора хостинга – чаще всего этим занимается программист по совместительству, и у него нет времени или знаний для индивидуальной настройки системы. Чаще всего все ограничивается стандартной конфигурацией, и надеждой на хостеров датацентра. Однако, несмотря на то, что в документации настройка расписана четко и понятно, человек с улицы, далекий от администрирования, не сможет настроить – для этого необходим хотя бы начальный уровень знаний. Обычный же принцип – работает – не трогай – здесь не подойдет, система нуждается в индивидуальной и постоянной настройке В итоге — как показывает наша практика — остается много типичных проблем, которые почти всегда снижают скорость работы сайта.Немного отступлю от начальной темы поста и попробую описать самые типовые проблемы, с которыми мы сталкивались на протяжении многих лет. Надеюсь, если даже где-то вы узнаете свой собственный веб-сервер, вам немного поможет понимание сути…PHP как CGIК счастью, такой режим работы PHP уже становится редкостью. Тем не менее, еще где-то год назад таких конфигураций было достаточно много.Чем плох CGI? Тем, что на каждое обращение к скрипту запускается отдельный процесс PHP. Это долго и ресурсоемко.open_basedirЭтот параметр в PHP отвечает за ограничение доступа скриптов в те или иные директории. Очень полезно для конфигураций, в которых на одном сервере могут работать сайты разных клиентов. Благая цель — безопасность, но при этом реализовано решение, мягко говоря, «не очень»…Во-первых, есть немало вариантов «обойти» ограничения, установленные в open_basedir.Во-вторых, установка этого параметра (даже в «пустое» значение) очень негативно влияет на скорость работы PHP (файловые операции, например, include). На пустом ненагруженном сервере скорость генерации страниц может снизиться на 20-30%, а при высокой нагрузке — в 2-3 раза.Есть много альтернатив для open_basedir. Начиная с отдельной копии веб-сервера для каждого клиента, заканчивая использованием chroot.Не установлен прекомпилятор PHPПрекомпилятор служит для оптимизации и ускорения выполнения PHP-скриптов (прекомпилирует интерпретируемый код, кэширует результат и затем исполняет уже прекомпилированный код).Разница в производительности на разных проектах может достигать нескольких раз.Недостаточно памяти прекомпиляторуПрекомпилятор может быть установлен, но, например, все настройки оставлены «по умолчанию». Чем это может быть чревато? Например, тем, что будет выделено слишком мало памяти для закэшированных скриптов, обращения к новым скриптам будут вытеснять старые данные, и вся работа прекомпилятора будет неэффективной.Отсутствует FrontEnd (nginx)Двухуровневая архитектура «Backend — Frontend» — практически обязательное требование для стабильной работы любого более-менее нагруженного веб-проекта.Такая схема работы решает несколько задач:• всю статику быстро отдают «легкие» (с минимальным потреблением памяти) процессы;• backend занят обработкой только «тяжелых» запросов к скриптам;• на медленных каналах у клиентов backend не занят отдачей контента конечному клиенту — он отдает его frontend’у и свободен для обработки последующих запросов.Не отрегулировано значение MaxClients в ApacheНа non-threaded серверах этот параметр отвечает за максимальное количество процессов, которые могут быть запущены для параллельной обработки клиентских запросов.Многие думают, что чем больше — тем лучше. Во многих конфигурациях можно видеть значения и 50, и 150, и 256.Что это означает на практике. Допустим, один процесс Apache может потребить 40 Мб оперативной памяти. Если MaxClients установлено в 150, то при пиковой нагрузке (DDoS, хабраэффект, ошибки в разработке и т.п.) под все процессы потребуется примерно 6 Гб RAM. Только под Apache.Если такое количество памяти не доступно, начнет использоваться своп. И начнется общая деградация всей системы. И даже те запросы, которые могли бы быть обработаны быстро, будут обрабатываться очень долго.Гораздо лучше ограничить MaxClients разумным значением. Если количество запросов будет больше, то они просто «встанут в очередь» и будут обработаны, когда освободятся занятые процессы. Система будет стабильна.

singree.com

ускоряем сайт в 2 раза за 5 минут

ИНТЕРВОЛГА – компетентный веб-интегратор . 

Мы создаем крупные информационные веб-системы, глубоко интегрированные в бизнес Заказчика. Большинство наших проектов – комплексные, интеграционные.

Наш принцип: Мы приносим пользу бизнесу клиента за счет осмысленного применения веб-технологий. В рамках этой стратегии мы тщательно и глубоко исследуем все новые технологические и маркетинговые приемы, проверяем их работу и обоснованно консультируем наших клиентов. Ранее мы уже писали об аудите производительности ,  композитных сайтах и оптимизации нагруженных сайтов на Битриксе .

Сегодня – перевод Битрикс-проектов на php7.

1 июля 2016 компания 1С-Битрикс анонсировала версию 16.5 платформы “Управление сайтом”, а вместе с ней поддержку PHP версии 7. Это прекрасная новость, так как PHP7 работает примерно в 2 раза быстрее. Теоретически. В статье проверяем скорость работы Битрикса на PHP7 на деле.

Переход рекомендован ВСЕМ! А в особенности тем, кого хостинг ругает за слишком высокую нагрузку на процессор.

Статья о том, как перевести на PHP 7 сайт, размещенный на хостинге TimeWeb. Для других хостингов процедура аналогичная. По итогам замеряем скорость.

Исходные данные

Моем руки

  1. Делаем бекап сайта
  2. Готовимся редактировать файлы НЕ через административную панель сайта. Мы будем редактировать конфигурационные файлы хостинга. Если в них допустить ошибку, сайт перестанет открываться. Поэтому редактирование нужно выполнять либо через интерфейс хостинга, либо через SSH/FTP.
  3. Убеждаемся, что конфигурация хостинга корректна с точки зрения 1С-Битрикс. Для этого запускаем проверку системы (Настройки → Инструменты → Проверка системы). В результатах проверки не должно быть красных строк.

Переводим сайт на PHP 7

  1. Проверяем, что используется новая версия драйвера базы данных: MySqli. Как проверить и как перейти на новую версию описано в блоге 1С-Битрикс https://dev.1c-bitrix.ru/community/blogs/vad/the-new-kernel-and-the-mysqli-extension.php .
  2. Меняем версию PHP в настройках хостинга
  3. Корректируем 1 цифру в файле .htaccess
  4. Снова выполняем проверку сайта и убеждаемся что не появилось новых ошибок. См. пункт 3 в разделе “Моем руки”.
  5. В админ. панели в разделе “Настройки → Производительность → PHP” проверяем версию PHP. Минимально допустимая 7.0.8. В предыдущих версиях были серьезные ошибки. Для некоторых из них был сделан workaround в ядре Битрикса, но не для всех. 

А теперь самое интересное

Снова смотрим на оценку производительности

Как видим, количество баллов производительности (в наших кругах “попугаев”) увеличилось в 2 раза. По информации от 1С-Битрикс увеличение может достигать 3-х раз и учитывая увиденное, этому можно верить.

Примечание №1 : препятствием к переходу на PHP7 могут стать модули из Marketplace. Во-первых, в самом языке ужесточились правила написания кода. Например, в статических/нестатических методах и способах обращения к ним. Во-вторых, после перевода на PHP7 нельзя будет установить из Marketplace демо-версии платных модулей, если по ним не было выпущено обновлений после 1 июля 2016. Это связано с изменением механизма защиты этих модулей.

Примечание №2 : обновление для виртуальной машины 1С-Битрикс ожидаем в сентябре. Если Ваш сайт развернут именно так, рекомендую подождать.

Подводя итог, могу сказать что получить такое ускорение сайта на битрикс за десятки минут это просто сказка. Матерые программисты подтвердят, что никакой рефакторинг кода никогда не даст такого прироста.

Всех желающих приглашаю оставить заявку на перевод своего сайта силами нашей техподдержки (быстро и с обязательным бекапом).

А для тех кто пропустил презентацию, вот то самое видео с рассказом о приросте скорости от Сергея Рыжикова

Оцените статью:

Спасибо, ваш голос успешно добавлен!

www.intervolga.ru

Стабилизируем PHP на бою — что и почему «роняет» веб-сервер

Вы отвечаете за стабильность работы веб-проекта на PHP. Нагрузка постоянно растет, добавляются фичи, клиенты довольны. В один прекрасный день начинают появляться загадочные ошибки…
Ошибки серверного софта
… которые программисты не знают как исправить, т.к. «ломается» серверный софт, например связка apache-PHP — а клиент получает в ответ на запрос страницу о регламентных работах. Веб-разработчик часто не обладает глубокими знаниями в программировании на C в unix/linux, а сисадмин нередко, к сожалению, глубже bash в систему не погружается. Настоящий хардкор :-)
Нестабильная работа серверных скриптов
Нередко, определенные страницы веб-проекта начинают сходить с ума. Например выполняться по 15 минут и выяснить, чем же они занимаются, непросто. В прошлом посте на данную тему я описал одну из методик определения, чем занимается PHP-скрипт на боевом сервере, но чувствуется, что нужен более мощный инструмент.

На практике я часто встречаю проекты, которые сталкиваются с подобным классом ошибок «серверного софта», и в команде не всегда знают, что делать. В логе apache часто появляются сообщения о нарушении сегментации (segmentation fault), клиенты получают страницу об ошибке, а веб-разработчик с сисадмином ломают себе голову, играются с разными версиями PHP/apache/прекомпилятора, собирают PHP из исходников с разными опциями снова и снова, пишут о багах, а им доказывают, что это баги не PHP, а их кода и так до бесконечности…

В статье я хочу рассказать как можно просто и быстро найти причину, почему PHP рассыпался на боевом сервере и устранить ее — не погружаясь в прекрасный мир системного программирования на C для unix :-) От вас потребуется желание и одна чашечка кофе.

Смотрим в лог ошибок веб-сервера
Если в логе ошибок apache вы видите что-то подобное, то статья для вас:[Mon Oct 01 12:32:09 2012] [notice] child pid 27120 exit signal Segmentation fault (11) В данном случае бесполезно искать подробную информацию в логе ошибок PHP — ведь грохнулся сам процесс, а не скрипт. Если заранее не сделать на nginx симпатичную страничку о регламентных работах, то клиенты увидят аскетичную ошибку «50*».

Хочется дать кому-нибудь в морду, но кому? :-) Чтобы отвлечься от деструктивных решений, вспомним теорию.

Что такое «signal»? Это, можно сказать, средство, которое операционная система использует, чтобы сказать процессу, что он, например, не прав :-) Берет и, нарушая законы математики, делит на… 0, или насильственными действиями вызывает переполнение стека. В данном случае мы видим сигнал с номером 11 и названием «SIGSEGV». Список сигналов можно посмотреть, выполнив «kill -l»:... 11) SIGSEGV ...

Некоторые сигналы, например SIGSEGV — нельзя перехватить, поэтому ваш процесс apache-PHP будет безжалостно убит ядром без суда и следствия. Оказывается именно его перехватить — можно, но нужно лезть в исходники :-)

А за что убили то?
Теперь найдем причину, за что же убили процесс apache-PHP? Для этого нужно настроить создание дампа памяти процесса в момент убийства :-) или coredump. Да, да — до сих пор используется устаревший лет эдак на 50 термин, означающий сохранение данных с магнитных сердечников. Как только в следующий раз процесс будет убит операционной системой, будет ядром создан файл — место и его название можно настроить. Если вы в консоли, просто наберите «man 5 core». Например, можно складывать файлы в папочку так: echo "/tmp/httpd-core.%p" > /proc/sys/kernel/core_pattern

Если ничего не задать, система создаст файл с именем «core.#process_number#» в рабочей директории процесса.

Только проследите, чтобы процесс apache-PHP имел туда право записи.

Это еще не всё. По-умолчанию, скорее всего, в вашей системе отключена генерация coredump-файлов. Ее можно включить, вставив в начало скрипта запуска веб-сервера строку:ulimit -с unlimited или, чтобы сделать настройку постоянной, отредактировать файлик "/etc/security/limits.conf". Туда можно вставить:apache - core -1 Подробности по формату файла — " man limits.conf".

Однако, пока я для apache не настроил папку для coredump-файлов, ничего не работало ("/etc/httpd/conf/httpd.conf"):CoreDumpDirectory /tmp Теперь перезапускаем апач:service httpd restart

Тестируем. Вручную убьем процесс: ps aux | grep httpd … kill -11 12345

Смотрим в "/var/log/httpd/error_log":[Mon Oct 01 16:12:08 2012] [notice] child pid 22596 exit signal Segmentation fault (11), possible coredump in /tmp

В "/tmp" теперь найдем файлик с названием типа "/tmp/httpd-core.22596"

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

На месте преступления — толкуем coredump
Важно знать, что если PHP собрана без отладочных символов (ключик --enable-debug, -g для gcc при компиляции) — мы потеряем много полезной информации. Однако, если вы собрали PHP из исходников даже без этой опции, и исходники лежат рядом — этого может хватить для анализа. Еще есть очень распространенное заблуждение, что отладочная сборка влияет на производительность и потребляемую процессом память (memory footprint). Не влияет, а лишь увеличивается размер исполняемого файла. Поэтому, если не сможете разобраться в причине ошибки без отладочной сборки — попросите сисадмина собрать модуль PHP с отладочными символами. Чем открыть coredump? Конечно старой и «очень доброй» утилитой — gdb, изначально написанной верховным апостолом движения бесплатного свободного программного обеспечения Ричардом Столманом. Разобраться, как работает отладчик, не займет много времени. Можно за пару часиков поглотить один из самых занимательных учебников, а можно попросить это сделать сисадмина ;-)

Обычно открывают coredump так: gdb путь_к_выполняемому_файлу_веб-сервера путь_к_coredump

Все уважающие себя разработчики на C в unix конечно умеют пользоваться этим отладчиком, делают это, наверное, каждый день, но, к сожалению, их может не быть в вашей команде. И есть еще одно неприятное НО…

Отладка PHP в gdb — черная магия
Дело в том, что скомпилированный в байткод скрипт PHP это… не совсем программа на C ;-) Нужно, правда совсем немного, разобраться во внутренностях движка Zend — и вы все поймете довольно быстро. А именно — нужно найти в трейсе последний вызов функции execute, перейти в этот frame стека и исследовать локальные переменные (op_array), а также заглянуть в глобальные переменные движка Zend:(gdb) frame 3 #3 0x080f1cc4 in execute (op_array=0x816c670) at ./zend_execute.c:1605 (gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name $14 = 0x80fa6fa "pg_result_error" (gdb) print (char *)executor_globals.active_op_array->function_name $15 = 0x816cfc4 "result_error" (gdb) print (char *)executor_globals.active_op_array->filename $16 = 0x816afbc "/home/yohgaki/php/DEV/segfault.php" В op_array можно запутаться, поэтому полезна команда просмотра типа этой структуры:(gdb) ptype op_array type = struct _zend_op_array { zend_uchar type; char *function_name; zend_class_entry *scope; zend_uint fn_flags; union _zend_function *prototype; zend_uint num_args; zend_uint required_num_args; zend_arg_info *arg_info; zend_bool pass_rest_by_reference; unsigned char return_reference; zend_uint *refcount; zend_op *opcodes; zend_uint last; zend_uint size; zend_compiled_variable *vars; int last_var; int size_var; zend_uint T; zend_brk_cont_element *brk_cont_array; zend_uint last_brk_cont; zend_uint current_brk_cont; zend_try_catch_element *try_catch_array; int last_try_catch; HashTable *static_variables; zend_op *start_op; int backpatch_count; zend_bool done_pass_two; zend_bool uses_this; char *filename; zend_uint line_start; zend_uint line_end; char *doc_comment; zend_uint doc_comment_len; void *reserved[4]; } *

Процесс отладки заключается в хождении между фреймами стека («frame N»), переходе в каждый вызов функции «execute» и исследовании ее локальных аргументов («print name», «ptype name»). Чем меньше номер фрейма, тем вы глубже. Иногда полезно зайти в гости в экстеншн PHP и посмотреть, где произошла ошибка и почему (хотя бы попытаться понять причину).

(gdb) frame #номер# (gdb) print op_array.function_name $1 = 0x2aaab7ca0c10 "myFunction" (gdb) print op_array.filename $2 = 0x2aaab7ca0c20 "/var/www/file.php"

И так далее…

Если вы поперхнулись кофе :-), то просто запомните, что переходя между фреймами стека вызовов с помощью команды «frame #N#», можно смотреть всего определенные элементы этой структуры — и вы точно сможете установить в каком файле PHP была вызвана функция PHP, какую функцию она вызвала и т.п. — и доберетесь до причины «Segmentation Fault» или другой ошибки, убившей процесс. И объясните программистам — в чем причина и ее поправят! Быстро и, надо быть оптимистами — навсегда.

Распространенные причины ошибок
Начните просматривать coredump-файлы (или поручите это сисадмину) и вы довольно быстро научитесь классифицировать ошибки по группам: 1) Проблемы в расширениях PHP. В этом случае либо отключите расширение, либо попробуйте поиграть его настройками. Вы точно знаете, что проблема в нем, дело за малым. 2) Проблема с рекурсией, стеком. Вы можете наступить на ошибку, при которой функция библиотеки, например, pcre, входит в рекурсию и вызывает себя тысяч двадцать раз. Можно либо настроить параметры библиотеки или, если лень, добавить процессу побольше стека ("/etc/init.d/httpd"):

ulimit -s «ставим значение больше»

А текущее значение можно посмотреть командой: «ulimit -a» (man ulimit, далее ищем «ulimit»). 3) Проблемы в ядре PHP — тут нужно писать разработчикам PHP :-)

В общем, круг причин ошибки будет серьезно сокращен. Что нам и нужно.

Отладка запущенного процесса
Это еще не все. Если вы не можете получить coredump — можно подключиться к запущенному процессу и погулять по нему. Пока вы внутри процесса, его выполнение приостанавливается («ps aux | grep apache | grep 'T '» — он будет в состоянии трейсинга). Когда покинете его — он снова продолжит выполняться. Подключиться можно так: gdb -p ид_процесса
Итоги
В статье мы научились «правильно готовить» ошибки серверного софта, делать отладочные сборки apache-PHP, создавать coredump-файлы и правильно их толковать, используя символьный отладчик. Еще мы узнали, что из coredump-файла можно найти конкретный файл PHP и функцию, вызвавшую ошибку.

Теперь можно составить чеклист для менеджера для борьбы с загадочными серверными ошибками, в которых не могут разобраться ни веб-разработчики, ни сисадмины:

  1. Включить сбор coredump-файлов на сервере (сисадмин)
  2. При необходимости пересобрать apache-PHP с отладочными символами (сисадмин)
  3. С помощью gdb (выходные на его изучение) исследовать причину появления ошибки (сисадмин с веб-разработчиком)
  4. Принять меры по ее устранению или снижению частоты появления: поменять настройки, обновить софт, написать в багтрекер, отключить расширение PHP и т.п.

В заключение приглашаю всех на наш облачный сервис Битрикс24, в котором мы эффективно используем все описанные в статье технологии.

Всем удачи и стабильной работы веб-проектов!

habr.com

Установка PHP OPcache (Zend OPcache) - PHP 5.6 - 7.2

14 Октября 2015

Как увеличить производительность сервера на ОС CentOS. Часть вторая : Установка прекомпилятора PHP Zend OPcache.

В данной статье мы расскажем, как увеличить производительность виртуального сервера VPS на ОС CentOS путем установки прекомпилятора PHP Zend OPcache. Материал ориентирован на пользователей с небольшим багажом знаний в области администрирования, мы рассмотрим самые простые, и в тоже время действенные, способы повышения производительности сервера.

Установка прекомпилятора PHP Zend OPcache.

Прекомпилятор (кешер, акселератор) PHP ускоряет работу сайтов за счет кеширования скриптов PHP. На момент написания статьи, наиболее популярный и производительный прекомпилятор PHP - Zend OPcache, рассмотрим способы его установки на сервер.

Установка Zend OPcache через панель управления возможна, но практически никогда не выполняется корректно. Поэтому мы рекомендуем установить расширение из командной строки.

Установка Zend OPcache на сервер с любой панелью управления.

Вам понадобится SSH доступ к серверу и SSH клиент. Если на Вашем ПК установлена операционная система Linux — SSH клиент Вам не нужен, можете использовать для подключения по SSH стандартный Linux терминал. Владельцам компьютеров с ОС Windows мы рекомендуем использовать SSH\Telnet клиент Putty. Данная программа бесплатна и проста в использовании.

Скачать последнюю версию с официального сайта можете по ссылке.

Подключитесь к Вашему серверу по SSH от имени суперпользователя root или другого пользователя с аналогичными привилегиями.

Добавьте репозиторий remi. Чтобы добавить репозиторий remi на CentOS 6 используйте следующие команды :

wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm sudo rpm -Uvh remi-release-6*.rpm

Для установки репозитория remi на CentOS 7 используйте такие команды :

wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm sudo rpm -Uvh remi-release-7*.rpm

Проверьте текущую версию PHP с помощью команды:

php -v

Для версии PHP 5.4 используйте такую команду :

yum install --enablerepo=remi php-pecl-zendopcache

Для версии 5.5, используйте команду :

yum install --enablerepo=remi-php55 php-pecl-zendopcache

Для версии 5.6, используйте команду :

yum install --enablerepo=remi-php56 php-pecl-zendopcache

Для установки opcache на PHP 7 используйте такую команду :

yum install --enablerepo=remi-php70 php-pecl-zendopcache

После установки дополнения перезагрузите веб сервер. Для этого используйте команду :

service httpd restart

Если на Вашем сервере нет httpd - скорее всего работает связка Nginx + PHP-FPM, тогда перезагрузите PHP-FPM :

service php-fpm restart

После перезагрузки можете проверить корректность установки дополнения с помощью команды :

php -m

Если Opcache установлен корректно - под списком расширений Вы увидите подобные строки :

Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies С другими материалами по оптимизации настроек сервера можете ознакомиться по ссылкам :

Как увеличить производительность сервера на ОС CentOS. Часть первая : Установка Nginx.

Как увеличить производительность сервера на ОС CentOS. Часть третья : Быстрая оптимизация настроек веб сервера.

Если у Вас возникнут трудности в настройке - всегда можете обратиться в нашу службу технической поддержки. Открыть тикет можете здесь.

well-web.net

Нагрузочное тестирование CMS «1С-Битрикс» / Блог компании 1С-Битрикс / Хабр

Знаете анекдот про самолет, в котором есть и бар, и бассейн, и ресторан, но только при взлете стюардесса говорит: «А теперь со всем этим мы попробуем взлететь»?

Веб-разработка немного похожа на такой самолет. Заказчик хочет от веб-студии и классный дизайн, и кучу интерактива, и все службы доставки и оплаты в интернет-магазины, студия с удовольствием все это программирует… А вот хватит ли мощностей сервера на обеспечение стабильной работы сайта — непонятно. Чтобы нагрузка была прогнозируемой, чтобы задать некоторые эталонные значения, мы провели нагрузочное тестирование «1С-Битрикс: Управление сайтом» и «1С-Битрикс: Энтерпрайз».

Мы постарались так провести тестирование, чтобы клиент понимал, что можно получить на текущем оборудовании, а разработчик мог понять, каковы перспективы роста проекта. Получится ли отмасштабироваться при росте нагрузки?

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

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

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

Постановка задачи

Многие по разному понимают смысл, цель и задачи нагрузочного тестирования.

Для начала, нужно сформулировать для себя — чего же мы хотим?

Какой продукт и в каком виде тестировать? Сначала мы хотели взять реально существующий интернет-магазин, его код и базу. Но это было бы тестирование именно этого решения, другие разработчики не смогут использовать его в качестве точки отсчета. Значит, тестировать надо стандартную «коробку», заполнив ее большим количеством позиций, соответствующим крупному интернет-магазину (по нашему опыту, это около 100 000 SKU). «1С-Битрикс» работал с включенной технологией «Композитного кэша» — решения, которое сначала подгружает быстрый кэш сохраненной страницы из nginx, а следом — ajax-запросом подгружает динамические данные. Таким образом, пользователь получает страницу максимально быстро. Для оценки числа запросов в секунду мы считали именно динамические запросы.

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

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

Какие нужно создать сценарии нагрузки? По результатам анализа нагрузки на ряд крупных магазинов, трафик интернет-магазина можно разделить на 3 категории:

  1. 60% пользователей приходят и просматривают несколько страниц в каталоге, зная, какой конкретно товар им нужен.
  2. 37% пользователей выбирают нужный товар из нескольких возможных, применяют фильтрацию (smart-фильтр).
  3. 3% пользователей (стандартный показатель хорошей конверсии) положили товар в корзину и купили его.
Как именно нагружать серверы? Существует две основных модели нагрузочного тестирования проекта: закрытая и открытая. Закрытая подразумевает собой искусственную постоянную статичную нагрузку, в которой запросы «пользователей» идут статичным потоком (а не волнами, как в реальной жизни). Ее цель — выяснить поведение проекта при максимуме нагрузки, понять максимальную «пропускную способность» системы. Это верхняя планка метрики, выше нее уже не подняться.

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

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

Какой SLA выбрать для тестирования? Нам нужно было четко обозначить для себя тот порог, ниже которого мы считаем систему стабильно обслуживающей запросы. Для этого мы воспользовались статистикой ТОП-100 крупных интернет-магазинов (по версии издания «Коммерсант», 2014 г.) и выбрали две главные метрики: ответ на 99% запросов должен быть дан меньше чем за 1 секунду, а число ответов с кодом, отличным от HTTP 200, должно быть не более 0,5%. Тестирование должно вестись непрерывно в течение 24 часов.

Какой хостинг выбрать? В качестве площадки для тестирования мы выбрали хостинг Selectel с дата-центром «Цветочная-1» в Санкт-Петербурге. Selectel предоставил нам серверы самой популярной своей конфигурации — Intel Xeon E3-1270v3 3,5 ГГц, 32 Гб оперативной памяти, 2 × 240 Гб SSD-накопители в RAID 1. Один из серверов был использован как центр нагрузки, остальные, в разных конфигурациях «1С-Битрикс», мы использовали для тестирования.

Конфигурация системы В рамках тестирования серверы работали на ОС Linux CentOS 6.6 с установленным на нем пакетом «1С-Битрикс: Веб-окружение», подробнее о нем можно почитать здесь.

PHP в системе был обновлен до версии 5.6.9, а директории кэшей были смонтированы в tmpfs. Для тестирования были подготовлены три конфигурации:

1) 1 сервер. «1С-Битрикс: Управление сайтом», web и MySQL работают на одном сервере

2) 2 сервера. «1С-Битрикс: Энтерпрайз», балансировщик nginx на первом сервере, web-application на обоих серверах, MySQL мастер и запись/чтение в него — на первом сервере, MySQL slave и чтение из него — на втором сервере

3) четыре сервера. Вариант, в котором вторая конфигурация горизонтально отмасштабирована slave-машиной.

Чем тестировать? В качестве средства тестирования был выбран Яндекс.Танк. Яндекс.Танк позволяет использовать две системы генерации нагрузки — Phantom и JMeter. Phantom превосходит JMeter в плане производительности, однако не позволяет генерировать POST-логику, сохранение и последующее использование куков. По этой причине мы генерировали нагрузку с помощью JMeter.

Кто тестирует? Нам хотелось, чтобы тестирование провела независимая компания, мнению которой могли бы доверять и мы, и сторонние компании, и эксперты индустрии. Это задачу мы доверили компании ITSumma , которая с 2008 года занимается круглосуточным администрированием и технической поддержкой известных в Рунете проектов и зарекомендовала себя на рынке. Ее сотрудники являются постоянными докладчиками профильных конференций (таких как Highload, РИТ++ и др.).

Тестирование

В ретроспективе тестирование можно разбить на три этапа.

Первый этап — примерочная стрельба, в рамках которой мы подбирали максимальное число потоков, при котором будет сохраняться SLA:

Второй этап — первые попытки запустить полноценный тест. Планируя нагрузочное тестирование, нужно понимать, что определенное время займет как доработка системы, на которой будет производиться тест, так и отработка самой процедуры теста.

На этом этапе мы столкнулись с рядом сложностей. Из опыта их преодоления мы вынесли ряд уроков:

  1. Организуя нагрузочное тестирование, помните, что первый большой прогон теста будет далек от идеальных результатов. Возможно, вы что-то забудете в конфигурации ОС и софта сервера. Возможно, будут проблемы с самой системой тестирования (JMeter — это Java-приложение, со свойственными ему проблемами со сборкой мусора). Ну и главное — вы увидите тонкие места в своей системе, которые ранее не замечали и которые можно будет исправить. Например, в рамках нашего тестирования были обнаружены девять значимых багов, исправления которых выйдут в ближайших версиях продукта. Так что рассматривайте свой первый тест как инструкцию к оптимизации.
  2. Несколько очевидная вещь, которую однако стоит проговорить: во время оптимизации все изменения конфигурации на серверах должны фиксироваться. В идеале не применяйте больше, чем несколько изменений за раз. Иначе будет трудно выяснить, какое же именно действие привело к улучшению производительности.
  3. Суточное тестирование при наличии любой, не обнаруженной сразу ошибки — это потерянный день работы. После одной из итераций, когда мы внесли ряд изменений в конфигурацию, получили хорошие результаты и были тому обрадованы. Но потом обнаружили, что был отключен третий сценарий — оформление заказов пользователей, самый тяжелый в нашем случае. Пришлось запускать тестирование заново. Через сутки выяснили, что примененные изменения не ускоряют систему.
  4. Система под нагрузочным тестом — это продакшн-система, и с ней могут случится все те же типовые проблемы, которые происходят на продакшн-сайтах. У нас в одном из тестов, через 12 часов после запуска, на одном из серверов закончилось место. Поэтому жизненно необходимо поставить стандартные оповещения о проблемах на сайте в своей привычной системе мониторинга, чтобы они приходили вам на телефон. И при получении нужно немедленно бежать исправлять ситуацию, чтобы не потерять уже собранные драгоценные данные.
  5. Хорошие результаты чаще всего означают ошибки в тестировании. В одной из итераций мы получили двукратный прирост по сравнению с предыдущим тестом. Оказалось, что MySQL «вылетал» по max connections, а сайт в таких ситуация отвечал валидным для системы тестирования кодом HTTP 200.
  6. В любом тестировании очень важна «бюрократия»: делайте максимально подробное описание проведённого теста — сценарии, конфигурацию системы, логи тестирования и т.д. Все это будет полезно для последующего анализа.
Третий этап — сам тест. После того, как все процедуры отработаны, а система оптимизирована, лучше прогнать тест несколько раз. По нашему опыту, это позволяет получить действительно точный результат, который даже на 24-х часовом тестировании будет практически идентичен такому же тесту. В повторах своих тестов мы получали результаты с точностью до запросов в секунду.

Результаты тестирования

Конфигурация 1 (1 сервер, «1С-Битрикс: Управление Сайтом», редакция «Бизнес»)

Время выполнения теста: 86 892 секунды

Процентиль Яндекс.Танка

«Полка» RPS (верхняя граница — 350 запросов в секунду, включая «композитные» запросы — 167 динамических запросов в секунду).

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

Конфигурация 2 (2 сервера, «1С-Битрикс: Энтерпрайз»)

Процентиль Яндекс.Танка

«Полка» RPS (включая «композитные» запросы — верхняя граница — 550 запросов в секунду).

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

Конфигурация 3 (4 сервера, «1С-Битрикс: Энтерпрайз»)

Процентиль Яндекс.Танка

«Полка» RPS (включая «композитные» запросы — верхняя граница — 1100 запросов в секунду).

А вот здесь — отличный результат по масштабированию. Добавив еще два сервера к двухсерверной конфигурации, мы получили двукратный же прирост в производительности. Этот результат говорит о том, что вы не упретесь в вертикальные пределы «железа», дополнительные серверы позволят адекватно распределить нагрузку между машинами.

Итоги и дальнейшие планы

Этим тестированием мы старались задать некий эталон, на который могут ориентироваться разработчики при оценке производительности своих систем. Для нас очень важным результатом стало подтверждение высокой эффективности горизонтального масштабирования «1С-Битрикс»: использование четырех серверов вместо двух и дало двукратный прирост. Ну и, конечно, приятная метрика — 167 запросов на динамике в сложной системе на одном сервере.

Теперь мы планируем провести тест уже в открытой системе, чтобы выяснить для себя следующие моменты:

  1. Что происходит с системой после достижения ее пределов в рамках одного сервера, что можно в ней оптимизировать?
  2. Как быстро система восстановится после сверхвысокой нагрузки?
  3. Как получить такой инструментарий, чтобы разработчики могли оценить реальное число пользователей, которое может обслужить созданный ими проект на текущем оборудовании?
Мы обязательно расскажем о результатах этого теста и вынесенном опыте.

Полезные ссылки:

  1. Подробный отчет о нагрузочном тестировании 1С-Битрикс
  2. Доклад Алексея Лавренюка о Яндекс.Танк в рамках конференции FailOver Conference 2015
  3. Тюнинг JMeter

habr.com

Denwer c PHP 7.1.8 и MYSQL 5.7 оптимизированный для Битрикс, заметки по Битрикс на сайте camouf.ru

В последнее время, все чаще приходиться работать на Windows, хотя и не люблю эту ОС- с точки зрения разработчика сайтов. Но так или иначе, потребовался простой но работоспособный веб сервер, который можно запускать прямо в ОС- без применения виртуальных машин и прочего. Выбрал Denwer - но его нужно немного обновить и модифицировать.

Почему Denwer

Я знаю, что Denwer- достаточно давно заброшенный продукт. Максимальная версия, которую можно скачать на официальном сайте, содержит PHP 5.3 и какую-то старую версию MYSQL

В тоже время, есть современные аналоги этого продукта. Например, OpenServer или XAMPP - попробовал и эти инструменты. Но они показались мне избыточными и громоздкими.

Есть официальное Битрикс веб окружение для Windows, которое можно скачать на официальном сайте. Но оно, тоже, давно не обновлялось- да и работать с несколькими сайтам в нем не удобно (управление виртуальными хостами и портами, сделано...ни как)

В итоге: просто взял официальный Denwer и довел его до работоспособного (для Битрикс) состояния.

Скачать Denwer для Битрикс

Итак: прикладываю архив для скачивания, в нем настроенный Denwer, который включает в себя следующие отличия, от официального:

— PHP обновлен до актуального 7.1.8. — MYSQL Обновлен до версии 5.7 — Включен прекомпилятор Opcache с оптимальными параметрами для Битрикс — Включено расширение OpenSSL — Проведена настройка конфигурационых файлов php.ini и my.ini для максимальной производительности

Скачать Denwer для 1С-Битрикс

В остальном, это все тот же Denwer - в плане работы ни чем не отличается от стандартной сборки. Также создаются новые хосты (сайты) и управление базами данных через phpMyAdmin

Хотел добавить еще и nginx с memcached - но посчитал это избыточным. Для локальной разработки они наврядли понадобятся. Но вернусь к этому вопросу чуть позже.

В заключении

Само собой, 1С-Битрикс вполне запуститься и на штатной сборке Denwer Но, лично мне, работать не комфортно из за жутких тормозов

На штатной сборке вебсервера, Битрикс редакции Бизнес выдавал 2 балла производительности из 30-ти. После обновления и оптимизаций стал выдавать 41 из 30-ти.

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

Если не запускается Apache: Посмотрите не занят ли, в системе, 80-ый порт. Чаще всего, его занимает skype- просто завершите его и после этого, снова запустите Denwer. Если Skype нужен: в его настройках отключите соединение через 80-ый порт.

Автору на кофе и печеньки!

camouf.ru

Prostoy-Site | Все права защищены © 2018 | Карта сайта