Оптимизация Apache для просмотра 10K + WordPress в день на 2 ГБ оперативной памяти E6500 CPU


10

У меня есть выделенный сервер с apache / php на Ubuntu, который обслуживает мой блог Wordpress с 10K + просмотрами страниц в день. У меня установлен плагин W3TC с APC.

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

Вот мой конфиг, что я делаю не так?

ServerRoot "/etc/apache2"
LockFile /var/lock/apache2/accept.lock
PidFile ${APACHE_PID_FILE}
TimeOut 40
KeepAlive on
MaxKeepAliveRequests 200
KeepAliveTimeout 2
<IfModule mpm_prefork_module>
  StartServers 5
  MinSpareServers 5
  MaxSpareServers 8
  ServerLimit        80
  MaxClients         80
  MaxRequestsPerChild 1000
</IfModule>
<IfModule mpm_worker_module>
  StartServers       3
  MinSpareServers    3
  MaxSpareServers    3
  ServerLimit        80
  MaxClients         80
  MaxRequestsPerChild  1000
</IfModule>
<IfModule mpm_event_module>
  StartServers       3
  MinSpareServers    3
  MaxSpareServers    3
  ServerLimit        80
  MaxClients         80
  MaxRequestsPerChild  1000
</IfModule>
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
AccessFileName .htaccess
<Files ~ "^\.ht">
  Order allow,deny
  Deny from all
  Satisfy all
