Оптимизируем VPS за 5$ (512MB RAM / 1 CPU) так, что сайт на wordpress выдерживает нагрузку в 42,735,587 хитов в день

Когда вы приобретаете сервер VPS с 256MB или 512MB оперативной памяти на борту и лишь часть мощности процессора, то использовать для таких сервисов как MySQL/PHP/Apache настройки по умолчанию является очень плохой идеей. В настоящее время у меня запущено 3 сайта на самом дешевом тарифном плане с 512MB RAM/1 CPU. Не уверен полностью, но посещаемость составляет порядка 5-10 тысяч посетителей в день. Далее я хочу поделиться инструкцией как оптимизировать LAMP используя всего лишь 512 MB и при этом не уходя в swap. Обычно при такой настройки используется 256 – 378Mb памяти и все работает довольно быстро.

Определяем доступную память и активность swap.

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

$ free -m

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

$ ps -eo pmem,pcpu,rss,vsize,args | sort -k 1 -r | less


Настраиваем LAMP сервер для потребления малого количества оперативной памяти. Останавливаем, отключаем ненужные сервисы

Первый и очевидный вопрос, который необходимо задать — это «какие сервисы мне не нужны в использовании?». Недавно, я обнаружил очень удобную утилиту для управления сервисами. Она называется "sysv-rc-conf" и управляет сервисами при помощи псевдографики и флажками. Выгдялит вот так:



Здесь представлен список сервисов, которые я изменил.

  • Postfix. Этот сервис позволяет отправлять и получать почтовые email сообщения для домена. Я использую для этих целей Google Apps для отправки почты и mailchimp для новостных подписчиков. Таким образом я остановил и отключил этот сервис.
  • Bind9. Он нужен для управления DNS записями Вашего домена. Его можно отключить, так как все DNS записи хранятся у хостера.
  • SSHD. Имеются и другие реализации, которые используют гораздо меньше памяти, но они не поддерживают sftp, поэтому данный сервис я оставил без изменений.


Не запускайте X-сервер, выключите все ненужные сервисы и настройте Apache, MySQL, PHP только с базовой необходимой функциональностью.

Apache

Самая большая проблема Apache — это объем оперативной памяти, который он использует. Я буду рассматривать следующие способы ускорения работы и снижения потребления оперативной памяти:

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


Настроить Apache на использование только наименьшего количество запущенных дочерних процессов


Prefork — это где случается настоящая магия. Это то, где мы говорим Apache генерировать много процессов. По умолчанию выделяется большое количество, что и приводит к потреблению оперативной памяти сервера. Убедитесь, что apache2.conf не настроен для запуска слишком большого количества серверов или имеет множество запасных. Ниже пример:


<IfModule mpm_prefork_module>
    StartServers          1
    MinSpareServers       1
    MaxSpareServers       3
    MaxClients           10
    MaxRequestsPerChild 3000
</IfModule>
 
<IfModule mpm_worker_module>
    StartServers          1
    MinSpareThreads       5
    MaxSpareThreads      15 
    ThreadLimit          25
    ThreadsPerChild       5
    MaxClients           25
    MaxRequestsPerChild 200
</IfModule>

Также обязательно отрегулируйте параметр "KeepAliveTimeout", установив значение 10 или 15. На мой взгляд, 15 секунд слишком много, чем маленькой странице требуется для просмотра и короче, чем требуется для длительного просмотра страницы.

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

Настроенный по умолчанию веб-сервер Apache подгружает слишком много ненужных модулей. Проверить какие модули установлены и включены можно следующей командой:


# apache2ctl -M

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

LoadModule dir_module modules/mod_dir.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule alias_module modules/mod_alias.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule rewrite_module modules/mod_rewrite.so

Вам необходимо закомментировать остальные модули для экономии памяти. Или же вы можете включить/отключить модули через командную строку. Для включения воспользуйтесь командой:


# a2enmod module_name

Для отключения:


# a2dismod module_name

После проделанных манипуляций вам необходимо обязательно перезагрузить веб-сервер Apache:


# service apache2 restart

Уменьшаем журналирование

