Оптимізуйте apache для перегляду 10K + wordpress в день на 2 ГБ оперативної пам’яті E6500 CPU


10

У мене є виділений сервер з apache / php в ubuntu, який обслуговує мій блог Wordpress з приблизно 10 К + перегляди сторінок на день. У мене встановлено штекер 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 для одного сервера низького та середнього діапазону або VPS. Я класифікую середній діапазон як одноядерний, що має близько 1 Г пам'яті і досить швидкі диски.

У вашій коробці ця послуга зможе обслуговувати понад 10 тис. Переглядів сторінок на годину

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

  • Linux - або Debian Lenny, або Ubuntu
  • Nginx - Налаштовується як кеш-файл статичного зворотного проксі
  • Apache - Apache буде обробляти PHP, завантажений Nginx на альтернативному порті
  • MySql - вимагає WP, переконайтеся, що ви працюєте з останньою стабільною версією
  • PHP - остання стабільна версія 5,2 або 5,3 відділення

PHP кеш

  • APC - Налаштуйте його за допомогою mmap-пам’яті та розміром shm принаймні 128М

WordPress Plugin стек продуктивності

  • Інтегратор кешу проксі-сервера Nginx
  • W3 Total Cache - Встановлення кешу сторінки на розширений диск, мінімізація на диску та об'єкт і db в APC.
  • Self Hosted CDN - Створіть 4 псевдоніми імен, які вказують на домен на сервері, створені просто для подання статичного файлу

За допомогою 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

На Debian ви можете використовувати сховища для установки, але вони містять лише версію 0.6.33. Щоб встановити більш пізню версію, вам потрібно додати пакети із заднім числом

$ 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, пов’язаним з файлом у доступній для сайтів каталозі.

$ 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;
        }

        }

CDN конф. Конф

Для власної конфіденційної конфіденційності CDN вам потрібно лише налаштувати її для обслуговування статичних файлів без пропуску проксі

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 ця установка теоретично може обслуговувати 1833,56 запитів в секунду

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

alt текст


Ви згадуєте про те, що nginx обробляє статичні файли та apache обробляє php-файли, але у блоці статичних файлів у вас є "proxy_pass wordpressapache ;". Чи це не означає, що апаш обробляє статичні файли?
srchulo

0

Це схоже на стандартну конфігурацію Apache, хоча, здається, деякі з них були зняті завдяки тому, що вони виглядають як HTML.

Вам потрібно дослідити, що відбувається, коли ваш сервер реагує повільно. Ви не кажете, що специфікація вашого сервера, але ви згадуєте про його виділення, і 10 к / день слід легко обробляти.

  • Що показує топ?
  • Де вузьке місце? Процесор, пам'ять, введення / виведення Зачекайте?
  • Скільки запущених процесів Apache?
  • Скільки з'єднань показано в netstat?

Здогадуючись, CPU - це, мабуть, вузьке місце, викликане PHP. Використання APC та плагін кешування WP - хороші методи для полегшення цього, що ви вже зробили. Ви також можете спробувати модель процесу MPM Apache замість "Prefork". Переконайтеся, що у вас достатньо пам'яті, виділеної APC, щоб він міг кешувати ваші скрипти PHP, а не "пропускати".

Це також може бути MySQL - дивіться, чи це вивішування процесора чи диска.

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

Використовуйте такий інструмент, як "облога" або "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, це один із ознак цієї ситуації.

Можливо також, що ви ложкою годуєте деяких мобільних клієнтів (або інших клієнтів на повільних з'єднаннях) "великими" файлами, тим самим споживаючи всі наявні слоти для апашей. Можливо, у вас занадто мало MaxClients. Перевірка статусу сервера підкаже, що кожен із цих клієнтів робить у той час. Одне рішення для цієї ситуації - збільшити MaxClients (але це також може перетворитись на ситуацію вище). Кращим рішенням для цього є встановлення HTTP-акселератора перед apache (одна вільна опція є perlbal.) Якщо ваш командний рядок є нормальним швидкість при перезапуску apache, ось один із ознак цієї ситуації.


0

Використання mod_status - це спосіб побачити, що відбувається всередині декількох екземплярів Apache, але зауважте, що це дійсно погіршить продуктивність. Здається, це споживає пам'ять, і в одному випадку я не зміг поставити діагноз, чи це було причиною блокування однопроцесових процесів у режимі зворотного проксі-сервера, де безпосередньо нічого не подавали. Вони, звичайно, повідомляються про те, що "завантажувати сторінку потрібно вічно". Вони навіть не розуміють різниці між "почекати було б ще 10 секунд" і "це ніколи не закінчиться", оскільки вони зазвичай натискають "Стоп" у своєму браузері через кілька (<10) секунд.

Також перевірте, чи ви налаштовуєте правильне місце (легко зрозуміти за допомогою mod_status, оскільки ви бачите кількість примірників / процесів). Конфігурація запасів, щонайменше, під ubuntu має розділи ifdef'ed в режимі MPM, і це легко редагувати режим робочого, коли ви запускаєте префорк (як це підказує звичайна мудрість з нечіткого відчуття, що PHP не є безпечним потоком).

О, і найбільше: запустіть на вершині як root і стежте за змішаними ресурсами. Пам'ять, диск, процесор - ви побачите.

Ще одне: Ідея вимкнути mod_deflate може бути хорошою, хоча ваше налаштування не схильне до помилки невірної інформації про довжину вмісту, що змушує браузер чекати даних "назавжди", даючи вам повідомлення про "мертвий повільний" до "не відповідає".

BTW: 10 Кб, що доставляються на день, плюс мультимедійні файли на цій машині мають бути проблемою лише в тому випадку, якщо вони відвідують одну годину.


0

Деякі поради, особливо якщо ви розміщуєте багато медіафайлів:

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