ГлавнаяОптимизацияBitrix apache оптимизация

Оптимизация хостинга под битрикс, Требования сканера безопасности. Bitrix apache оптимизация


Оптимизация Apache для работы при высоких нагрузках

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

 

 

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

 

Отключение неиспользуемых модулей

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

apache2ctl -M

Loaded Modules: core_module (static) so_module (static) access_compat_module (shared) alias_module (shared) auth_basic_module (shared) authn_core_module (shared) authn_file_module (shared) authz_core_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) cgi_module (shared) deflate_module (shared)

…

php5_module (shared) rewrite_module (shared) setenvif_module (shared) socache_shmcb_module (shared) ssl_module (shared) status_module (shared)

 

Каждый модуль дает какие-то возможности, но предполагает затрату ресурсов и уменьшение скорости обработки запроса. С нужными модулями Apache может быть скомпилирован сразу, тогда уменьшения производительности не происходит.

Прочитав документацию по модулям стоит определиться какие из них нужны, остальные отключить.

 

 

MPM – Multi-Processing Module

Способ работы с клиентскими запросами

Prefork — обрабатывает процессы как самостоятельные сущности, на поступающий запрос от основного процесса создается дочерний

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

 

 

Какой MPM используется можно выяснить той же командой, которая использовалась ранее, но с другим ключем

apachectl -V | grep -i mpm

Server MPM: prefork

 

Переключение MPM (если Apache собран с поддержкой всех трех) выполняется за счет отключения модуля, подключения другого и перезапуска службы.

Например если нужно сменить prefork на worker:

 

a2dismod mpm_prefork_module

a2enmod mpm_worker.load

 

Перезапускаем Apache

/etc/init.d/apache2 restart

 

Два MPM одновременно использоваться не могут, если пробовать их включить возникнет конфликт. Для каждого можно задавать индивидуальные настройки в /etc/apache2/apache2.conf (для всех mpm в нем есть отдельная секция по умолчанию).

 

AllowOverride

Для увеличения производительности имеет смысл отключать использование .htaccess за счет AllowOverride

 

Сжатие

Сжатый контент будет отдаваться значительно быстрее за счет сокращения workload в каждом ответе сервера. Читайте о том, как включить сжатие.

 

Запросы к DNS

Как любая другая служба, работающая по сети Apache может обращаться к DNS чтобы разрешить доменное имя в IP адрес. Это поведение лучше отключать директивой HostnameLookups Off

В логи при этом будут писаться только IP адреса.

 

В нагруженных системах от Apache часо отказываются оставляя только Nginx, который тоже специально настраивается.

server-gu.ru

Nginx и Bitrix. Использование их без использования апача. |

Встала тут задача поднять сервер, исключительно под сайты, написанные на базе CMS Bitrix (в силу тормознутости этой CMS, дабы своей прожорливостью она не портила жизнь всем остальным сайтам), и чтобы по максимуму быстро отдавать содержимое Bitrix-овских сайтов, решил, что Apache на сервере нафиг не нужен и что nginx-а будет вполне достаточно. Избавится от апача я решил, не потому, что имею к нему какие то притензии, а по двум причинам, во-первых, для быстрой отдачи статики все равно использоватьnginx удобней, а во-вторых, на первом серевере у меня уже использовался nginx в качестве проксирующего сервера, но поскольку админ, ответственный за добавление сайтов, не парился над тем, чтобы прописывать для сайтов в конфиге nginx-а папки со статикой, получилось, что в нем срабатывал конфиг по умолчанию, который, естественно, не знал где эта статика лежит и все равно все запросы переадресовывал апачу. То есть выйгрыш был только на отдаче больших файлов, в этом случае nginx просто отпускал apache, а сам сидел на раздаче контента конечному пользователю. И чтобы не плодить лишних конфигов (к сожалению, структура сайтов была разной и написать один универсальный конфиг для всех не представляется возможным), я решил просто убрать apache вообще. Сказано, сделано. Apache даже не ставился (единственное, что от него было поставлено — это ab для анализа производительности), а к nginx-у PHP был прикручен как FastCGI, благо описаний, как это сделать, в интернете было много. Итак, ставлю тестовый сайт на Bitrix-е — и все работает. Ну вот, думаю, счастье есть. Все, можно отдыхать. Но не тут то было. Мне просто повезло, что этот сайт был без ЧПУ и mod_rewrite от apache там просто не задействовался. Но вот, ставят сайт с ЧПУ и началось. Типовое содержимое .htaccess Битрикса для реализации ЧПУ выглядит следеющим образом:

<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-l RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$ RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L] </IfModule>

Гугление и чтение доки на сайте nginx-а показало, что конструкция

location / { root /home/www/domain.name/public_html; index index.php index.html index.htm; if (!-e $request_filename) { rewrite ^(.*)$ /bitrix/urlrewrite.php last; } }

легко и непринужденно заменяет всю пачку Apach-евских инструкций для реализации ЧПУ. Но всплыло одно НО. Битрикс после добавления товара в корзину, делает редирект на страницу товара, но не просто на ту же папку, а с какого то перепугу, дописывает в конец пути index.php. То есть, если путь к товару был, к примеру,/e-store/xml_catalog/1067/38608/, то после добавления его в корзину, Битрикс перенаправляет посетителя на/e-store/xml_catalog/1067/38608/index.php. И, ахтунг !!!, if (!-e $request_filename) совершенно игнорирует тот факт, что такой директории не существует, и понятное дело, что в несуществующей директории index.php ну никак не может быть. В итоге, срабатывает описание для файлов PHP:

location ~ \.php$ { fastcgi_pass 127.0.0.1:1026; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /home/www/domain.name/public_html$fastcgi_script_name; include fastcgi_params; }

И поскольку такого файла то нет, мы получаем ошибку: No input file specified. Чтобы избежать этого, пришлось вставить проверку на существование файла c расширением php в само описание обработчикаFastCGI, и если такого файла не существует, делать редирект на URL, но уже без файла:

location ~ \.php$ { root /home/www/domain.name/public_html; if (!-f $request_filename) { rewrite ^(.*)/index.php$ $1/ redirect; } fastcgi_pass 127.0.0.1:1026; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME /home/www/domain.name/public_html$fastcgi_script_name; include fastcgi_params; }

Еще несколько тонкостей — поскольку мы не знаем, существует ли сама директория, то нам надо запускать процесс анализа полученного урла заново, и чтобы это произошло, надо использовать именно флаг redirect, а не last или break. Во-вторых, Битрикс, как выяснилось очень привередлив к наличию слеша в конце URL, и если его там нет, он игнорирует значение последней директории в пути, что приводит к поднятию на уровень выше. То есть если вместо rewrite ^(.*)/index.php$ $1/ redirect; написать rewrite ^(.*)/index.php$ $1 redirect; — вместо описания товара мы попадаем на уровень выше, то есть на список товаров в данной категории.

http://expo-vpa.ru/

www.jajjja.com

Оптимизация хостинга под битрикс, Требования сканера безопасности

Сканер безопасности 1С-Битрикс достаточно требовательная к хостингу штука. Замечу, требования адекватные по большей части. Не все из них могут быть выполнены без вашего участия, в связи с относительностью путей к некоторым директивам и т. д. И не на все их них существует достаточное описание к устранению. А главное у вас должен быть достаточно широкий перечень доступов к серверу и понимание, что и куда следует писать. Давайте разберем некоторые из них:

Убрать все предупреждения по безопасности сайта, сдать все тесты полностью на 100%

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

Используется опасная/устаревшая версия php