Если вы хотите добиться максимальной производительности, вам определенно нужно ограничить журналирование. На моем сервере я установил уровень «error» (ошибок). Также, если вам не нужна детальная статистика, вы можете отключить логирование User-Agent или the http-referer.


# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a <VirtualHost>
# container, error messages relating to that virtual host will be
# logged here.  If you *do* define an error logfile for a <VirtualHost>
# container, that host's errors will be logged there and not here.
#
ErrorLog ${APACHE_LOG_DIR}/error.log
 
#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel error

Меня устраивают такие настройки, ну а вы сами решайте.

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

Тонкая настройка MySQL для использования малого количества оперативной памяти довольно проста.
Далее мы будем рассматривать следующие типы настроек MySQL:

  • Вещи, которые мы можем отключить;
  • Оптимизация параметров MySQL сервера;
  • Сторонние инструменты настройки конфигурации MySQL.


Для оптимизации MySQL нам необходимо отредактировать файл /etc/mysql/my.cnf.

Вещи, которые нам необходимо выключить

Mysql предоставляет несколько движков хранения таблиц. Два их них наиболее популярны — это InnoDB и MyISAM. Основные различия между ними:
  • MyISAM предлагает блокировки на уровне таблиц, это значит, что когда информация записывается в таблицу, то вся таблица блокируется и если в этот момент будут еще записи, которые должны выполнится одновременно в ту же таблицу, то они должны будут подождать, пока первая запись добавиться успешно;
  • InnoDB, с другой стороны предлагает блокировки на уровне строк, это значит, что когда происходит запись в строку, то только эта единичная строка блокируется; остальные же доступны для записи.


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

Если вы решили использовать MyISAM таблицы, то вам необходимо добавить следующие строки в конфигурационный файл my.cnf:


default-storage-engine=MyISAM
default-tmp-storage-engine=MyISAM

Если у вас будут только MyISAM таблицы, вы можете отключить InnoDB движок, тем самым сэкономив оперативную память, добавив лишь одну строку в my.cnf:


skip-innodb

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


#!/bin/bash
 
MYSQLCMD=mysql
 
for db in `echo show databases | $MYSQLCMD | grep -v Database`; do
        for table in `echo show tables | $MYSQLCMD $db | grep -v Tables_in_`; do
                TABLE_TYPE=`echo show create table $table | $MYSQLCMD $db | sed -e's/.*ENGINE=\([[:alnum:]\]\+\)[[:space:]].*/\1/'|grep -v 'Create Table'`
                if [ $TABLE_TYPE = "InnoDB" ] ; then
                        mysqldump $db $table > $db.$table.sql
                        echo "ALTER TABLE $table ENGINE = MyISAM" | $MYSQLCMD $db
                fi
        done
done

Оптимизируем параметры MySQL сервера

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

Key buffer size

Это один из самых важных параметров, влияющий на потребление оперативной памяти и производительности, который необходимо оптимизировать. MySQL пытается положить все, что проиндексировано в key buffer, поэтому этот параметр приносит огромную производительность. SQL-запрос будет подан непосредственно из оперативной памяти RAM. Я не могу сказать, какой размер вы должны установить для key buffer, потому что только вы знаете, сколько RAM имеется у вас свободной.

The Query Cache

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

Ниже приведены три переменные, которые влияют на то, как работает ваш кэш запросов:


query_cache_size
query_cache_limit
query_cache_type


Maximum Number of Connections

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

The table Cache

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

Ниже приведен корректный my.cnf, который я оптимизировал на моем VPS с самым низким тарифным планом.
Мой my.cnf

