Оптимизация Web сервера. Оптимизация сервера

Серверная

SVN для развертывания веб-приложения

Простое развертывание приложений и сервисов при помощи Subversion

#Серверная #Приложение #svn #deployment

Выбор типов данных в Mysql

Правила выбора типов данных для максимальной производительности в Mysql

#Серверная #Базы данных #mysql

Elastic поиск неточных соответствий

Fuzzy search на основе ElasticSearch

#Серверная #Базы данных #search #elasticsearch #elastic

Профилирование PHP с XHprof

Анализ медленных PHP скриптов с помощью XHprof

#Серверная #Приложение #php #профилирование #xhprof

Оптимизация PHP

Улучшение производительности PHP приложений

#Серверная #Приложение #php

Оптимизация сервера на Ubuntu

Улучшение производительности Web сервера на Ubuntu

#Серверная #Операционные системы #ubuntu #оптимизация #ipv6 #swap

Полнотекстовый поиск в PostgreSQL

Создание и использование полнотекстовых индексов в Postgres

#Серверная #Базы данных #postgresql

Оптимизация репликации в Mysql

Ускорение репликации в Mysql 5.6+

#Серверная #Базы данных #mysql #репликация

Оптимизация ORDER BY RAND()

Эффективная замена ORDER BY RAND()

#Серверная #Базы данных #mysql #оптимизация

Параллельное выполнение ssh команд на серверах

Как выполнять команды на нескольких серверах одновременно

#Серверная #Операционные системы #ssh

Оптимальная настройка Mysql

Правильная настройка Mysql под нагрузки и не только. Обновлено.

#Серверная #Базы данных #mysql #оптимизация

Кэширование с Nginx

Использование Nginx, как кэширующего сервера

#Серверная #Web сервер #nginx

Удаление больших объемов данных из Mysql таблиц

Использование партиций для ускорения сложных удалений

#Серверная #Базы данных #mysql

Что делать, если cp: command not found

Чаще всего такая проблема может возникать при работе скриптов на кроне

#Серверная #Операционные системы #shell #crontab

Как передать данные из NodeJS в PHP

Что делать, если часть логики написана на PHP, а часть на NodeJS

#Серверная #Приложение #nodejs #php #dnode

Как использовать индексы в JOIN запросах Mysql

3 примера установки индексов в JOIN запросах

#Серверная #Базы данных #mysql #индексы

Профилирование в MySQL

Анализ медленных запросов (профилирование) в MySQL с помощью Percona Toolkit

#Серверная #Базы данных #mysql #профилирование #оптимизация

Как обновить крон без запуска текстового редактора

Как обновить расписание crontab из скрипта и без открытия текстового редактора

#Серверная #Операционные системы #linux #crontab #continuous integration

Как удалить миллион файлов

Как правильно удалить большое количество файлов из папки на Linux'e

#Серверная #Операционные системы #linux #shell

Как работает Blockchain

Как устроена распределенная база данных на основе blockchain механизма

#Серверная #Базы данных #blockchain

Дельта индекс в Sphinx

#Серверная #Приложение

Сравнение Vertica и Mysql

Сравнение Vertica и Mysql на практике

#Серверная #Базы данных #vertica #mysql

Настройка Nginx для Magento

Как настроить веб-сервер Nginx для работы с Magento

#Серверная #Приложение #nginx #magento

MySQL Handlersocket

Повышение скорости работы запросов с MySQL Handlersocket

#Серверная #Базы данных #mysql #оптимизация

Настройки безопасности SSH

Рекомендуемые настройки SSH на сервере для безопасности

#Серверная #Операционные системы #ssh #безопасность

ruhighload.com

Оптимизация Web сервера

Web сервер — это самое первое звено в работе любого Web сайта. Он принимает запрос от клиента, формирует ответ и отправляет его обратно клиенту. Когда количество таких запросов растет, скорость работы Web сервера будет падать.

Основы оптимизации

Существуют несколько простых методик повышения эффективности работы Web сервера. Все основано на трех принципах:

Сжатие запросов
Уменьшение количества запросов
Увеличение/ограничение ресурсов

Сжатие запросов

Все современные браузеры поддерживают работу со сжатием Gzip. Web сервер сжимает содержимое ответа перед отправкой его клиенту, а браузер распаковывает его в момент получения. Так можно сэкономить до 70% размера файла. Для клиентов это будет означать более высокую скорость работы Web сайта.