Первое на что мы обратим внимание, как на критическое замечание «php опасная устаревшая версия». Тут после переписки со службой поддержки и просьбы понизить требуемый уровень php до реально существующих в стабильных ветках репозиториев ни к чему не привели;(

В общем в этом вопросе кина не будет. для устранения данного требования придется обновлять php с нестабильной ветки репозиториев или собирать ручками. В дальнейшем разумеется таким же способом. В моем случае я доставил дополнительную версию php 4.5 дабы менять их можно будет с админки хостинга, а к 5 версии претензий битрикс не имеет.

Разрешено чтение файлов по URL (URL wrappers)

allow_url_fopen = Off прописываем сразу в php.ini, поскольку ispconfig3 работает по умолчанию с представлением php FastCGI, и мы не сможем php_value прописать в .htaccess.

В случае php.ini, вид представления php не имеет значения. Если же вы используете другую панель управления, обратите внимание что в deb семействе 3 конфига php.ini, вписывайте директивы в соответствующей или можно сделать проще:

find /etc/php5 -name 'php.ini' -exec sed -i 's/allow_url_fopen = On/allow_url_fopen = Off/g' "{}" \; /etc/init.d/apache2 restart

Включить веб-антивирус

Включение веб-антивируса в 1С-Битриксauto_prepend_file. Поскольку мы редактируем php.ini то недурно будет сразу кинуть в него и веб-антивирус. В моем случае это:

auto_prepend_file = /var/www/medver.ru/web/bitrix/modules/security/tools/start.php

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

Разрешено отображение сайта во фрейме с произвольного домена

add_header X-Frame-Options SAMEORIGIN; — добавляем данную строчку в nginx, так как nginx стоит на выходе (для битрикса принципиален front-end). Если мы поставим его на apache толку не будет. По-хорошему, строку нужно закинуть в оба конфига. В админке ispconfig3, если вы ставили по моему мануалу, просто саму директиву. Если вы создавали конфиги руками (читай, сами), то вписываем строку в server, а не location.

server { add_header X-Frame-Options SAMEORIGIN; }

Включен Automatic MME Type Detection

Аналогичная ситуация, поскольку директива Header set X-Content-Type-Options nosniff. C того же модуля можно вписать их вместе.

Для apache2:

<IfModule headers_module> Header set X-Content-Type-Options nosniff Header set X-Frame-Options SAMEORIGIN </IfModule>

В Nginx просто вписываем рядом.

Server { add_header X-Content-Type-Options nosniff; add_header X-Frame-Options SAMEORIGIN; }

htaccess файлы не должны обрабатываться Apache в директории хранения загружаемых файлов

Теперь чуть посложней. Исключив .htaccess в папке upload, мы автоматически получим дополнительную ошибку, исполняются php файлы, по сему нам придется перенести весь .htaccess из папки upload в apache, а для этого нам придется явно указать папку в которой будет работать это правило, поскольку в .htaccess этого не требовалось. В противном случае мы запретим исполнение php файлов на всем сайте.

<Directory /var/www/medver.ru/web/upload> AllowOverride none <IfModule mod_mime.c> <Files ~ \.(php|php3|php4|php5|php6|phtml|pl|asp|aspx|cgi|dll|exe|shtm|shtml|fcg|fcgi|fpl|asmx|pht|py|psp|rb|var)> SetHandler text/plain ForceType text/plain </Files> </IfModule> </Directory>

PHP скрипты выполняются в директории хранения загружаемых файлов

Собственно, ошибка появляется когда вы отключили .htaccess в папке upload решение смотрим выше, поскольку оно решает две проблемы сразу. В результате у меня получилось следующее:

Теперь рассмотрим как это сделать для всех сайтов одновременно.

Добавим настройки для nginx

vim /usr/local/ispconfig/server/conf/nginx_reverse_proxy_plugin.vhost.conf.master

находим строчку include /etc/nginx/locations.d/*.conf; и вставляем перед ней код. Должно получиться так:

#для битрикс монитора add_header X-Content-Type-Options nosniff; add_header X-Frame-Options SAMEORIGIN; include /etc/nginx/locations.d/*.conf;

Далее добавляем apache2в генератор хостов

vim /usr/local/ispconfig/server/conf/vhost.conf.master

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

<IfModule headers_module> Header set X-Content-Type-Options nosniff Header set X-Frame-Options SAMEORIGIN </IfModule> <Directory {tmpl_var name='web_basedir'}/{tmpl_var name='domain'}/web/upload> AllowOverride none <IfModule mod_mime.c> <Files ~ \.(php|php3|php4|php5|php6|phtml|pl|asp|aspx|cgi|dll|exe|shtm|shtml|fcg|fcgi|fpl|asmx|pht|py|psp|rb|var)> SetHandler text/plain ForceType text/plain ;</Files> </IfModule> <IfModule mod_php5.c> php_flag engine off </IfModule> </Directory>

Дополнительно, по ходу дела, тестируя работоспособность скриптов на разных сайтах, пришлось докинуть директиву во все php.ini

session.entropy_file = /dev/urandom session.entropy_length = 128

klondike-studio.ru

Оптимизация ISPmanager под проекты на Битриксе или как я скрестили ISPmanager и VMBitrix (Битрикс окружение) / СоХабр

Возможно вы уже знакомы с таким продуктом, как «1С-Битрикс: Веб-окружение» — Linux. Очень часто это идеальное решение для проектов на базе CMS «Битрикс», но, иногда, чисто «консольное» меню не обладает необходимым функционалом для людей, работающими над проектами.

Для примера, другой популярный продукт — ISPmanager, позволяет создавать FTP аккаунты из удобной веб-панели для администраторов всего за пару кликов мышкой, в то время как из консоли вам необходимы навыки администратирования Linux. Порой просто хочется управлять своим сервером и проектами из вкладки в браузере, без помощи ssh консоли.

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

В связи с необходимым требованием работать с проектами через "user-friendly" интерфейс ISPmanager 5 и не потерять в скорости и функционале проектов, было принято решение о неком «скрещивание» этих двух систем.

Сценарий установки протестирован только на чистой CentOS 6.6 x64_86, сразу после установки стабильного ISPmanager 5 и включения в нём «Возможности» nginx. Для продвинутых пользователей, желающих использовать предложенное решение, которые ранее модифицировали какие-либо настройки в своей системе, категорически не рекомендуется устанавливать скрипты полностью в автоматическом режиме — выполняйте инструкции из них вручнуюАвтор не даёт никаких гарантий по стабильной или правильной работе предложенного решения. Все инструкции вы выполняете на свой страх и риск. Текущее версия скриптов и конфигурационных файлов находится на этапе активного тестирования Внимательно ознакомитесь с разделом «Этап 2.6 Создания дополнительных необходимых каталогов»Модуль «компрессия» в системе должен быть обязательно УДАЛЁН. Композит — ВЫКЛЮЧЕН.

Композит HTTPS Красивые сообщения об ошибках веб-сервера

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

Рассматривается следующий сценарий:

  1. Вы установили чистую CentOS 6.6 x86_64
  2. Установили ISPmanager 5, следуя официальным инструкциям
  3. В разделе «Возможности» панели ISPmanager 5 активировали Nginx

Далее можно приступать к самой оптимизации: (все ссылки в конце публикации)

  1. сначала запускаем «bitrix-env_5.1.2_patched_2.sh»
  2. копируем скрипт «isp_patch_V0.1.sh» вместе с распакованным архивом «patch_filesV0.1.zip» в произвольную директорию на сервере
  3. запускаем «isp_patch_V0.1.sh»

Поздравляю, ваш сервер с ISPmanager 5 готов для работы с проектами на Битрикс

Осталось только развернуть сайт на свежем домене: (все ссылки в конце публикации)

Буду рад любым вашим комментариям, замечаниям и пожеланиям!

Этап 1. bitrix-env.sh (или «1С-Битрикс: Веб-окружение» — Linux)

Классическая установка битрикса происходит на битрикс-окружение, которое устанавливается через скрипт www.1c-bitrix.ru/products/env/ Именно с разбора bitrix-env.sh мы и начнём оптимизацию своего ISPmanager На самом деле в самом скрипте ничего особенного нет, сначала идёт стандартная проверка дистрибутива системы, затем по результатам этой проверки устанавливается то или иное необходимое ПО. Вся магия происходит, когда скрипт добавляет «фирменный» репозиторий 1С-Битрикс и устанавливает в систему пакет bitrix-env* и bx-nginx, на них мы заострим своё внимание.

И так, наш "bitrix-env_5.1.2_patched_2.sh" ничто иное, как немного переделанный скрипт от самого 1С-Битрикс, но основная «фишка» в установке bitrix-env из него убрана, почему — расскажу дальше.

Этап 2. bitrix-env.rpm (или Основной этап конфигурации)

Целая экосистема, которую предлагает bitrix-env, нам не подходит, нагромождения потенциально конфликтующих пакетов/конфигов ISPmanager и Битрикс-окружения нам вовсе ни к чему.

Оставив только нужно на мой взгляд я перенёс всё из rpm пакета в скрипт isp_patch.sh (внимание, протестирован только на centos 6.6 x64).

Немного подробнее — далее.

Этап 2.1 bx-nginx (или Nginx с поддержкой Push & Pull)

Этот пакет, который нам предлагает Битрикс-окружение, является ничем иным, как скомпилированным nginx с модулем «push and pull», который применяется в таком функционале как, например, «Бизнес-чат», «Живые комментарии», «Видеозвонки», «Мобильное приложение».

Мы можем просто забрать себе в систему, любезно скомпилированный 1С-Битрикс, готовый бинарник nginx на свою машину с ISPmanager и избавить себя от необходимости компилировать его самостоятельно (22 и 23 строки скрипта)

Этап 2.2 bvat.bx (или автотюнер параметров ПО)

интересным составляющим «Битрикс-окружения» является скрипт bvat.bx, который прописывается в автозагрузку системы и выполняет работу по тюнингу параметров ПО, отвечающее за работу проекта (преимущественно mysql сервера и расходу оперативной памяти). Сам тюнер работает довольно просто, основываясь на текущей конфигурации системы он выставляет тот или иной заготовленный «пресет» настроек в качестве действующих параметров. Хотелось бы заметить, что в конфигурации предусмотрено изменения параметров, которые выставил bvat.bx без полного его отключения (хотя можно поступить и так).

в нашем скрипте за его установку отвечают строки 25-31

Аналогично эталонному Битрикс-окружению, свои собственные параметры для mysql сервера можно прописать в файле /etc/mysql/conf.d/z_bx_custom.cnf (которые будут применены в обход bvat.bx). Аналогично, подключением своих конфигурационных файловпосле конфигурационных файлов bvat, можно обойти его автонастройки для остального ПО, если тот или иной параметр, выставленный автоматически, вас не устраивает.

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

Этап 2.3 Настройки php

Изменяем несколько параметром в php.ini (строки 33-40 в нашем скрипте) и отключаем dav модули для php

Этап 2.4 Настройки mysql

42-48 строки скрипта копируют заранее подготовленный и настроенный my.cnf, в котором вы, наверняка захотите что-нибудь поменять уже самостоятельно

Этап 2.5 bitrixenv.ini (или директивы php необходимые для работы битрикса)

Неотъемлемой частью классического битрикс-окружения является файлик /etc/php.d/bitrixenv.ini, содержащий необходимые настройки директив, перечисленные в нём

с минимальной разницей с оригинальным файлом я скопирую его на свою машину с ISPmanager, как файл /etc/httpd/bx/bx_apache.conf (строки 50-52)

важно заметить, что этот файлик мы нигде не инклюдим намеренно, чтобы прописывать его при необходимости только отдельным Virtualhost созданных из-под ISPmanager (в секцию конфиг-apache)

Этап 2.6 Настройка nginx

Настройки nginx в моём скрипте имеют долю «автотюна» (строка 64 и 67) Остальное взято из конфигурационных файлов для nginx от Битрикс-окружения

строки 72-77 отвечают за компрессию на уровне сервера 79-82 — за push&pull

обратите внимание, на файл bx/conf/bitrix.conf важно заметить, что этот файлик мы нигде не инклюдим намеренно, чтобы прописывать его при необходимости только отдельным хостам, созданных из-под ISPmanager (в секцию конфиг-nginx)

кроме того, в нём есть блок «Some security options» с заранее подготовленными, но закоментированными опциями, имеющими отношения к безопасности хоста

Этап 2.7 Создания дополнительных необходимых каталогов

В скрипте (строки 13-19) создаются каталоги для хранения сессий и временных файлов битриксом.

Внимание, «по-умолчанию» на каталоги выставляются полные права на запись и чтение для всех пользователей на сервере и из одного хоста (сайта) с помощью скриптов можно запросто вытянуть данные с другого сайта. Подобная конфигурация является небезопасной, чтобы исправить это, можно поступить двумя способами:

1) включить хранение сессий в разделе админки «БД: Защита сессий» и создать отдельные каталоги только для временных файлов

2) либо создать отдельные два каталога (отдельные для сессии и для временных файлов), например

mkdir -p /tmp/php_sessions/ext_www/your_site.ru mkdir -p /tmp/php_upload/ext_www/your_site.ru выставить на них права только того пользователя, которыми они принадлежат chown user_of_yoursite:user_of_yoursite /tmp/php_sessions/ext_www/your_site.ru -R chown user_of_yoursite:user_of_yoursite /tmp/php_php_upload/ext_www/your_site.ru -R и прописать в конфигурацию your_site.ruphp_admin_value session.save_path /tmp/php_sessions/ext_www/your_site.ru php_admin_value upload_tmp_dir /tmp/php_upload/ext_www/your_site.rubitrix-env_5.1.2_patched_2.shbitrix_install.zipсоздание хоста.pdfisp_patch_V0.1.shpatch_filesV0.1.zip

sohabr.net

Оптимизация производительности Apache — Linux портал

Apache — популярный веб-сервер в интернет, он обслуживает неограниченное количество серверов и сайтов. Часто возникает необходимость прирастить производительность веб-сервера. Наверное лучший способ это сделать — перейти к схеме frontend+backend, но это может потребовать достаточно грозных конфигураций в приложении (например, у вас наверняка отвалятся всяческие индикаторы прогресса аплоада файлов . Другой способ — просто прирастить производительность сервера — поставить более быстрый процессор и больше памяти. Да и 1-ое и 2-ое просит много времени и ресурсов, так что на 1-ое время можно испытать ускорить apache способом оптимизации его конфигурации. Есть оптимизации, которые можно применить только при пересборке apache, другие же можно использовать без перекомпиляции сервера.

Загружайте только нужные модули

Apache — модульная программа, большая часть функций которой реализуется в модулях. При всем этом эти модули могут быть как вкомпилированы, так и собраны в виде DSO — динамических библиотеках. Большая часть современных дистрибутивов поставляет apache с набором DSO, так что не нужные модули можно просто отключить без перекомпиляции.Запускайте apache только с необходимыми модулями, чтобы уменьшить потребление памяти. Если вы решили скомпилировать apache без помощи других, то либо тщательно подходите к выбору списка модулей, которые вы включите, либо компилируйте их как DSO используя apxs в apache1 и apxs2 в apache2.

Для того чтобы отключить ненужные DSO-модули, достаточно закомментировать лишние строчки LoadModule в httpd.conf. Apache со статически скомпилированными модулями будет потреблять чуть меньше памяти, но для вас придется каждый раз его перекомпилировать для конфигурации списка модулей.

Выберете подходящий MPM

В apache каждый запрос обрабатывается в своем процессе или потоке. При компиляции apache позволяет выбирать один из нескольким MPM (Multi-processing module), которые отвечают за прослушивание портов, прием запросов и раздачу этих запросов дочерним процессам или потокам, в каких эти запросы будут обработаны.Выбор MPM зависит от нескольких обстоятельств, таких как наличие поддержки потоков в ОС, количества свободной памяти, также требований стабильности и безопасности.Если безопасность очень принципна, следует выбрать peruser MPM, пожертвовав производительностью.Если принципна непосредственно производительность, то выбор ограничивается 2-мя mpm: prefork и worker.Worker - поточный MPM, т.е. в нем каждый запрос обслуживается в отдельном потоке 1-го из дочерних процессов. Потоки — более легкие для ОС объекты, чем процессы, они более отлично употребляют память и переключения контекста для их происходят быстрее. Но, из-за того что каждый поток имеет доступ ко всей памяти процесса, worker mpm более подвержен сбоям: сбой 1-го потока может повлечь падение всего процесса, в каком находился этот поток (именно поэтому worker mpm запускает несколько дочерних процессов с несколькими потоками в каждом).

1С

Perfork - mpm употребляет несколько дочерних процессов, каждый дочерний процесс обрабатывает одно подключение. Из-за того что процесс — более тяжелая структура, он употребляет малость больше ресурсов, зато он менее подвержен сбоям — обработка каждого отдельного запроса не зависит от других процессов. К огорчению, для смены mpm требуется перекомпиляция apache. Тут проявляют свои плюсы source-based дистрибутивы: вы можете просто перекомпилировать apache и все зависимые от него пакеты, не превратив систему в свалку. Бинарные дистрибутивы выходят из этой ситуации по-разному.

Например в RHEL в apache rpm находится слету две версии apache — с worker и prefork mpm (prefork употребляется по умолчанию). Но worker mpm не поддерживает php. Так что если вы желаете php и worker mpm для вас придется компилировать его без помощи других либо отыскивать посторонние репозитории.

DNS lookup

Директива HostnameLookups включает reverse DNS запросы, так что в логи будут попадать dns-хосты клиентов вместо ip-адресов. Разумеется, что это существенно замедляет обработку запроса, т.к. запрос не обрабатывается пока не будет получит ответ от DNS-сервера. Поэтому смотрите чтобы эта директива всегда была выключена (HostnameLookups Off), а если для вас все-таки нужны dns-адреса, вы можете узнать их позже, прогнав лог в утилите logresolve (которая поставляется с apache).Не считая того, смотрите чтобы в директивах Allow from и Deny From использовались ip-адреса а не доменные имена. По другому apache будет делать два dns запроса (обратный и прямой) чтобы убедиться что клиент-тот за кого себя выдает.

Встреча BAFPUG 2011-11-05

AllowOverride

Если директива AllowOverride не установлена в ‘None’, apache будет пробовать открыть .htaccess файлы в каждой директории которую он посещает и во всех директориях выше нее. Например:

DocumentRoot /var/www/html <Directory /var/www/html/> AllowOverride all </Directory>

Если будет запрошен /index.html, apache попробует открыть (и интерпретировать) файлы /.htaccess, /var/.htaccess, /var/www/.htaccess, и /var/www/html/.htaccess. Это увеличивает время обработки запроса. Так что, если для вас нужен .htaccess только для одной директории, разрешайте его только для нее:

DocumentRoot /var/www/html <Directory /> AllowOverride None </Directory> <Directory /var/www/html/> AllowOverride all </Directory>

FollowSymLinks и SymLinksIfOwnerMatch

Если для директории включена функция FollowSymLinks, сервер будет следовать по символическим ссылкам в этой директории. Если для директории включена функция SymLinksIfOwnerMatch, apache будет следовать по символическим ссылкам только если владелец файла или директории, на которую указывает эта ссылка совпадает с владельцем обозначенной директории. Так что при включенной функции SymLinksIfOwnerMatch apache делает больше системных запросов.Не считая того, дополнительные системные запросы требуются когда FollowSymlinks НЕ УСТАНОВЛЕН. Т.о. более наилучшая ситуация для производительности — когда функция FollowSymlinks включена.

Content Negotiatio

Пытайтесь избегать content negotiaion.

MaxClients

Директива MaxClients устанавливает наибольшее количество параллельных запросов, которые будет поддерживать сервер. Apache не будет порождать больше процессов/потоков чем MaxClients.

Значение MaxClient не долно быть очень маленьким (по другому много клиентов останутся необслуженными), ну и не стоит устанавливать очень неограниченное количество — лучше не обслужить часть клиентов чем исчерпать все ресурсы, залезть в своп и умереть под нагрузкой. Хорошим может быть значение MaxClients = количество памяти выделенное под веб-сервер / больший размер порожденного процесса или потока. Для статических файлов apache употребляет около 2-3 Мб на процесс, для динамики (php, cgi) — зависит от скрипта, но обычно около 16-32 Мб.

Если сервер уже обслуживает MaxClients запросов, новые запросы попадут в очередь, размер которой устанавливается с помощью директивы ListenBacklog.

MinSpareServers, MaxSpareServers, и StartServers

Т.к. создание потока, и в особенности процесса — дорогая операция, apache делает их заранее. Директивы MaxSpareServers и MinSpareServers устанавливают как много процессов/потоков должны ожидать в готовности принять запрос (максимум и минимум).

Если значение MinSpareServers очень наимельчайшее и в один момент приходит много запросов, apache должен будет создавать много новых процессов/потоков, что создаст дополнительную нагрузку в этой стрессовой ситуации. С другой стороны, если MaxSpareServers очень велико, apache будет очень нагружать систему этими процессами, даже если количество клиентов не много.Постарайтесь установить такие MinSpareServers и MaxSpareServers, чтобы apache не создавал более Четыре процессов/потоков в секунду. Если он создаст более 4, в ErrorLog будет помещено сообщение об этом. Это — сигнал того что MinSpareServers очень не довольно.

MaxRequestsPerChild

Директива MaxRequestsPerChild устанавливает сколько запросов может обработать один дочерний процесс/поток до того как он будет завершен. По умолчанию значение этой директивы установлено в 0, что означает что однажды изготовленный процесс/поток не будет завершен никогда (ну не считая случаев остановки сервера или краха этого процесса/потока).

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

KeepAlive и KeepAliveTimeout

KeepAlive позволяет делать несколько запросов в одном TCP-подключении. Это в особенности полезно для html-страниц с множеством изображений.

Если KeepAlive установлен в Off, то для самой страницы и для каждого изображения будет создано отдельное подключение (которое нужно будет обработать master-процессу), что плохо и для сервера и для клиента. Так что для похожих случаев рекомендуется устанавливать KeepAlive в On.

Для других применений (например для download-сервера) KeepAlive может быть бесполезен и даже вреден, т.к. при включенном KeepAlive сервер закрывает соединение не слету, а ждет KeepAliveTimeout секунд нового запроса. Для того чтобы процессы не висели очень продолжительно в бесполезном ожидании, устанавливайте KeepAliveTimeout достаточно малым, около 5-10 секунд обычно достаточно.

Сжатие

HTTP-сжатие было определено в образце HTTP/1.1, и сейчас все современные клиентские программы и практически все сервера его поддерживают. Сервер может отдавать ответ в gzip или deflate, а клиентская программа незаметно для пользователя разжимает данные. Это уменьшает количество передаваемого трафика (до 75%), но естественно наращивает внедрение процессора.Но если ваш сервер посещает много клиентов с медленным подключение, сжатие может снизить нагрузку с вашего сервера из-за того что сервер сможет быстрее передать сжатый ответ и вызволить ресурсы, занятые дочерним процессом. В особенности очень этот эффект может быть заметен если у вас быстрый процессор, но не довольно памяти.Кеширование меняется директивами модуля mod_deflate. Имейте в виду, что не следует устанавливать степень сжатия gzip более 4-5 — это потребует существенно большего времени CPU, а эффект будет достаточно невелик. Ну и разумеется не нужно пробовать сжать изображения в jpg, gif и png, музыку, видео файлы и все другие бинарные файлы, которые уже и так отлично сжаты.

Кеширование на стороне клиента

Не забывайте устанавливать Expires заглавия на статические файлы (см. модуль mod_expires). Если файл не изменяется, то его всегда следует испытать закешировать на клиенте. Тогда у клиента будут быстрее загружаться страницы, а сервер освободится от лишних запросов.

Отменная статья, перепечатал с сайта Highload Web.

Читаем еще:

Похожие статьи

hpunix.org

Оптимизация сервера под Битрикс | Apache | Linux

Необходимо оптимизировать сервер для CMS БИТРИКС редакция Стандарт.

«1С-Битрикс: Веб-окружение» установленное на этот сервер выдавало производительность 150 попугаев.

Но у нас другие условия.

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

- CPU i7-4770 RAM32 ГБ DDR3 2 x 240 ГБ SATA 6 Гбит/с SSD (Soft RAID)

- Ispmanager 5 pro (Nginx+Apache)

- CloudLinux 7

Требования:

- Функционал Ispmanager 5 pro должен быть полностью сохранен.

- CMS БИТРИКС Стандарт должен показывать индекс производительности свыше 120

Квалификация: Apache, Linux, Nginx

Показать больше nginx 0.7, nginx apache, convert nginx apache, linux, wordpress magento nginx apache, nginx apache optimization, nginx apache traffic, nginx apache traffic server, nginx apache magento, nginx apache mod rewrite, nginx apache freebsd, freebsd nginx apache php mysql

( 0 отзыв(-а, -ов) ) Dnipropetrovsk, Ukraine

ID проекта: #9181724

www.freelancer.com.ru

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