[mysqld]
     port            = 3306
     socket          = /var/lib/mysql/mysql.sock
     skip-locking
     key_buffer = 16K
     max_allowed_packet = 1M
     table_cache = 4
     sort_buffer_size = 64K
     read_buffer_size = 256K
     read_rnd_buffer_size = 256K
     net_buffer_length = 2K
     thread_stack = 64K
 
     # For low memory, InnoDB should not be used so keep skip-innodb uncommented unless required
     skip-innodb
 
     # Uncomment the following if you are using InnoDB tables
     #innodb_data_home_dir = /var/lib/mysql/
     #innodb_data_file_path = ibdata1:10M:autoextend
     #innodb_log_group_home_dir = /var/lib/mysql/
     #innodb_log_arch_dir = /var/lib/mysql/
     # You can set .._buffer_pool_size up to 50 - 80 %
     # of RAM but beware of setting memory usage too high
     #innodb_buffer_pool_size = 16M
     #innodb_additional_mem_pool_size = 2M
     # Set .._log_file_size to 25 % of buffer pool size
     #innodb_log_file_size = 5M
     #innodb_log_buffer_size = 8M
     #innodb_flush_log_at_trx_commit = 1
     #innodb_lock_wait_timeout = 50
 
     [mysqldump]
     quick
     max_allowed_packet = 16M
 
     [mysql]
     no-auto-rehash
     # Remove the next comment character if you are not familiar with SQL
     #safe-updates
 
     [isamchk]
     key_buffer = 8M
     sort_buffer_size = 8M
 
     [myisamchk]
     key_buffer = 8M
     sort_buffer_size = 8M
 
     [mysqlhotcopy]
     interactive-timeout


Сторонние мастера настройки MySQL

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

Мониторинг MySQL сервера

MySQL хранит статистику, которая помогает определить самые лучшие значения для использования. Кроме этого, имеются две удобные утилиты, которые можно использовать для чтения этой статистики и выводить в понятном формате: tuning-primer.sh and mysqltuner.pl.
Эти скрипты позволят мониторить ваш MySQL сервер, и после предоставят подсказку о параметрах, которые необходимо настроить на вашем сервере.

Оптимизация PHP и кэширование

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


; Limit the memory to 40M should be fine for barebones Wordpress
memory_limit = 48M
realpath_cache_ttl=300
realpath_cache_size=1M

Alternative PHP Cache

Установите PHP Cache, например, такой как, Alternative PHP Cache. PHP cache будет хранить скомпилированные PHP скрипты таким образом, что они будут заново использованы без компиляции и, соответственно, не создадут нагрузку:


# pecl install apc

Ниже мой сконфигурированный php.ini файл.
Мой php.ini

[APC]
extension=apc.so
apc.enabled=1
apc.shm_segments=1
 
;32M per WordPress install
apc.shm_size=128M
 
;Relative to the number of cached files (you may need to watch your stats for a day or two to find out a good number)
apc.num_files_hint=7000
 
;Relative to the size of WordPress
apc.user_entries_hint=4096
 
;The number of seconds a cache entry is allowed to idle in a slot before APC dumps the cache
apc.ttl=7200
apc.user_ttl=7200
apc.gc_ttl=3600
 
;Setting this to 0 will give you the best performance, as APC will
;not have to check the IO for changes. However, you must clear 
;the APC cache to recompile already cached files. If you are still
;developing, updating your site daily in WP-ADMIN, and running W3TC
;set this to 1
apc.stat=1
 
;This MUST be 0, WP can have errors otherwise!
apc.include_once_override=0
 
;Only set to 1 while debugging
apc.enable_cli=0
 
;Allow 2 seconds after a file is created before it is cached to prevent users from seeing half-written/weird pages
apc.file_update_protection=2
 
;Leave at 2M or lower. WordPress does't have any file sizes close to 2M
apc.max_file_size=2M
 
;Ignore files
apc.filters = "/var/www/apc.php"
 
apc.cache_by_default=1
apc.use_request_time=1
apc.slam_defense=0
apc.mmap_file_mask=/var/www/temp/apc.XXXXXX
apc.stat_ctime=0
apc.canonicalize=1
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.lazy_classes=0
apc.lazy_functions=0


Static Cache

Другая вещь, которая может быть хорошей идеей для блога на маленьком сервере — это поставить его перед статическим HTTP-cache, например, Varnish. Что может реально увеличить вашу масштабируемость. Конфигурация Varnish — это отдельная большая статья, требующая, отдельного топика.

Заключение


Я выложил в открытый доступ конфигурацию моего веб-сервера, чтобы доказать, что можно добиться высокой производительности даже от самого дешевого VPS контейнера с 512МБ RAM и 1Ghz CPU. Использую я Ubuntu 12.04 LTS, LAMP, Varnish,APC Cache для размещения 3-х веб-сайтов, сделанных на Wordpress (не мультисайтовых) с посещаемостью 10к в день. Давайте взглянем на результаты тестов от Blitz.io:



Как видите, 0,23% пользователей получают Connection Timeout, когда мой веб-сайт имеет 42,735,587 хитов в день (WOW), может можно еще что-то оптимизировать, но я получаю удовольствие от работы моего веб-сервера. Если ты устал от этого руководства или не хочешь делать руками, то можешь воспользоваться такими сервисами, как PuPHPet или Vagrant.
Поделиться публикацией
Ммм, длинные выходные!
Самое время просмотреть заказы на Фрилансим.
Мне повезёт!
Реклама
Комментарии 85
  • +48
    А почему не выкинули apache в пользу php-fpm?
    • +3
      Кстати nginx был бы гораздо лучшим решением, там хотя бы можно было бы использовать крутое кеширование, да и вообще там затюнить многое можно. после можно было бы принимать еще больше посетителей,
      • +1
        Дело в том, что сервер не имеет прямого подключения к глобальной сети, а выходит в нее через специальное сетевое оборудование. Я пробовал ngnix+php-fpm, но быть может моих знаний в настройке этой связки не хватило или может еще каких-либо нюансов я не учел, но у меня сложилась такая ситуация, что описанные мной настройки показали больший прирост производительности, нежели связка ngnix+php-fpm. Но я продолжаю анализировать причины такого поведения и как только их обнаружу, то непременно поделюсь ими.
        • +3
          Странно. Мне кажется связка nginx+php-fpm гораздо понятнее и удобнее в настройке, к тому же к этой связке такая куча мануалов, можно почти бездумно копипастить и будет работать отлично
          • +1
            Кстати, вместо php-fpm давно уже можно использовать uWSGI. По сути тот же php-fpm, но ещё позволит запускать Python/WSGI, Ruby/rack, Lua/WSAPI и другие приложения :)
            Бонусом к такому варианту идёт доступность из PHP функций для работы с кешем uWSGI, к инструментарию RPC, другим «рюшечкам», также можно назначить session.save_handler=uwsgi

            Ну и самое главное: слабым местом всегда остаётся само веб-приложение, каким бы ни был сервер…
            • 0
              Добавлю, что WordPress проявляет тормозность только когда он основательно набит контентом (вероятно, там есть как минимум линейная зависимость числа неких громоздких операций от количества постов и страниц), поэтому и тестирование нужно проводить при условии, что на сайте будет достаточно много контента. К тому же, наличие контента может поспособствовать тому, что слабым местом как бы внезапно станет не сервер, а интернет-подключение.
              • 0
                эта зависимость проявляется в запросах вида:
                SELECT * FROM table LIMIT 1000, 20
                
              • +1
                А что самое прикольное — uWSGI можно настроить на использование namespaces, чтобы свести к минимуму последствия взлома какого-то vhost.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Ой, а можно подробности о «фризится»? Сломал весь мозг от того, что он иногда подвисает. Как отлавливать?
              • НЛО прилетело и опубликовало эту надпись здесь
                • 0
                  monit давно написан (=
                  • +2
                    Форк не умирает после обработки запроса.
                    Один процесс может обработать несколько запросов, пока не достигнет лимита из переменной pm.max_requests.
                    Время исполнения скрипта в php ограничено настройками php, как и количество памяти, которое он может захавать.
                    При ликах памяти он просто жрет память.
                    Фризиться он может, если залезет в своп.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        Как одну из причин, замечал как «виснет» php при обращении к внешним ресурсам.
                        Через, curl, fopen и т.д.
                        Это можно отследить через strace.
                        Или у уже зависшего процесса посмотреть /proc//fd, там файлы типа socket с номером.
                        ls -of | grep <номер> покажет, какое подключение сейчас установлено.
                        Все не доходят руки написать статью на эту тему.
                        • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        При дефиците памяти может помочь установка pm в ondemand.
                  • +2
                    Есть риск что автор не автор.
                • 0
                  И почему не выкинули WP в пользу чего-то менее прожорливого по внутреннему строению? :)
                  • 0
                    Пример менее прожорливого можете привести? ВП удобен огромным количеством плагинов, можно совершенно не владеть php для вменяемой разработки сайтов на нем.
                    • 0
                      Вменяемой — не совсем чтобы. Быстрый в создании из кирпичиков — да. Но вот это кирпичестроение требует куда больше ресурсов, как ни крути. Тем более если плагины низкого качества (что не сразу заметно, благо даже дешевый дроплет на DO отлично взлетает и летит, пока не нагрузка не превысит что-то там), то лететь сайту недалеко.

                      Грубо: сайт у вас меняется редко. Значит, его можно закешировать и держать в виде html-страниц. Но, скажем, кеш можно сбрасывать по таймеру, можно от событий в отношении страницы, можно от вообще любого события на сайте. Как себя поведет тот плагин, что вы поставили как кешер — честно, не скажу точно, но эти три варианта дадут разный уровень нагрузки. А если кеш при этом сложить в БД, или сложить его в файлы на диске, или если сложить его в памяти (что тоже дает свои варианты) — то получим еще набор разных задержек.

                      Скажем, делаете так: настраиваете отдачу страниц сайта через nginx из файловой системы в ОЗУ (я рассуждаю, что сайт у вас не дикий по размеру), по 404 ошибке nginx дергает ваш второй веб-сервер (что угодно, хоть апач), а тот уже рендерит страницу и записывает ее на нужное место в docroot nginx-а, плюс отдает nginx-у эту же страницу в этот раз. Получается, что nginx шустро будет отдавать страницы, даже если апач у вас упадет. И, если страницы не нужно менять, вы просто выключаете апач+php+mysql, и наслаждаетесь тем, что сайт летает и память пуста. Но вот как вы будете сбрасывать кеш — это, видимо, можно сделать hook-ом внутри WP, отследить изменение страниц, и переписывать их в docroot nginx-а.

                      P.S. А менее прожорливый — возьмите ModX Evo, но это разные движки, да и любой другой так же.
                      • 0
                        Спасибо за ответ, modx конечно крут, но я больше люблю ВП :)
                        Кстати, кэширование на ВП легко выполняется с помощью плагинов ;)
                        Вменяемой, в данном контексте означало, что просто работает (как это уже второй вопрос).
                      • 0
                        Может быть, не надо разрабатывать сайты на том, в чем не смыслите? Иначе это мы так друг друга лечить начнем самостоятельно. Кому полостную операцию сделать, возьму не дорого!
                  • +5
                    После проделанных манипуляций вам необходимо обязательно перезагрузить веб-сервер Apache:

                    # service apache2 restart
                    

                    Не надо рестартить сервис там, где это не нужно.
                    Иногда достаточно сделать reload:
                    service apache2 reload
                    

                    • +6
                      Да, вы абсолютно правы! Почему в статье написал именно так, сейчас постараюсь объяснить. Был у меня один случай очень давно. Тогда настраивал apache еще под управление freebsd то ли 6.4, то ли 7.1. И долго не мог разобраться, почему измененный параметр в конфигурации веб-сервера не вступает в силу. Убил на решение проблемы порядка 5-и часов. После перезагрузил сервер и проблема решилась. Начал играться с опциями и обнаружил, что reload не перечитывает конфигурацию, а restart/stop-start выполняется успешно, причем, в логах тоже ничего не было подозрительного. С тех пор выработалась привычка, что когда что-то с нуля подымаю использую, исключительно, опцию restart, а когда в продуктивной среде необходимо что-то изменить в конфигурации на высоконагруженном проекте, то конечно же, использую reload и только reload.
                      • 0
                        apachectl для этих целей более универсальное решение.
                        • +1
                          С freebsd 6.4 много воды утекло, особенно в linux.
                          Но я вижу, вы в курсе насчет restart на хайлоаде :)
                      • +4
                        А что вы конкретно тестировали? Заглавную страницу веб-сервера, которая отображается по умолчанию? Судя по приведенной статистике, размер отданной страницы составил 20.69 / 28650 * 1024 ≈ 0.74 кб
                        • 0
                          Для примера, главная одного из моих сайтов генерирует следующие результаты
                          Скриншот
                          image
                          • +12
                            судя по Response Time 16-37 ms — все запросы обработал Varnish, и до апача с php дело не дошло ни разу.
                            • +1
                              В целом, реальные цифры… разве нет?
                          • +2
                            В последней табличке: 20 мегабайт и 28650 хитов. Это сколько отдаётся/принимается на один хит? Не слишком ли цифры далеки от реальных приложений?
                            Смотрю у этого blitz.io нету бесплатного плана, так бы свой не потимизированый ВП для интересу померял.
                            • +2
                              Если установлен слишком маленький кэш таблицы, то mysql будет блевать на вас, вы же не хотите этого.

                              Блевать? Буэээ
                              • +14
                                nginx + php-fpm намного меньше апача будут есть
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • +3
                                      в статье не написано, что нельзя заменять тяжеловесные приложения более оптимальными.
                                      п.с. как же надо ненавидеть nginx, чтоб слить мне за этот камент карму в — ;)
                                      хабр такой хабр.
                                      • 0
                                        > п.с. как же надо ненавидеть nginx, чтоб слить мне за этот камент карму в — ;)

                                        oh wait, зря я написал коммент ниже :(
                                      • +1
                                        <удалено во имя справедливости>
                                        
                                    • +25
                                      Не запускайте X-сервер
                                      You made my day!
                                      PHP не очень интенсивно использует память, поэтому я не думаю, что нужно сильно беспокоится о потреблении памяти этим процессов
                                      Twice!

                                      Советы:
                                      * apache+mod_php -> nginx+php-fpm
                                      Иначе это очень странная борьба за экономию памяти и оптимизацию.
                                      * Главное, чтобы ваш сайт не валился с ошибкой, что php не хватает оперативки.
                                      Ибо 48 метров маловато.
                                      * apc.shm_size=128M в вашем случае это дофига.
                                      Там же в комменте строкой выше указано: ";32M per WordPress install"
                                      * max_connections в mysql — это очень важный параметр, т.к. mysql выделяет кучу памяти на каждое соединение.
                                      С одной стороны, его нельзя делать маленьким — сайт будет выдавать ошибку.
                                      С другой стороны, в целях экономии оперативки его нельзя делать слишком большим.
                                      * Грубо говоря, в key_buffer лежат индексы myisam таблиц.
                                      Поэтому в идеале он должен быть не меньше размера всех индексов myisam таблиц.
                                      Иначе база будет упираться в IO.
                                      * Поставьте самый простой кеширующий dns сервер (dnsmasq, nscd).
                                      Сайт может делать dns запросы на каждый чих.
                                      Делать запрос на dns хостера куда дольше. чем брать из кеша.
                                      Ну и глюканет dns у хостера — у вас все встанет (а такое изредка бывает).

                                      По mysql прочитайте краткое описание важных параметров habrahabr.ru/post/66684/
                                      • +4
                                        Забыл сказать про кеширование на уровне веб сервера.
                                        Если у вас не особо динамичный сайт, nginx + fastcgi_cache разгонят его до скорости отдачи простой статики.
                                        • 0
                                          Да с этого, по сути, надо было начинать, в свете перехода на майисам
                                      • 0
                                        А что за хостер? И какие диски на вашем ВПС?
                                        • +4
                                          Zend Opcache вошел в код Php 5.5 который на тестах лучшее APC

                                        • +13
                                          А, это синтетические тесты. Я то уж подумал что у вас реально 40M хитов в день и все это как то живет на слабенькой VPS, а владелец сайта настолько жмется =)

                                          Ради интереса проделывал похожие вещи на еще более слабой VPS, но там я сразу отказался от Apache поставив вместо него nginx и скомпилировав на той же машине php 5.7
                                          По сути подобные тесты будут показывать довольно высокую производительность когда все запросы падают на одну страничку и совершенно другая картина будет с реальными пользователями. В случае с плагинами типа W3 cache или надстройками типа Varnish то настройки php и mysql вообще на тест влиять не будут т.к. сервер будет тупо отдавать статичную страничку.
                                          • +9
                                            Советуете переделать InnoDB в MyIsam???!!!
                                            • +9
                                              Ага, скриптом их всех. Ну, там foreign key да триггеры пропали, пофиг.
                                              • 0
                                                А что с триггерами в myisam?
                                                Я использую триггеры в myisam.
                                                В некоторых случаях myisam работает значительно быстрее, чем InnoDB.
                                                Тут я подумал, что автор знает, что MyISAM использует меньше памяти.
                                                • 0
                                                  Можно было бы пойти дальше: заюзать MEMORY схему, если бы не ее урезанность. Уж начто я привык ко всему, но буквально недавно столкнулся с xenforo — и что бы вы думали, тоже не используют внешних ключей, не используют транзакции. А знаете, почему? Они на форуме писали — чтобы не было проблем с бекапированием.
                                            • +12
                                              Как только не изощряются люди, лишь бы nginx + php-fpm не использовать. :)
                                              • +2
                                                Over 400 RPS на WordPress. Шикарно. На каком контенте и запросах? Допустим, страница статьи с деревом комментариев на 300 штук различной вложенности, которые периодически пополняются. Тоже > 400 rps держит? Было бы прекрасно, но верится с трудом.
                                                • +4
                                                  Да там slowest request 37ms, весь тест на 100% в кеш попадал, никакого wp/apache/mysql.
                                                  • +1
                                                    О том и речь. Самый простой способ раскачать wordpress — отключить wp/apache/mysql
                                                  • 0
                                                    А в чем сложность дерева комментариев на 300 запросов? 1 запрос к БД с выборкой по индексу.
                                                    PS. например алгоритм nested sets
                                                • +1
                                                  еще можно в my.cnf

                                                  thread_cache = 5

                                                  # Query Cache Configuration
                                                  query_cache_limit = 4M
                                                  query_cache_min_res_unit = 8
                                                  query_cache_size = 8M
                                                  query_cache_type = 1

                                                  будет кешировать запросы и держать несколько тредов префоркнутыми
                                                  • +2
                                                    что-то тема, как говорится, не раскрыта, давайте уже посмотрим в действительности на нагруженный сайт и поймем, почему он действительно работает быстро при такой количестве посещений и конфигурации
                                                    • 0
                                                      Да обычно все сводится к банальному кешированию.
                                                      redis, memcache, proxy_cache, fastcgi_cache.
                                                      • 0
                                                        На 512 мб? Допускаю, но не верю.
                                                        • +1
                                                          На 512 — гуляй не хочу
                                                          вот на 128 все гораздо веселее…
                                                          • 0
                                                            Имею десятка полтора слабеньких VPS под 256 МБ ОЗУ. Для большинства клиентов хватает с головой. Но вот как поместиться на 128 МБ представляю с трудом. Там ведь никакого резерва не будет. Разве что заранее решить, что ничего кроме статики :)
                                                            • +1
                                                              Раньше vdsplanet по тарифу луна (сейчас у них минимум 256) выдавали 128 оперативки.
                                                              Разумеется никакого резерва не было, но хотелось покрасноглазить и запустить.
                                                              Сервером понятное дело nginx, для mysql выставил все размеры по 4 метра — на дефолтных настройках ее убивало при старте. PHP вместо fpm использовал php-cgi -b и скрипт в кроне проверки наличия процесса.
                                                              Собственно все — в таком состоянии легкие динамические запросы отрабатывались, даже хватало на второй запуск php по крону, правда во время выполнения крона по ssh зайти было нельзя :)
                                                              Еще пришлось очень весело генерить локали — sshfs + chroot
                                                          • 0
                                                            Не, не при такой конфигурации естественно.
                                                            На действительно нагруженных сайтах все ок с оперативкой, но сама по себе куча оперативки скорости не прибавляет.
                                                            Имхо, не бывает нагруженных сайтов (> 1кк уников в сутки) на серверах с 0,5 ГБ оперативки.
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                              • 0
                                                                Да, но я не столько про БД, сколько про сервера логики, где выполняется код.
                                                                Грубо говоря, php скриптов на диске может лежать на 100-200(-500?) МБ.
                                                                Естественно, они быстро окажутся в кеше файловой системы.
                                                                Ну и оперативка тратится на код скриптов во время выполнения.
                                                                Ну а дальше все.
                                                                Если сервер логики не упирался в оперативку ранее, то увеличение, скажем с 16 до 32 ГБ не даст какого-то прироста.
                                                                На серверах БД, конечно, больше оперативки позволит запихать в неё больше данных.
                                                                Про уников я писал 1кк — это 1 млн, это несколько синтетическая величина с точки зрения нагрузки, согласен.
                                                      • 0
                                                        безусловно интересные советы, спасибо.

                                                        Очень хотелось бы посмотреть как соб-но изменилась производительность «до» и «после». В идеале — при изменении каждого параметра каждого сервиса. Еще хорошо бы посмотреть как меняется load внутри системы. У вас же синтетические тесты, легко их прогнать.

                                                        Если этого нет, то неясно что мы теряем и что получаем. А интуиция при подкручивание разных опций может и обмануть.
                                                        • +16
                                                          А не синтетический тест провести довольно просто — давайте ссылку на Ваш сайт здесь и через часик, если все еще будете иметь доступ к нему, выкладывайте уже картинку красивую.
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                            • 0
                                                              Казалось бы при чем тут wordpress? )
                                                              Ни слова про плагин w3tc, который при правильной настройке позволяет отдавать статику напрямую через nginx. В зависимости от типа контента этот кеш может жить очень долго, единственный неприятный момент — перестанут работать счетчики просмотров постов (для некоторых актуально), лечится использованием JSON счетчиков.
                                                              • +2
                                                                Тепличные тесты сферического сайта в вакууме.
                                                                Blitz.io не покажет реального положения вещей, танк более-менее покажет реальную нагрузку на тестовом стенде.
                                                                У реального сайта с такой посещаемостью будут проблемы совсем другого уровня, ибо будет накручена куча модулей и корявого кода, в котором никто не шарит ибо сменилось 10 поколений разрабов. С этими проблемами в первую очередь и придется столкнуться.
                                                                Где кеширование nginx'ом, memcache, XtraDB?

                                                                С такой посещалкой экономия на сервере — глупость. Не вводите пользователей в заблуждение, доверяйте профессионалам работу с HL.
                                                                Картинка по запросу «Выдуманный Мир»
                                                                image
                                                                • 0
                                                                  Хм, а ради интереса можете Яндекс Танком шарахнуть по вашему ВП? У меня php-fpm + nginx держал 25 одновременных юзверей, второй тариф на ДО.
                                                                  • 0
                                                                    Оптимизация для любого веб-сервера начинается с использования nginx + php5-fpm + opcache и настройке кеширования на nginx там где только можно.
                                                                    Также рекомендую больше внимания всё-таки уделить отключению лишнего в php5-fpm.
                                                                    А тесты Вам стоит проводить, направив нагрузку на самые тяжелые в плане вычислений места.
                                                                    Ну и конечно же, отключение логов при малейшем DDoS или попытках взлома Вам обойдутся дорого.

                                                                    За статью спасибо, но если уж оптимизировать, то по максимуму.
                                                                    • +1
                                                                      Какой смысл такого теста? До WordPress даже ничего не дошло, всё тупо из кэша отдалось. Можно и просто странички на html положить и удивляться скорости отдачи сервера за 5$.
                                                                      • 0
                                                                        А почему в списке включенных модулей нет mod_php?
                                                                        • 0
                                                                          Тест Varnish'а получился, не?
                                                                          Переходя на MyISAM помните, что выдергивание сервера из розетки с большой вероятностью даст ручное восстановление данных с потерей некоторой части оных — MyISAM не контролирует свою целостность в отличии от InnoDB. Ну транзакционная целостность… не нужна?
                                                                          В Apache можете еще обработку .htaccess отключить, а вообще nginx.
                                                                          • 0
                                                                            может устроим такой конкурс?
                                                                            • +12
                                                                              Пожалуйста, оставляйте ссылку на оригинал
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                • 0
                                                                                  Я думал, что будет рассказано о mod_pagespeed, есть опыт использования mod_pagespeed?
                                                                                  • 0
                                                                                    При разработке софта может быть полезен. А так, только увеличивает время генерации страницы. На High-load проектах увеличивает очень сильно.
                                                                                  • 0
                                                                                    Хотелось бы еще увидеть сайты, которые лежат на серваке. Так как разница между корпоративной визиткой и порталом, как Вы понимаете…

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