Сжатие работает только для файлов текстового формата (HTML/XML, CSS, Javascript). Сжатие также приведет к дополнительной нагрузке на Web сервер, но незначительной.

Как проверить, включено ли сжатие gzip?

Уменьшение количества запросов

Каждая картинка или скрипт на Web странице — это отдельный запрос к Web серверу. 10 картинок и 3 Javaскрипта на странице приведут к тому, что Web сервер получит 14 запросов от каждого посетителя:

1 основной запрос + 10 картинок + 3 JS = 14

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

Минимизируйте количество внешних запросов со страницы (склеивание css/js, CSS спрайты).

Используйте клиентское кеширование, чтобы клиент не отправлял повторные запросы серверу. Для этого Web сервер должен отправить браузеру специальный заголовок Cache-control. Как проверить, включен ли Cache-control?

Настройка ресурсов

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

Каждый Web сервер имеет свой набор параметров и настраивается индивидуально:

Самое важное

Сжатие и уменьшение количества запросов к Web серверу принесет 90% эффекта для Ваших посетителей
Оптимизация параметров сервера поможет увеличить количество посетителей, которых он сможет обслуживать без потерь

#nginx #apache ID: 144

ruhighload.com

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

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

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

Однако и первое и второе требует много времени и ресурсов, так что на первое время можно попробовать ускорить 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, пожертвовав производительностью.

Если важна именно производительность, то выбор ограничивается двумя mpm: prefork и worker.

Worker - поточный MPM, т.е. в нем каждый запрос обслуживается в отдельном потоке одного из дочерних процессов. Потоки - более легкие для ОС объекты, чем процессы, они более эффективно используют память и переключения контекста для них происходят быстрее. Однако, из-за того что каждый поток имеет доступ ко всей памяти процесса, worker mpm более подвержен сбоям: сбой одного потока может повлечь падение всего процесса, в котором находился этот поток (именно поэтому worker mpm запускает несколько дочерних процессов с несколькими потоками в каждом).

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 запроса (обратный и прямой) чтобы убедиться что клиент-тот за кого себя выдает.

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 процессов/потоков в секунду. Если он создаст более 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.

Еще записи по теме

www.itword.net

Оптимизация сервера под Drupal с замером результатов / Блог компании ua-hosting.company / Хабр

Сама по себе инструкция о том, где что подкрутить на сервере, чтобы Drupal стал работать быстрее, встречаются на просторах интернета в разной степени детализации. Однако все встречавшиеся мне статьи обладали небольшим изъяном: я не встречал каких-либо реальных замеров, сопутствовавших настройке. Как численно меняется скорость генерации страницы? Как меняется использование памяти? Что происходит при увеличении количества параллельных запросов? Давайте проведём эксперимент. Некоторые рекомендации, изложенные в статье, носят общий характер и могут быть полезны для других CMS.

Вместо предисловия

В основу данной статьи легла подборка материалов Server tuning considerations, размещённая на официальном сайте Drupal. Из неё отобрано то, что носит наиболее универсальный характер и может быть применимо к произвольному серверу, на котором планируется использование Drupal (в частности, секции, касающиеся настройки PHP и MySQL). Эта статья не охватывает вопросы тонкой настройки самой CMS.

Экспериментальная модель

Для проверки нагрузки был создан некий эталонный тяжёлый сайт. Для этого был использован Drupal 7 и несколько популярных модулей, в том числе Views и Pathauto. В один из типов материала было добавлено числовое поле, которое могло принимать значение от 1 до 10. С помощью функции генерации контента модуля Devel было создано около 10 тыс. страниц материала данного типа и от 0 до 15 комментариев к каждому посту.

Далее был создан и размещён на главной странице блок Views, выбирающий 100 случайных страниц, где поле принимало значение 5 (т.е., если верить теории вероятности, 100 из 1000 страниц) вместе с комментариями к ним. Критерий фильтрации Global: Random был использован, чтобы страница гарантированно генерировалась по-новой при каждой загрузке. На личном тестовом сервере время генерации такой страницы составляло примерно 10 секунд. Также при подготовке был поднят тестовый интернет-магазин на базе Commerce Kickstarter и сгенерировано около 5 тыс. товаров. Однако выяснилось, что Global: Random совершенно не дружит с Search API, а без рандомизации страница с 96 продуктами грузилась ощутимо быстрее, чем предыдущая тестовая страница. Потому замеры по быстродействию интернет-магазина не проводились. Тестовые сайты были перенесены на…

