Комментарии 42
Александр, рассказываете красиво, но упускаете как минимум 1 момент. Пункты «Медленная отдача статических ресурсов клиентам» и «Блокировка в ожидании соединения с серверами в браузере» можно более глобально назвать «Клиентской оптимизацией» и вот тут выяснится, что парочка пунктов упущена.
Не буду их перечислять — они есть вот тут правила PageSpeed Insights, например.
Я давно и плотно работаю с «продуктом» о котором идет речь и многое из перечисленного Вами действительно в нем доведено до прекрасного уровня. Многое, но только не «клиентская оптимизация». А в этом месте можно ускорить страницу весьма сильно.
Собственно к чему я клоню: сейчас продукт, который называет себя «технологической платформой» вставляет слишком много спиц в колеса «клиентской оптимизации». Даже если разработчик на обсуждаемом продукте ооочень захочет сделать все круто — у него не получится, платформа не даст. Вот за это продукту жирный минус!
Не буду их перечислять — они есть вот тут правила PageSpeed Insights, например.
Я давно и плотно работаю с «продуктом» о котором идет речь и многое из перечисленного Вами действительно в нем доведено до прекрасного уровня. Многое, но только не «клиентская оптимизация». А в этом месте можно ускорить страницу весьма сильно.
Собственно к чему я клоню: сейчас продукт, который называет себя «технологической платформой» вставляет слишком много спиц в колеса «клиентской оптимизации». Даже если разработчик на обсуждаемом продукте ооочень захочет сделать все круто — у него не получится, платформа не даст. Вот за это продукту жирный минус!
В статье я постарался рассказать о современных технологиях, позволяющих ускорить отклик веб-приложения и как выжать из них максимум — чтобы всем было интересно и полезно. Относительно продуктов компании — ведется постоянная работа как по серверной, так и клиентской оптимизации (внимательно читаем рекомендации Google, разумеется) — но, как всегда, есть куда расти :-)
Что есть в продуктах уже сейчас по клиент-сайду:
— кэширование ресурсов в браузере
— объединение js/css в несколько больших файлов, согласитесь это очень важно
— сжатие на стороне сервера
— оптимизация порядка загрузки js/css
— CDN и шардинг доменов
— композитная технология, фишка релиза!
это не полный список.
О чем идут дискуссии по клиент-сайду:
— минификация js/css/html
По сервер-сайду:
— управляемое кэширование с настраиваемой грануляцией кэша
— веб-кластер, позволяющий снизить нагрузку на отдельные ноды и БД — и ускорить таким образом отклик
— протюненый стек tcp/ip — выйдет в виртуальной машине
это тоже не полный список, чтобы не утомлять читателей.
Что есть в продуктах уже сейчас по клиент-сайду:
— кэширование ресурсов в браузере
— объединение js/css в несколько больших файлов, согласитесь это очень важно
— сжатие на стороне сервера
— оптимизация порядка загрузки js/css
— CDN и шардинг доменов
— композитная технология, фишка релиза!
это не полный список.
О чем идут дискуссии по клиент-сайду:
— минификация js/css/html
По сервер-сайду:
— управляемое кэширование с настраиваемой грануляцией кэша
— веб-кластер, позволяющий снизить нагрузку на отдельные ноды и БД — и ускорить таким образом отклик
— протюненый стек tcp/ip — выйдет в виртуальной машине
это тоже не полный список, чтобы не утомлять читателей.
Новость о том, что работа в эту сторону ведется радует, ибо из других источников (кроме Вас) только молчание.
Но не могу не возразить некоторым Вашим доводам.
1. оптимизация порядка загрузки js/css
Расскажите что вы имеете ввиду под этим пунктом? Потому как я вижу полную противоположность Вашим словам.
Самый банальный из примеров — невозможно вынести скрипты (уже объединенные) из head в конец body. Раньше это было только для скриптов главного модуля, теперь похоже для всех кроме скриптов шаблона. А как бы «оптимизация порядка загрузки ресурсов» идет лесом… Именно к этому самая большая из моих претензий.
2. CDN и шардинг доменов
CDN — да, шардинг доменов — отсутствует в продукте (при выключенном CDN)
3. композитная технология, фишка релиза!
Не работает с объединением CSS. Исправите надеюсь, но факт что сейчас не работает
Если есть сомнения по поводу любого из моих замечаний — мои контакты в есть профиле
Но не могу не возразить некоторым Вашим доводам.
1. оптимизация порядка загрузки js/css
Расскажите что вы имеете ввиду под этим пунктом? Потому как я вижу полную противоположность Вашим словам.
Самый банальный из примеров — невозможно вынести скрипты (уже объединенные) из head в конец body. Раньше это было только для скриптов главного модуля, теперь похоже для всех кроме скриптов шаблона. А как бы «оптимизация порядка загрузки ресурсов» идет лесом… Именно к этому самая большая из моих претензий.
2. CDN и шардинг доменов
CDN — да, шардинг доменов — отсутствует в продукте (при выключенном CDN)
3. композитная технология, фишка релиза!
Не работает с объединением CSS. Исправите надеюсь, но факт что сейчас не работает
Если есть сомнения по поводу любого из моих замечаний — мои контакты в есть профиле
В текущей версии главного модуля есть возможность переносить в конец body подключения js модулей. На Б24 так подключаются js модулей im, pull, timeman.
Для этого:
1. в footer.php шаблона добавляется метод $APPLICATION->ShowBodyScripts();
2. в шаблоне или init.php указывается какие модули идут в body $GLOBALS[«APPLICATION»]->MoveJSToBody('pull');
3. дополнительно модули в body можно сгруппировать в один файл $GLOBALS[«APPLICATION»]->GroupModuleJS('im','pull');
Для этого:
1. в footer.php шаблона добавляется метод $APPLICATION->ShowBodyScripts();
2. в шаблоне или init.php указывается какие модули идут в body $GLOBALS[«APPLICATION»]->MoveJSToBody('pull');
3. дополнительно модули в body можно сгруппировать в один файл $GLOBALS[«APPLICATION»]->GroupModuleJS('im','pull');
А можно глупый вопрос? :)
Если у меня cdn работает сильно медленнее своего хостинга, это мне так повезло, или картинки слишком большие, или так и должно быть? :)
Если у меня cdn работает сильно медленнее своего хостинга, это мне так повезло, или картинки слишком большие, или так и должно быть? :)
Весь вопрос это только у вас или у клиентов сайта все наоборот.
Совсем не глупый вопрос :-) Суть CDN в том, что картинка отдается оттуда с единого для всех адреса типа: «images.cdn.com», но резолвится это DNS-имя на ближайший к клиенту IP-адрес, раздающий статику. Эти ближайшие сервера должны быть как можно ближе к точкам раздачи трафика, со скоростными каналами. В результате клиент скачает файл или посмотрит видео — максимально комфортно.
У вас же один сервер хостинга, а сервера CDN понатыканы в датацентры по всей России — самостоятельно поднимать такую инфраструктуру — безумно дорого.
У вас же один сервер хостинга, а сервера CDN понатыканы в датацентры по всей России — самостоятельно поднимать такую инфраструктуру — безумно дорого.
Совершенно согласен. Текущая реализация продукта, к сожалению, не дает разработчикам необходимых средств для клиентской оптимизации.
Вот, например, фрагмент кода главной страницы сайта продукта:
Я не призываю отказаться от подхода разработки «коробочных решений». Предоставьте разработчикам возможность гибкого управления процессом формирования страницы — и они будут вам благодарны.
Вот, например, фрагмент кода главной страницы сайта продукта:
Я не призываю отказаться от подхода разработки «коробочных решений». Предоставьте разработчикам возможность гибкого управления процессом формирования страницы — и они будут вам благодарны.
Спасибо, обсудим с коллегами.
Спасибо за понимание.
Вы же знаете, как это работает — позвольте сообществу участвовать в развитии продукта, и сообщество сделает все само. Пригласите к обсуждению хотя бы Золотых Партнеров и разработчиков крупных проектов. Мы рады будем помочь.
Вы же знаете, как это работает — позвольте сообществу участвовать в развитии продукта, и сообщество сделает все само. Пригласите к обсуждению хотя бы Золотых Партнеров и разработчиков крупных проектов. Мы рады будем помочь.
А, что конкретно в приведенном вами примере не устраивает?
Большое количество неминицифированных скриптов и CSS, принудительное подключение служебных скриптов (тот же kernel_main.js) в публичной части даже для неавторизованных пользователей. Последнее, скорее, относится не конкретно к сайту продукта, но к поведению CMS по умолчанию.
Первая строка метода ShowHead():
Даже на самом сайте продукта используется
Нет никакой возможности влиять на ход выполнения ShowHeadScripts() в контексте подключения служебных скриптов. Поправьте, если я ошибаюсь.
Первая строка метода ShowHead():
echo '<meta http-equiv="Content-Type" content="text/html; charset='.LANG_CHARSET.'"'.($bXhtmlStyle? ' /':'').'>'."\n";Даже на самом сайте продукта используется
doctype html. Достаточно <meta charset="">Нет никакой возможности влиять на ход выполнения ShowHeadScripts() в контексте подключения служебных скриптов. Поправьте, если я ошибаюсь.
1. Не минифицированные скрипты скорее соглашусь, хотя с учетом их сжатия выигрыш не такой большой
2. kernal_main.js не будет подключаться если вы не используете системные js на странице. Как вариант у вас может быть включено продление сессии пользователя, которое и подключает main.
3. «Нет никакой возможности влиять на ход выполнения ShowHeadScripts() в контексте подключения служебных скриптов. » — не совсем понял, что имеете в виду
2. kernal_main.js не будет подключаться если вы не используете системные js на странице. Как вариант у вас может быть включено продление сессии пользователя, которое и подключает main.
3. «Нет никакой возможности влиять на ход выполнения ShowHeadScripts() в контексте подключения служебных скриптов. » — не совсем понял, что имеете в виду
1. По поводу минифицирования скриптов ставил эксперимент примерно полгода назад. Был взят тиражный магазин, тесты проводились и на стилях и на скриптах. Результаты получились следующие (усреднено по всем стилям/скриптам на главной странице тиражного магазина):
Только gzip — сжатие около 78%.
Только минификация — сжатие около 15%.
И то и другое — сжатие около 82%.
Т.е. при минификации (если вы используете gzip при отдаче статики) получим доп. выигрыш в 5% от исходного объема. Учитывая сколько сил нужно упахать в минификацию — как-то нецелесообразно ее делать.
2. Действительно, если поколдовать — можно избавиться от скриптов ядра (модуля main). Правда это пока вы не включите тот самый «композит». В этом случае получите +100-150кб скриптов. Учитывая что почти каждый сайт использует jQuery — хотя бы дайте программистом выбор той библиотеки которая будет отвечать за подмену динамических областей. Но это как я понимаю на грани фантастики
Только gzip — сжатие около 78%.
Только минификация — сжатие около 15%.
И то и другое — сжатие около 82%.
Т.е. при минификации (если вы используете gzip при отдаче статики) получим доп. выигрыш в 5% от исходного объема. Учитывая сколько сил нужно упахать в минификацию — как-то нецелесообразно ее делать.
2. Действительно, если поколдовать — можно избавиться от скриптов ядра (модуля main). Правда это пока вы не включите тот самый «композит». В этом случае получите +100-150кб скриптов. Учитывая что почти каждый сайт использует jQuery — хотя бы дайте программистом выбор той библиотеки которая будет отвечать за подмену динамических областей. Но это как я понимаю на грани фантастики
Браво, Александр!
Прекрасный текст по форме, хотя и уже хорошо известный по сути.
Спасибо, всегда бы так.
ps в предпоследнем абзаце лишняя кавычка после слова продукте
Прекрасный текст по форме, хотя и уже хорошо известный по сути.
Спасибо, всегда бы так.
ps в предпоследнем абзаце лишняя кавычка после слова продукте
Спасибо :-) Я почему-то думал раньше, что достаточно понимать логику работы приложения и БД — чтобы разобраться в узких местах производительности веб-приложения. Оказалось — сильно заблуждался. Мир стал сложнее, технологий стало больше и они стали многограннее — надеюсь статейка сформирует у коллег целостную картину бытия и поможет быстрее искать и уничтожать узкие места производительности.
Спасибо Александр, оптимизации много не бывает, весьма полезно :)
У SPDY есть некоторые проблемы :-) Если соединение плохое, и сегменты теряются то весь твой мультиплексированный поток останавливается :) Поэтому это уже не модно, сейчас можно QUIC (Quick UDP Internet Connections) :-)
Эта проблема, под названием «head line blocking», не только у SPDY, а у TCP в целом. Дело не в моде :-) На базе SPDY идет разработка IETF будущего стандарта сети — HTTP 2.0
То что начали разрабатывать сдантарт HTTP 2.0 на основе SPDY пока не осознали его недостатков — это не значит что он полностью дублирует его реализацию. Пока вы пишете посты про SPDY, Google уже включил на своих серверах поддержку QUIC и утверджает что этот протокол эффективнее SPDY :-)
QUIC работает на базе null-protocol-ного формата UDP. Коллеги просто придумали свою версию TCP, которую нужно пообкатывать лет эдак 20 ;-).
1) UDP — это потери пакетов, причем немалые, хотя он успешно сейчас применяется в том же WebRTC и VoIP, играх.
2) UDP — это проблемы на NAT. Достаточно настроить WebRTC, чтобы увидеть, сколько там подводных камней — чтобы состыковать по UDP два браузера через кучу NAT, особенно в мобильных сетях. Выход для WebRTC — это кластер STUN/TURN-relay серверов, иначе в 10-20% никак.
Но для передачи некритичных данных, думаю, протокол пригодится.
1) UDP — это потери пакетов, причем немалые, хотя он успешно сейчас применяется в том же WebRTC и VoIP, играх.
2) UDP — это проблемы на NAT. Достаточно настроить WebRTC, чтобы увидеть, сколько там подводных камней — чтобы состыковать по UDP два браузера через кучу NAT, особенно в мобильных сетях. Выход для WebRTC — это кластер STUN/TURN-relay серверов, иначе в 10-20% никак.
Но для передачи некритичных данных, думаю, протокол пригодится.
Long pooling?
Мне всегда казалось, что должно быть long polling
Мне всегда казалось, что должно быть long polling
Схема TLS несколько сложнее, чем ты приводишь. Если туда добавить цепочки сертификатов, OCSP и SPDY, а также учесть, что центры сертификации расположены за пределами России, то получится весьма забавная картина.
Если решились на описание технологий\систем, ускоряющих ресурс, то упустили некоторые вещи, а именно кеширование — тут нам помогут и значительно упростят жизнь манифесты, localStorage, IndexedDB и проч.
Согласен. Но я упонялул про кэширование в браузере, без него да. никуда:
Про известные вещи типа скорости рендеринга веб-страницы и размера изображений и JavaScript, порядка загрузки ресурсов и т.п. — писать не интересно. Тема избита и убита. Если кратко и неточно — кэшируйте ресурсы на стороне веб-браузера, но… с головой. Кэшировать 10МБ js-файл и парсить его внутри браузера на каждой веб-странице — понимаем к чему приведет. Включаем отладчик браузера, наливаем кофе и к исходу дня — тренды налицо. Набрасываем план и реализуем. Просто и прозрачно.
Я уже после отправки комментария подумал о том, что (а) о кешировании было сказано и (б) если писать о кешировании, то об этом можно написать целую статью, включая серверные технологии (редиска\мемкеш\тарантул или на худоё конец MySQL с таблицами типа memory, всякие CDN и прочее). И поэтому, вполне логично что о нём было сказано так мало. Вы совершенно правы.
Но время редактирования комментария вышло и поезд ушёл.
Но время редактирования комментария вышло и поезд ушёл.
Ребята, статья весьма хорошая, но когда Битрикс можно будет нормально размещать не на мейнфреймах с тоннами оперативной памяти и SSD дисками в RAID-10?
Когда Ваш мониторинг производительности будет показывать НЕ погоду на Марсе? Почему это плохо, ну хотя бы вот поэтому: forum.searchengines.ru/showthread.php?t=787038
Когда появятся актуальные образы для KVM/OpenVZ виртуализации?
Почему существующие образы Bitrix основаны на давно устаревшей Fedora 6 и морально устаревшей CentOS 5?
Когда появится разумная документация, КАК ЗАСТАВИТЬ Битрикс работать на вменяемой скорости с помощью настройки СУЩЕСТВУЮЩЕГО сервера, а не безусловного использования Вашей сборки (в которую инъектировано порядка полусотни правок лишь по известным Вам мотивам)?
Когда Ваш мониторинг производительности будет показывать НЕ погоду на Марсе? Почему это плохо, ну хотя бы вот поэтому: forum.searchengines.ru/showthread.php?t=787038
Когда появятся актуальные образы для KVM/OpenVZ виртуализации?
Почему существующие образы Bitrix основаны на давно устаревшей Fedora 6 и морально устаревшей CentOS 5?
Когда появится разумная документация, КАК ЗАСТАВИТЬ Битрикс работать на вменяемой скорости с помощью настройки СУЩЕСТВУЮЩЕГО сервера, а не безусловного использования Вашей сборки (в которую инъектировано порядка полусотни правок лишь по известным Вам мотивам)?
Спасибо.
У Битрикс есть несколько редакций. Младшие можно размещать на виртуальном хостинге с разумными требованиями. По опыту — довольно часто забывают включить кэширование, делают неоптимальные вызовы АПИ — рождающие неоптимальные запросы в БД — вот и мейнфреймы нужны. Поставить базу на колени можно 3 строками кода же, знаете.
Ну а старшие редакции по функционалу не уступают SAP — для них мы рекомендуем веб-кластерные технологии, с ними проекты живут, развиваются, не коллапсируют как нередко бывает с самописными монолитами.
Я посмотрел вашу статейку. Тесты синтетические, даже не погода на Марсе, а смещение Доплера в галактике в созвездии Андромеды :-)
Что измеряете:
— Время на создание 1000 файлов из PHP
— MySQL inserts per second
— Скорость загрузки файлов с Яндекса
В то время, как типичное веб-приложение:
— читает с диска (точнее из кэша файловой системы в памяти операционки)
— нагружает процессор на выполнение байткода PHP
— делает ВЫБОРКИ из БД
Т.е. на диск практически не пишет :-)
Именно поэтому в мониторе производительности мы и замеряем скорость загрузки ядра продукта в секунду — создается близкий сценарий нагрузки.
Хотя сейчас обсуждаем вопрос встроенного нагрузочного тестирования кейсов типа: выборка из каталога, вставка в каталог — т.е. видите, опять бизнесовые замеры, а не марки и циферки на железках.
CentOS6 уже года 3 как минимум. Самый последний.
В виртуальную машину внесены описанные в сети настройки, проверенные нами на стенде. Разумеется в зависимости от проекта, кейсов использования — их нужно подстраивать, базу возможно тюнить и т.п. Я лично никогда не доверял всяким преднастроенным виртуальным машинам, смотрел конфиги, и настраивал по своему — в зависимости от нагрузки на проект.
Консультируем по нагрузке совершенно бесплатно, пишите в личку — сразу отвечу. Еще лучше — собрать скайп-вебинарчик и порисовать.
но когда Битрикс можно будет нормально размещать не на мейнфреймах с тоннами оперативной памяти и SSD дисками в RAID-10?
У Битрикс есть несколько редакций. Младшие можно размещать на виртуальном хостинге с разумными требованиями. По опыту — довольно часто забывают включить кэширование, делают неоптимальные вызовы АПИ — рождающие неоптимальные запросы в БД — вот и мейнфреймы нужны. Поставить базу на колени можно 3 строками кода же, знаете.
Ну а старшие редакции по функционалу не уступают SAP — для них мы рекомендуем веб-кластерные технологии, с ними проекты живут, развиваются, не коллапсируют как нередко бывает с самописными монолитами.
Когда Ваш мониторинг производительности будет показывать НЕ погоду на Марсе?
Я посмотрел вашу статейку. Тесты синтетические, даже не погода на Марсе, а смещение Доплера в галактике в созвездии Андромеды :-)
Что измеряете:
— Время на создание 1000 файлов из PHP
— MySQL inserts per second
— Скорость загрузки файлов с Яндекса
В то время, как типичное веб-приложение:
— читает с диска (точнее из кэша файловой системы в памяти операционки)
— нагружает процессор на выполнение байткода PHP
— делает ВЫБОРКИ из БД
Т.е. на диск практически не пишет :-)
Именно поэтому в мониторе производительности мы и замеряем скорость загрузки ядра продукта в секунду — создается близкий сценарий нагрузки.
Хотя сейчас обсуждаем вопрос встроенного нагрузочного тестирования кейсов типа: выборка из каталога, вставка в каталог — т.е. видите, опять бизнесовые замеры, а не марки и циферки на железках.
Почему существующие образы Bitrix основаны на давно устаревшей Fedora 6 и морально устаревшей CentOS 5?
CentOS6 уже года 3 как минимум. Самый последний.
Когда появится разумная документация, КАК ЗАСТАВИТЬ Битрикс работать на вменяемой скорости с помощью настройки СУЩЕСТВУЮЩЕГО сервера, а не безусловного использования Вашей сборки (в которую инъектировано порядка полусотни правок лишь по известным Вам мотивам)?
В виртуальную машину внесены описанные в сети настройки, проверенные нами на стенде. Разумеется в зависимости от проекта, кейсов использования — их нужно подстраивать, базу возможно тюнить и т.п. Я лично никогда не доверял всяким преднастроенным виртуальным машинам, смотрел конфиги, и настраивал по своему — в зависимости от нагрузки на проект.
Консультируем по нагрузке совершенно бесплатно, пишите в личку — сразу отвечу. Еще лучше — собрать скайп-вебинарчик и порисовать.
К счастью, та статейка с серча совершенно не моя — она была приведена как кейс буздумного и безумного использования теста производительности Битрикса :)
По поводу странности теста — я абсолюнто серьезно, речь даже идет не про виртуальный хостинг. Клиенты берут у нас сервера для миграции с VPS и на них тест производительности показывает цифры либо аналогичные либо даже меньшие, чем были ранее на заведомо более слабой по памяти/процессору/диску VPS. Причем, мы переносим машины целиком — со всеми настройками и прочим, что исключает внешние факторы.
Также объективно полезная установка Nginx в дополнение к Apache на Битрикс приводит к падению цифр производительности до очень низких. Тоже самое касается режима запуска PHP как mod_fcgid и Вы вынуждаете пользователей использовать тотально небезопасный режим PHP как модуля веб сервера Apache.
Число настроек в предсобранном образе честно говоря зашкаливает при полном отсутствии описания что делает какая из них. Настройки MySQL и PHP — это вообще отдельная тему и понять ее почти нереально. Мы на стенде так и не смогли полностью извлечь все настройки для использования на обычном сервере.
Алсо, мы хотеть — гайд по установке и оптимизации машин на Debian 7+/Ubuntu 12/14+ под Bitrix не внешними скриптами/образами, а просто по инструкции в стиле:
Вот за такие инструкции мы, как поддерживающие несколько тысяч инстансов Bitrix были бы тотально благодарны =)
По поводу странности теста — я абсолюнто серьезно, речь даже идет не про виртуальный хостинг. Клиенты берут у нас сервера для миграции с VPS и на них тест производительности показывает цифры либо аналогичные либо даже меньшие, чем были ранее на заведомо более слабой по памяти/процессору/диску VPS. Причем, мы переносим машины целиком — со всеми настройками и прочим, что исключает внешние факторы.
Также объективно полезная установка Nginx в дополнение к Apache на Битрикс приводит к падению цифр производительности до очень низких. Тоже самое касается режима запуска PHP как mod_fcgid и Вы вынуждаете пользователей использовать тотально небезопасный режим PHP как модуля веб сервера Apache.
Число настроек в предсобранном образе честно говоря зашкаливает при полном отсутствии описания что делает какая из них. Настройки MySQL и PHP — это вообще отдельная тему и понять ее почти нереально. Мы на стенде так и не смогли полностью извлечь все настройки для использования на обычном сервере.
Алсо, мы хотеть — гайд по установке и оптимизации машин на Debian 7+/Ubuntu 12/14+ под Bitrix не внешними скриптами/образами, а просто по инструкции в стиле:
- Вот такой режим апаче лучше потому что...
- Лучше использовать вот такой оптимизатор PHP опкода, потому что...
- Нужно изменить вот эти настройки MySQL, чтобы Битрикс работал быстрее и не показывал отрицательные числа в тесте производительности
Вот за такие инструкции мы, как поддерживающие несколько тысяч инстансов Bitrix были бы тотально благодарны =)
Мы тут посовещались и подумали, что отличным решением было бы:
Либо еще проще — просто рекомендованные файлы конфигурации, которые можно взять и вставать в акселератор/демона.
- В тестере проверять конфиуграцию PHP акселератора, а не просто проверять его наличие. Очень многое зависит от его параметров и как раз это Вы не проверяете, а надо бы.
- В тестере проверять конфигурацию MySQL и опять же сообщать о проблемах и рекомендованых установках
Либо еще проще — просто рекомендованные файлы конфигурации, которые можно взять и вставать в акселератор/демона.
По поводу странности теста — я абсолюнто серьезно, речь даже идет не про виртуальный хостинг. Клиенты берут у нас сервера для миграции с VPS и на них тест производительности показывает цифры либо аналогичные либо даже меньшие, чем были ранее на заведомо более слабой по памяти/процессору/диску VPS. Причем, мы переносим машины целиком — со всеми настройками и прочим, что исключает внешние факторы.
Да, тест несовершенен — но он делает то, что делает: «измеряет скорость загрузки ядра в секунду» :-). Если цифры меньше, значит стало хуже для ядра. Конечно стрест-тест АПИ не помешал бы дополнительно.
Также объективно полезная установка Nginx в дополнение к Apache на Битрикс приводит к падению цифр производительности до очень низких.
У нас nginx+apache входит в виртуальную машину, без него даже запускаться не рекомендуем.
Тоже самое касается режима запуска PHP как mod_fcgid и Вы вынуждаете пользователей использовать тотально небезопасный режим PHP как модуля веб сервера Apache.
На Битрикс24 вовсю используется режим php-fpm, как более быстрый и меньше жрущий памяти. Включение его в виртмашину — обсуждается. Php-fpm — несомненно лучше.
Число настроек в предсобранном образе честно говоря зашкаливает при полном отсутствии описания что делает какая из них. Настройки MySQL и PHP — это вообще отдельная тему и понять ее почти нереально. Мы на стенде так и не смогли полностью извлечь все настройки для использования на обычном сервере.
Какие именно, давайте поясню каждую! Сделано как можно проще же, но не проще необходимого (А.Энштейн)
Алсо, мы хотеть — гайд по установке и оптимизации машин на Debian 7+/Ubuntu 12/14+ под Bitrix не внешними скриптами/образами, а просто по инструкции
Тут пока проще брать конфиги с виртуалки и адаптировать для дебиана. Дебиан — правильная, авторитетная сборка, никто не спорит.
В тестере проверять конфиуграцию PHP акселератора, а не просто проверять его наличие.
Так и делается в админке — мы не только проверяем наличие, но и настройки каждого. Установите продукт и гляньте в админке в инструментах.
В тестере проверять конфигурацию MySQL и опять же сообщать о проблемах и рекомендованых установках
Такое есть в продукте — таблица рекомендаций по настройке mysql и анализ текущих параметров, некоторые выделены красным. Там же в админке.
Либо еще проще — просто рекомендованные файлы конфигурации, которые можно взять и вставать в акселератор/демона.
Можно брать из вирмашины смело.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Быстрое веб-приложение — трепанация сети