</Files>
DefaultType text/plain
HostnameLookups Off
ErrorLog /var/log/apache2/error.log
LogLevel error
Include /etc/apache2/mods-enabled/*.load
Include /etc/apache2/mods-enabled/*.conf
Include /etc/apache2/httpd.conf
Include /etc/apache2/ports.conf
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog /var/log/apache2/other_vhosts_access.log vhost_combined
Include /etc/apache2/conf.d/
Include /etc/apache2/sites-enabled/

Ответы:


23

Моя производительность WordPress и стек кэширования

Это отличный стек производительности WordPress для одиночного или среднего сервера с низким и средним диапазоном. Я классифицирую средний диапазон как одноядерный с около 1 ГБ памяти и довольно быстрыми дисками.

На вашем ящике это может обслуживать более 10 тысяч просмотров страниц в час.

Серверный стек

  • Linux - либо Debian Lenny, либо Ubuntu
  • Nginx - настроен как статический кеш обратного прокси
  • Apache - Apache будет обрабатывать PHP, выгруженный Nginx через альтернативный порт
  • MySql - требуется WP, убедитесь, что вы используете последнюю стабильную версию
  • PHP - последняя стабильная версия ветки 5.2 или 5.3

PHP Cache

  • APC - настройте его с памятью mmap и размером shm не менее 128M

Стек плагинов для WordPress Performance

  • Nginx прокси-кеш интегратор
  • W3 Total Cache - Усовершенствуйте кэш страницы для диска, уменьшите до диска, а объект и дБ до APC.
  • Self Hosted CDN - создайте 4 псевдонима cname, которые указывают на домен на сервере, настроенном только для обслуживания статического файла

В W3 Total Cache мы используем диск для кэширования страниц и минимизации, потому что Nginx будет очень быстро обслуживать наши статические файлы.

Как настроить Nginx для обслуживания статических файлов и передачи PHP в Apache

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

По умолчанию Apache прослушивает запросы через порт 80, который является веб-портом по умолчанию. Сначала мы собираемся внести изменения в наши файлы Apache conf и виртуальные хосты, чтобы прослушивать порт 8080.

Apache Config

httpd.conf

выключить KeepAlive

ports.conf

NameVirtualHost *:8080
Listen 8080

Виртуальный хост на сайте

<VirtualHost 127.0.0.1:8080>
     ServerAdmin info@yoursite.com
     ServerName yoursite.com
     ServerAlias www.yoursite.com
     DocumentRoot /srv/www/yoursite.com/public_html/
     ErrorLog /srv/www/yoursite.com/logs/error.log
     CustomLog /srv/www/yoursite.com/logs/access.log combined
</VirtualHost>

Вам также следует установить mod_rpaf, чтобы ваши журналы содержали реальные ip-адреса ваших посетителей. Если нет, ваши журналы будут иметь 127.0.0.1 в качестве исходного IP-адреса.

Nginx Config

В Debian вы можете использовать репозитории для установки, но они содержат только версию 0.6.33. Чтобы установить более позднюю версию, вы должны добавить пакеты lenny backports

$ nano /etc/apt/sources.list

Добавить эту строку в файл deb http://www.backports.org/debian lenny-backports main

$ nano /etc/apt/preferences

Добавьте следующее в файл:

Package: nginx
Pin: release a=lenny-backports 
Pin-Priority: 999

Выполните следующие команды, чтобы импортировать ключ с backports.org для проверки пакетов и обновления базы данных пакетов вашей системы:

$ wget -O - http://backports.org/debian/archive.key | apt-key add -
$ apt-get update

Теперь установите с помощью apt-get

apt-get install nginx

Это намного проще, чем компиляция из исходного кода.

Конфиг Nginx и файлы конфигурации сервера

nginx.conf

user www-data;
worker_processes  4;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    access_log  /var/log/nginx/access.log;
    client_body_temp_path /var/lib/nginx/body 1 2;
    gzip_buffers 32 8k;
    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;

    gzip  on;

  gzip_comp_level   6;
  gzip_http_version 1.0;
  gzip_min_length   0;
  gzip_types        text/html text/css image/x-icon
        application/x-javascript application/javascript text/javascript application/atom+xml application/xml ;



    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Теперь вам нужно настроить виртуальный хостинг Nginx. Мне нравится использовать метод с поддержкой сайтов, где каждый символ v host связан с файлом в каталоге сайтов.

$ mkdir /etc/nginx/sites-available  
$ mkdir /etc/nginx/sites-enabled
$ touch /etc/nginx/sites-available/yourservername.conf
$ touch /etc/nginx/sites-available/default.conf
$ ln -s  /etc/nginx/sites-available /etc/nginx/sites-enabled
$ nano /etc/nginx/sites-enabled/default.conf

default.conf

Примечание:

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

proxy_cache_path  /var/lib/nginx/cache  levels=1:2   keys_zone=staticfilecache:180m  max_size=500m;
proxy_temp_path /var/lib/nginx/proxy;
proxy_connect_timeout 30;
proxy_read_timeout 120;
proxy_send_timeout 120;

#IMPORTANT - this sets the basic cache key that's used in the static file cache.
proxy_cache_key "$scheme://$host$request_uri";

upstream wordpressapache {
        #The upstream apache server. You can have many of these and weight them accordingly,
        #allowing nginx to function as a caching load balancer 
        server 127.0.0.1:8080 weight=1 fail_timeout=120s;
}

За каждый сайт WordPress (для нескольких сайтов вам понадобится только один vhost)

server {
        #Only cache 200 responses, and for a default of 20 minutes.
        proxy_cache_valid 200 20m;

        #Listen to your public IP
        listen 80;

        #Probably not needed, as the proxy will pass back the host in "proxy_set_header"
        server_name www.yoursite.com yoursite.com;
        access_log /var/log/nginx/yoursite.proxied.log;  

        # "combined" matches apache's concept of "combined". Neat.
        access_log  /var/log/apache2/nginx-access.log combined;
        # Set the real IP.
        proxy_set_header X-Real-IP  $remote_addr;

        # Set the hostname
        proxy_set_header Host $host;

        #Set the forwarded-for header.
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        location / {
                        # If logged in, don't cache.
                        if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
                                set $do_not_cache 1;
                        }
                        proxy_cache_key "$scheme://$host$request_uri $do_not_cache";
                        proxy_cache staticfilecache;
                        proxy_pass http://wordpressapache;
        }

        location ~* wp\-.*\.php|wp\-admin {
                        # Don't static file cache admin-looking things.
                        proxy_pass http://wordpressapache;
        }

        location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
                        # Cache static-looking files for 120 minutes, setting a 10 day expiry time in the HTTP header,
                        # whether logged in or not (may be too heavy-handed).
                        proxy_cache_valid 200 120m;
                        expires 864000;
                        proxy_pass http://wordpressapache;
                        proxy_cache staticfilecache;
        }

        location ~* \/[^\/]+\/(feed|\.xml)\/? {
 # Cache RSS looking feeds for 45 minutes unless logged in.
                        if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
                                set $do_not_cache 1;
                        }
                        proxy_cache_key "$scheme://$host$request_uri $do_not_cache";
                        proxy_cache_valid 200 45m;
                        proxy_cache staticfilecache;
                        proxy_pass http://wordpressapache;
        }

        location = /50x.html {
                root   /var/www/nginx-default;
        }

        # No access to .htaccess files.
        location ~ /\.ht {
                deny  all;
        }

        }

Self Hosted CDN conf

Для вашей собственной CDN conf вам нужно только настроить ее для обслуживания статических файлов без пропуска прокси

server {

        proxy_cache_valid 200 20m;
        listen 80;
        server_name yourcdndomain.com;
        access_log   /srv/www/yourcdndomain.com/logs/access.log;
        root   /srv/www/yourcdndomain.com/public_html/;

 proxy_set_header X-Real-IP  $remote_addr;

      location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
                                # Cache static-looking files for 120 minutes, setting a 10 day expiry time in the HTTP header,
                                # whether logged in or not (may be too heavy-handed).

                                proxy_cache_valid 200 120m;
                        expires 7776000;
                        proxy_cache staticfilecache;
                }

location = /50x.html {
                root   /var/www/nginx-default;
        }

 # No access to .htaccess files.
        location ~ /\.ht {
          deny  all;
        }

    }

Теперь запустите серверы

$ /etc/init.d/apache2 restart  
$/etc/init.d/nginx start

Результаты тестов

На Apache Bench эта установка теоретически может обслуживать 1833,56 запросов в секунду

$ ab -n 1000 -c 20 http://yoursite.com/

альтернативный текст


Вы упоминаете, что nginx обрабатывает статические файлы и apache обрабатывает php-файлы, но в блоке статических файлов у вас есть «proxy_pass wordpressapache ;». Разве это не означает, что apache обрабатывает статические файлы?
srchulo

0

Это похоже на стандартную конфигурацию Apache, хотя кажется, что некоторые из них были удалены из-за того, что они выглядят как HTML.

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

  • Что показывает топ?
  • Где узкое место? Процессор, память, ввод / вывод подождать?
  • Сколько процессов Apache запущено?
  • Сколько соединений показано в netstat?

Догадываясь, процессор, вероятно, является узким местом, вызванным PHP. Использование APC и плагина кэширования WP - хороший способ облегчить это, что вы уже сделали. Вы также можете попробовать модель процесса Apache «MPM» вместо «Prefork». Убедитесь, что у APC достаточно памяти, чтобы он мог кэшировать ваши PHP-скрипты, а не «пропустить».

Это также может быть MySQL - посмотрите, если это перегружает процессор или диск.

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

Используйте такой инструмент, как 'siege' или 'ab', чтобы сравнить ваш сервер и выяснить, в какой момент ваш сервер замедляется.

Вот некоторые из моих закладок от настройки производительности веб-сервера: http://articles.slicehost.com/2010/5/19/configuring-the-apache-mpm-on-ubuntu

http://www.thebuzzmedia.com/increase-wordpress-performance-on-apache-with-worker-mpm-php-and-mod_fcgid/

http://www.devside.net/articles/apache-performance-tuning

http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/

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


0

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

Вы можете поменяться. Вы проверяли vmstat, пока это происходит? 2 ГБ ОЗУ для 80 MaxClients составляет всего 25 МБ для каждого (при условии, что устройство больше ничего не делает). Ваши MaxClients могут быть слишком высокими. Решение для этого очевидно: добавьте больше оперативной памяти или уменьшите MaxClients. Если командная строка медленно отвечает при перезапуске apache, это является одним из признаков этой ситуации.

Также возможно, что вы ложно кормите некоторых мобильных клиентов (или других клиентов при медленных соединениях) «большими» файлами, тем самым занимая все ваши доступные слоты apache. Может быть, у вас слишком мало MaxClients. Проверка состояния сервера покажет вам, что каждый из этих клиентов делает в то время. Одним из решений в этой ситуации является увеличение MaxClients (но это также может привести к описанной выше ситуации). Лучшее решение для этого - установить HTTP-акселератор перед apache (один бесплатный параметр perlbal.) Если ваша командная строка нормальная Скорость при перезапуске Apache, это один из признаков этой ситуации.


0

Использование mod_status - это способ увидеть, что происходит внутри нескольких экземпляров Apache, но учтите, что это действительно ухудшит производительность. Кажется, что он съел память, и в одном случае я не смог диагностировать, было ли это причиной одиночных блокировок процессов в настройке только с обратным прокси-сервером, где ничего не обслуживалось напрямую. Они, конечно, сообщаются пользователями как «загрузка страницы занимает вечность». Они даже не понимают разницы между «ожиданием было бы еще 10 секунд» и «оно никогда не закончится», поскольку они обычно нажимают «Стоп» в своем браузере через несколько (<10) секунд.

Также проверьте, правильно ли вы конфигурируете место (это легко увидеть с помощью mod_status, поскольку вы видите количество экземпляров / процессов). Стандартный конфиг по крайней мере в Ubuntu имеет разделы ifdef для режима MPM, и рабочий режим легко редактировать, когда вы запускаете prefork (как это принято считать, исходя из нечеткого ощущения, что PHP не является поточно-ориентированным).

Да, и самое главное: бегите поверх root и следите за максимальными ресурсами. Память, диск, процессор - увидишь.

Еще одно: идея деактивации mod_deflate может быть полезной, хотя ваши настройки не склонны к ошибке неверной информации Content-Length, заставляющей браузер ждать данные «вечно», давая вам сообщения о «очень медленном» и «не отвечающем».

КСТАТИ: 10 000 страниц в день плюс медиа-файлы на этой машине должны быть проблемой, только если они все приходят в течение одного часа.


0

Несколько советов, особенно если вы размещаете много медиа-файлов:

  • Переместите ваши носители в выделенный экземпляр Apache (или лучше: nginx). Никакого PHP, никаких модулей, только пустой http-сервер, который доставит медиа как можно быстрее.
  • Кеш, кеш, кеш! Используйте супер кеш плагин на WordPress. Это очень помогает.
  • Проверьте вашу конфигурацию apache на заголовках. Убедитесь, что изображения и другие «стабильные» носители имеют время истечения, установленное на удаленную дату, и что ваш apache возвращает код HTTP 304 по запросу клиентов
  • Включить mod_deflate. Это может снизить производительность клиентов будет быстрее обслуживаться.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.