Экспериментальное оборудование

Для экспериментов я позаимствовал на несколько дней свежеустановленные VPS Intel Xeon E3-1230 3.2GHz / 2-3 GB RAM / 30 GB SSD и Intel Xeon E3-1230 / 8GB DDR3 / 4x1TB SATA2 / 100Mbps Unmetered в Нидерландах (далее по тексту — VPS и Е3-1230 соответственно). На серверах были стандартно настроенные LAMP + Nginx. Основная часть замеров производилась утилитой ab с общим числом запросов 1000 и числом параллельных запросов от 10 до 50. По окончании также было запущено несколько тестов Loadimpact.

Данные «сырого» сервера

Первый замер был произведён до начала какой-либо оптимизации. Собственно, в этих замерах я остановился на 40 параллельных запросах. Полученные результаты выглядят примерно так:

На этом и последующих аналогичных графиках по оси X будет доля запросов, которые были обслужены за время, не превышающее соответствующего значения по оси Y.

Кроме того, интереса ради я запустил бесплатный тест Loadimpact, однако какой-либо ощутимой нагрузки он не создал.

Оптимизация PHP

Первое, что нужно сделать на сервере под Drupal, — выставить в php.ini значение memory_limit хотя бы 256M. Как правило, этого совершенно достаточно для большинства сайтов. А вот 128M порой оказывается маловато. Впрочем, это нельзя назвать оптимизацией, это скорее жизненная необходимость.

Для ускорения работы сайтов на уровне PHP разработчики рекомендуют использовать различные кеширующие оптимизаторы. В других источниках чаще всего упоминается APC, потому к нему я и обратился. О том, как его поставить, можно почитать в инструкции. Сейчас же нас интересуют ключевые параметры настройки. Собственно, основной параметр — размер сегмента памяти кеша, apc.shm_size. Чем более грузная страница, чем больше различных файлов подключается при исполнении, тем больше должно быть значение. Например, тестовому сайту хватило 64M. А тестовый магазин при этом значении выдал ошибку:

[Mon Jan 13 21:41:46 2014] [error] [client 176.36.31.190] PHP Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0, referer: http://s2shop.1b1.info/products?page=2 Поднятие значения до 256M вмиг убрало эту проблему. По данным модуля Devel, при разовых просмотрах сайтов включение кеширования повлияло на такие параметры:

в полтора-два раза сократилось время генерации страницы;
сократилось пиковое потребление памяти с примерно 50-55 MB до 30-32 MB для тестового сайта и с примерно 65-70 MB до 30-32 MB для тестового магазина.

О том, как повлияло включение APC на результаты бомбления с помощью ab, будет сказано немного позже. По общедоступной публичной информации, замечательные результаты даёт использование php-fpm вместо Apache + mod_php. Однако я пока не пробовал сравнивать эти две конфигурации.

Оптимизация MySQL

Один из самых простых способов оптимизировать MySQL — заменить my.cnf на my-huge.cnf. Этот файл рассчитан на системы с достаточным (2 Гб и выше) количеством оперативки и масштабным использованием MySQL. Помимо всего прочего, от стандартного конфига он отличается существенно большим размером буфера (key_buffer_size) и включением кеширования запросов (query_cache_size).

Общее изменение скорости отдачи при последовательном применении выглядит примерно так.

Е3-1230, 10 параллельных запросов

VPS, 10 параллельных запросов

Е3-1230, 30 параллельных запросов

VPS, 30 параллельных запросов

Как можно заметить, на VPS разрыв между неоптимизированным MySQL и оптимизированным заметнее, чем на E3-1230. Смею предположить, что это связано с использованием SSD дисков на VPS. Сейчас всё популярнее становятся конфигурации серверов, в которых базы данных выносятся на SSD. Учитывая, насколько существенно за последнее время они подешевели, такое решение не сильно бьёт по карману и во многих случаях позволяет заметно ускорить работу сайтов. Плюсом в пользу SSD, по моему мнению, являются и два следующих графика.

E3-1230, 50 параллельных запросов

VPS, 50 параллельных запросов

Как видим, на сервере с SATA дисками буферизация с кешированием очень быстро начинают захлёбываться. При этом на VPS с SSD дисками общая тенденция сохраняется. На VPS я попробовал ещё увеличить значения key_buffer_size и query_cache_size, благодаря чему получил незначительный, но стабильный прирост производительности (кривая MySQL 2). Впрочем, на этом этапе на обеих конфигурациях уже начинает захлёбываться процессор.

Тесты LoadImpact

Проведённые с помощью утилиты ab тесты показывают не реальную загрузку страниц сайта, а скорее качественное изменение производительности. Для каких-то более приближённых к жизни данных я провёл пару тестов с помощью Loadimpact.

На главную страницу тестового сайта были натравлены до 100 SBU, примерно равномерно распределённых по 5 разным локациям (2 в США, 2 в Европе, 1 в Австралии). Суммарный график не позволяет увидеть, напрягла ли сервер эта нагрузка хоть сколько-нибудь.
Но возрастание нагрузки становится заметнее, если смотреть графики сугубо по европейским точкам, с которыми связность лучше.
При этом общий поток данных был близок к 90 Мбит/с. Хотелось догнать канал до полочки, но не осталось кредитов.
Нагрузка на процессор становится заметной, однако Load average не идёт ни в какое сравнение с тестами ab.
В заключение я склонировал обычный небольшой информационный СДЛ и натравил на него Loadimpact из 8 разных точек. Все точки тестирования обращались к разным страницам сайта. За 10 минут количество SBU также дошло до 100.
Отдача была весьма равномерной, без каких-либо явных замедлений.
При этом сервер этого теста практически не заметил.

Вместо заключения

Я рассмотрел влияние на скорость работы сайта всего двух существенных параметров, потому буду благодарен всем, кто сможет дать дополнительные полезные советы по затронутой теме. Кроме того, где-то дней 5 после публикации тестовые среды ещё будут оставаться живы, и если у Вас есть ещё какие-то рекомендации по оптимизации или предложения по тестированию, я постараюсь за этот период воплотить их в жизнь и добавить в статью. Призываю всех обмениваться собственным опытом оптимизации и своими хитростями. И спасибо, что терпеливо дочитали.

habr.com

Настройка Apache. Ускоряем работу веб сервера

12 декабря 2015

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

В данной статье мы расскажем, как увеличить производительность сервера (выделенного или виртуального) на примере ОС CentOS с помощью быстрой оптимизации настроек веб сервера Nginx и Apache (httpd).

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

Оптимально работать с сервером по SSH, но если Вы испытываете сложности в работе с SSH - можете открывать файлы через менеджер файлов панели управления. (Инструкция по работе с SSH в первой части этой статьи)

Оптимизация настроек веб сервера Apache (httpd).

Конфигурационный файл веб сервера Apache находится по следующему пути :

/etc/httpd/conf/httpd.conf

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

StartServers 5MinSpareServers 5MaxSpareServers 20MaxClients 256MaxRequestsPerChild 0

Maxclients необходимо высчитать, опираясь на количество оперативной памяти, установленной на Вашем сервере. Также следует учесть количество памяти, используемой одним процессом веб сервера. Узнать количество потребляемой памяти одним процессом веб сервера можете с помощью утилиты top , инструкция по использованию в нашей базе знаний.

Далее отсчитайте 2\3 от общего количества оперативной памяти Вашего сервера и разделите на количество памяти, потребляемой одним процессом веб сервера. Полученное число и будет оптимальное значение MaxClients.

Например, имеем сервер с 8 Гб оперативной памяти. 2\3 от 8 будет 5.3 Гб. Один процесс веб сервера обычно потребляет около 40 Мб памяти. Считаем 5300мб \ 40мб , получаем 132. Лучше округлять в меньшую сторону. Оставляем значение 130, в итоге блок конфигурационного файла должен иметь такой вид:

StartServers 5MinSpareServers 5MaxSpareServers 20MaxClients 130MaxRequestsPerChild 0

Также включите KeepAlive, для этого найдите в конфигурационном файле строку :

KeepAlive Off

Измените Off на On :

KeepAlive On

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

/etc/init.d/httpd restart

или

service httpd restart

Оптимизация настроек веб сервера Nginx.

Конфигурационный файл веб сервера Nginx находится по следующему пути :

/etc/nginx/nginx.conf

В нем необходимо настроить количество процессов Nginx. Обычно данная настройка зависит от количества ядер процессора, которые доступны для Вашего сервера. За это отвечает директива worker_processes, в конфигурационном файле это выглядит так:

user apache;error_log /var/log/nginx/error.log warn;pid /var/run/nginx.pid;worker_processes 4;

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

Далее, до секции httpd { нужно добавить такой блок:

worker_rlimit_nofile 65536;events {use epoll;worker_connections 65536;}

Это увеличит ограничения для Nginx по количеству обрабатываемых файлов и улучшит его работу. Если в Вашем конфигурационном файле уже прописаны worker_rlimit_nofile или worker_connections - удалите их, оставьте только блок, как на образце.

В итоге начало конф-го файла должно выглядеть таким образом:

user apache;error_log /var/log/nginx/error.log warn;pid /var/run/nginx.pid;worker_processes 4;worker_rlimit_nofile 80000;events {use epoll;worker_connections 65536;}http {include /etc/nginx/mime.types;default_type application/octet-stream;log_format main '$remote_addr - $remote_user [$time_local] "$request" ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent" "$http_x_forwarded_for"';access_log /var/log/nginx/access.log main;

И так далее. Если на сервере наблюдается повышенная нагрузка на диск - отключите лог доступа, за это отвечает настройка access_log, установите ее значение таким:

access_log off;

(Просмотреть нагрузку на диск можете с помощью утилиты top)

Также Вы можете включить в Nginx Gzip сжатие. Это может ускорить загрузку Вашего сайта, а также это выгодно в seo продвижении, однако рекомендуем проверить скорость загрузки после включения Gzip, т.к. на сайты с большим количеством запросов это может повлиять негативно. Чтобы включить Gzip сжатие в Nginx, нужно добавить в секцию http { такой код:

gzip on;gzip_comp_level 5;gzip_min_length 10240;gzip_proxied expired no-cache no-store private auth;gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;gzip_disable "msie6";

Добавьте этот код на следующей строке после http { Чтобы это выглядело так:

use epoll;worker_connections 65536;}http {gzip on;gzip_comp_level 5;gzip_min_length 10240;gzip_proxied expired no-cache no-store private auth;gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;gzip_disable "msie6";include /etc/nginx/mime.types;default_type application/octet-stream;

Если ниже в коде встречаются настройки Gzip - удалите их.

После завершения настройки, выполните перезагрузку Nginx командой:

/etc/init.d/nginx restart

или

service nginx restart

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

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

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

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

well-web.net

Оптимизация сервера. Нет лагам! - Всё о CSS - Статьи

1. Требования к "железу" и подключению Одна из причин лагов на сервере - недостаточная мощность компьютера или недостаточная скорость и надежность сетевого соединения. На самом деле ознакомиться с этим пунктом желательно еще до того как вы решите создавать сервер.

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

- Оперативная память Наиболее важное системное требование. Зависит в первую очередь от числа слотов на сервере. Также зависит от модов и плагинов, но в меньшей степени. Во время работы HLDS сервер потребляет в среднем 8-12Мб на 1 игровой слот, но поскольку это значение может достаточно сильно варьироваться, то рекомендуемым значением является 20Мб на слот. Таким образом при определении необходимого размера памяти под сервер руководствуйтесь требованиями:

10 слотов на сервере = 200Мб RAM 12 слотов на сервере = 240Мб RAM 16 слотов на сервере = 320Мб RAM 20 слотов на сервере = 400Мб RAM 24 слота на сервере = 480Мб RAM и т. д.

- Процессор Нагрузка на процессор во многом зависит от того будут ли на сервер установлены моды, и если да то какие. например сервер с Zombie-модом будет расходовать ресурсы CPU раза в 2 больше чем простой паблик. Также многое тут зависит от числа слотов, от требуемого FPS сервера. В общем для примерной оценки можно сказать что для нормальной работы паблика на 20 слотов с последней версией AMXX без дополнительных модов подойдет любой процессор Intel/AMD с частотой 2Ггц. Если вы собираетесь поднимать более одного сервера, то желательно(но не обязательно) чтобы и ядер в процессоре было больше одного.

Остальные параметры железа играют незначительную роль и рассматривать их подробно не будем.

- Сетевое соединение (Если вы создаете сервер только для локалки, вам этот пункт не нужен) Требование к скорости соединения с интернетом зависит в первую очередь от числа слотов, а также, в меньшей степени от плагинов. Наиболее требователен HLDS сервер к исходящей скорости (скорости отдачи), с этим нужно быть внимательнее, поскольку многие провайдеры делают в своих безлимитных тарифах исходящую скорость (скорость отдачи) заметно ниже, чем входящую скорость (скорость закачки). Необходимая исходящая скорость на 1 слот примерно 15 кбайт/сек (120 кбит/сек) Необходимая входящая скорость на 1 слот примерно 2 кбайт/сек (16 кбит/сек) Заметим, что реально средний потребляемый трафик, будет несколько ниже приведенных значений, но скорость сильно меняется в процессе работы сервера, поэтому нужно руководствоваться максимальными значениями. Умножаем эти значения на число слотов на сервере и получаем требование к скорости.

2. FPS сервера

FPS сервера означает скорость работы сервера. Не стоит путать его с клиентским FPS, которые означают число кадров в секунду на мониторе клиента. Latency игроков зависит в том числе и от того, насколько быстро сервер обрабатывает полученные от клиентов пакеты данных и формирует отправляемые пакеты клиентам. То есть чем больше FPS сервера, тем быстрее он работает и тем ниже пинг игроков. Но высокое значение FPS потребует большей нагрузки сервера на процессор. Методы повышения FPS: Linux На линуксе все очень просто: добавляем в параметры командной строки -pingboost 3 для обеспечивания максимальной нагрузки на CPU и максимального FPS. Если нагрузку надо снизить то понижаем значение до -pingboost 2 или -pingboost 1.

Windows Тут все несколько сложнее. По-умолчанию в Windows установлена слишком низкая частота MMTimer(мультимедиа таймер), в следствии чего HLDS сервер обрабатывает пакеты с низкой частотой, из-за этого fps сервера не будет больше 64, что хорошему пингу не способствует. Есть 2 пути решения этой проблемы:

- Увеличение частоты mmtimer. Самый простой способ - запуск любого приложения Windows, который увеличивает частоту mmtimer, например Windows Media Player. Просто запускаете WMP в фоновом режиме и FPS увеличивается до 500 а возможно и до 1000. Во время работы сервера в зависимости от нагрузки на процессор FPS изменяется в диапазоне от 150 до 500 или до 1000. Также можно использовать Booster 1.7 (я юзаю этот, можно 2.40) - плагин к Metamod. Действует он таким же образом, изменяя mmtimer для обеспечения заданного FPS. Вот настройки Booster 1.70 по-умолчанию: (добавлять в server.cfg) booster_show_connmsg 1 booster_autofps 150 booster_minsleepms 3 booster_force_systicrate 0 booster_cpu_enabled 0 booster_cpu_spikemax 3 booster_cpu_spikelevel 75 booster_cpu_mminc 2 Из всех этих настроек наиболее важны booster_autofps и booster_minsleepms, первая означает каким FPS должен быть в среднем, вторая ограничивает максимум FPS следующим образом, например: booster_autofps 150 означает, в среднем FPS сервера будет около 150 fps booster_minsleepms 3 означает, что максимум FPS сервера = 1000/3 = 333 fps Настраивать их нужно по своему усмотрению, в зависимости от нагрузки сервера на ваш процессор. Помните, что не всегда имеет смысл гнаться за слишком высоким FPS, иногда лучше снизить нагрузку. Отличия в пинге игроков и нагрузке на CPU между серверами работающие допустим на 200 и на 500 FPS достаточно небольшие. Эти же самые различия для серверов к примеру на 64 и на 200 FPS гораздо больше. То есть пинг не будет снижаться пропорционально увеличению FPS. Важно, если вы используете Booster - никаких других приложений, увеличивающих частоту mmtimer не должно быть запущено, иначе контроль максимума fps booster_minsleepms теряет смысл. Функция мониторинга нагрузки CPU - booster_cpu_enabled 1 работает только на английской версии Windows и только для одноядерных процессоров. Есть еще один плагин схожий по функциям, но шире по настройкам и возможностям, чем Booster. Это ALX Lowping. Использовать его можете на свое усмотрение, но на данный момент пока что плагин довольно "сырой" и содержит баги.

- Обработка пакетов HLDS в необходимое время. При этом способе сервер HLDS обрабатывает пакеты только в то время, когда это необходимо, то есть, когда приходит пакет от клиента. FPS сервера будет увеличен ровно настолько, насколько это нужно для обработки пакета. Поскольку этот способ не требует увеличения частоты mmtimer, то он может неплохо сэкономить ресурсы CPU. Для этого нужно установить плагин Booster Lite Настройки Booster Lite по умолчанию: sys_ticrate 10000 booster_lite_mode 0 //контролирует степень нагрузки на CPU (от 0 до 3) 0 - самый высокий уровень, наиболее эффективно понижает пинг, 3 - самый низкий уровень, фактически отключает Booster-Lite booster_lite_extra_sleep_frequency 10 Использование Booster-Lite позволяет добиться такого же, а возможно даже и лучшего результата, чем при использовании Booster. И при этом к тому же нагрузка на процессор будет существенно меньшей даже если ставить booster_lite_mode 0. Есть лишь один минус - при использовании Booster-Lite нельзя запускать никакие приложения, повышающие частоту mmtimer (Windows Media Player, Winamp, QIP и т.д.). Иначе последствия будут непредсказуемыми, начиная от ускорения игрового времени на сервере и заканчивая вылетом сервера с ошибкой.

Какой из двух методов повышения FPS выбрать решать вам. Можно еще использовать Booster версии выше чем 2.0, там объединены функции Booster 1.7 и Booster-Lite, но его использование повышает риск падения сервера. Если у вас несколько серверов и многоядерный процессор и вы хотите распределить разные сервера(нагрузку) по разным ядрам, не используйте Booster 1.70 или ALX LowPing, поскольку несмотря на заданное соответствие (Affinity), нагрузка всех серверов всегда будет ложиться только на 1 ядро.

3. Защита от атак

Сервер может сильно лагать или даже зависнуть в случае успешно проведенной DDos атаки. Для защиты от атак и эксплоитов рекомендуется использовать программу Anti CSDoS. Все что от вас требуется это запустить программу, нажать кнопку "Patch HLDS" и оставить в фоновом режиме. Последняя версия Anti CSDoS 3.2 защищает от всех известных атак практически любую версию сервера.

4. HLDS совместно с другими программами

Что делать, если вы хотите поиграть на собственном сервере, но как только на него заходите, он начинает ужасно лагать? Тут все дело в расстановке соответствий и приоритетов. Заходите в диспетчер задач (Ctrl+Alt+Del) находите в списке "Процессы" hlds.exe правая кнопка -> приоритет - выше среднего. На процесс hl.exe приоритет ставьте ниже среднего, но если это приведет к падению FPS(клиента), то лучше оставить средним.

team-sr.clan.su

Удаленная оптимизация сайтов и работы серверов Linux, Windows ➤it-24.pro

Оптимизация и настройка серверов это?

Для надежного функционирования вашего сайта важно качественное обслуживание серверов и постоянная техническая поддержка. Настройка сервера – одна из важнейших процедур перед запуском интернет-ресурса, ведь от этого зависит скорость работы и стабильность вашего сайта, поэтому данный процесс лучше доверить опытным специалистам. Команда it-24.pro имеет многолетний опыт по удаленной настройке серверов и предлагает широкий спектр услуг как для новых клиентов, так и для уже работающего ресурса, который нужно оптимизировать и усовершенствовать.

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

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

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

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

Работаем удаленно

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

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

После согласования документа с заказчиком, мы приступаем к проведению технических работ такого характера:

настройка и изменение конфигурации ядра ОС: Windows, Linux и FreeBSD под высокие нагрузки;
работа с MySQL – задание оптимальных параметров буферу и кешированию, перевод файлов БД в оперативную память, отказоустойчивая кластеризация;
работа с NGINXS – задание оптимальных параметров кеширования, сохранение логов в системный журнал, организация работы напрямую с memcashed, перевод на Unix socket, настройка worker, работа с SSL;
работа с PHP – opcach, увеличение memory limit, сохранение сессий в memcashed;
работа с Memcashed – оптимизация использования памяти;
работа с Apache – настройка worker, сжатие, работа с ДСН.

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

Что дает оптимизация сервера

Удаленная оптимизация сервера позволит повысить его производительность в десятки раз, без каких-либо затрат на аренду дополнительных мощностей или на закупку более мощного оборудования. Устойчивость к сбоям и взломам будет многократно повышена. А в случае возникновения непредвиденных ситуаций, заказчик будет иметь твердую гарантию того, что данные на сервере будут сохранены в полном объеме и быстро восстановлены.

Заказывая эту услугу у нас, заказчик получает ряд преимуществ:

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

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

it-24.pro