Zoptymalizuj apache pod kątem 10 000 wyświetleń Wordpress na 2 GB pamięci RAM E6500 CPU


10

Mam dedykowany serwer z apache / php na ubuntu, obsługujący mój blog Wordpress z ponad 10 000 odsłon dziennie. Mam wtyczkę W3TC zainstalowaną z APC.

Ale co jakiś czas serwer przestaje odpowiadać lub przestaje działać powoli i muszę ponownie uruchomić apache, aby go odzyskać.

Oto moja konfiguracja, co robię źle?

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/

Odpowiedzi:


23

Moja wydajność WordPress i stos buforowania

To świetny stos wydajności WordPress dla pojedynczego serwera lub VPS niskiego do średniego zasięgu. Klasyfikuję średni zakres jako pojedynczy rdzeń z około 1G pamięci i dość szybkimi dyskami.

Na twoim urządzeniu byłoby to w stanie obsłużyć ponad 10 000 odsłon na godzinę

Stos serwerów

  • Linux - Debian Lenny lub Ubuntu
  • Nginx - Skonfigurowany jako pamięć podręczna plików statycznych z odwrotnym proxy
  • Apache - Apache będzie obsługiwał PHP odciążone przez Nginx na alternatywnym porcie
  • MySql - wymagany przez WP, upewnij się, że korzystasz z najnowszej stabilnej wersji
  • PHP - Najnowsza stabilna wersja oddziału 5.2 lub 5.3

Pamięć podręczna PHP

  • APC - Skonfiguruj go z pamięcią mmap i rozmiarem shm co najmniej 128M

Stos wtyczek wydajności WordPress

Dzięki W3 Total Cache używamy dysku do buforowania stron i minimalizacji, ponieważ Nginx będzie bardzo szybko obsługiwał nasze pliki statyczne.

Jak skonfigurować Nginx do obsługi plików statycznych i przekazywania PHP do Apache

Problem z używaniem samego Apache polega na tym, że otwiera połączenie i uderza php przy każdym żądaniu, nawet dla plików statycznych. To marnuje połączenia, ponieważ Apache utrzymuje je otwarte, a gdy masz duży ruch, Twoje połączenia zostaną zablokowane, nawet jeśli nie będą używane.

Domyślnie Apache nasłuchuje żądań na porcie 80, który jest domyślnym portem WWW. Najpierw wprowadzimy zmiany w naszych plikach Apache i wirtualnych hostach, aby nasłuchiwać na porcie 8080.

Konfiguracja Apache

httpd.conf

wyłącz KeepAlive

ports.conf

NameVirtualHost *:8080
Listen 8080

Wirtualny host na witrynę

<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>

Powinieneś także zainstalować mod_rpaf, aby twoje logi zawierały prawdziwe adresy IP twoich gości. Jeśli nie, twoje logi będą miały początkowy adres IP 127.0.0.1.

Konfiguracja Nginx

Na Debianie można użyć repozytoriów do zainstalowania, ale zawierają one tylko wersję 0.6.33. Aby zainstalować późniejszą wersję, musisz dodać pakiety lenny backports

$ nano /etc/apt/sources.list

Dodaj ten wiersz do pliku deb http://www.backports.org/debian lenny-backports main

$ nano /etc/apt/preferences

Dodaj do pliku:

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

Wydaj następujące polecenia, aby zaimportować klucz z backports.org, aby zweryfikować pakiety i zaktualizować bazę danych pakietów systemowych:

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

Teraz zainstaluj za pomocą apt-get

apt-get install nginx

Jest to o wiele łatwiejsze niż kompilacja ze źródła.

Konfiguracja Nginx conf i plików serwera

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/*;
}

Teraz musisz skonfigurować wirtualny hosting Nginx. Lubię używać metody obsługującej witryny z każdym v hostem połączonym z plikiem w katalogu witryn.

$ 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

Uwaga:

Ustawienia statycznej pamięci podręcznej w poniższych plikach będą działać tylko wtedy, gdy włączona jest wtyczka integratora pamięci podręcznej proxy 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;
}

Dla jednej witryny WordPress (w przypadku wielu witryn potrzebujesz tylko jednego vhosta)

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

        }

Konf. CDN na własnym serwerze

W przypadku samo-hostowanej sieci CDN wystarczy skonfigurować ją do obsługi plików statycznych bez przepustki proxy

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

    }

Teraz uruchom serwery

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

Wyniki testu

Na Apache Bench ta konfiguracja teoretycznie może obsłużyć 1833.56 żądań na sekundę

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

alternatywny tekst


Wspomniałeś, że nginx obsługuje pliki statyczne, a apache obsługuje pliki php, ale w bloku plików statycznych masz „proxy_pass wordpressapache ;”. Czy to nie znaczy, że apache obsługuje pliki statyczne?
srchulo

0

Wygląda to na standardową konfigurację Apache, choć wydaje się, że część została usunięta, ponieważ wygląda jak HTML.

Musisz zbadać, co się dzieje, gdy Twój serwer reaguje powoli. Nie podajesz specyfikacji swojego serwera, ale wspominasz o jego dedykacji, a 10 tys. Dziennie powinno być łatwo obsługiwane.

  • Co pokazuje top?
  • Gdzie jest wąskie gardło? Procesor, pamięć, operacje we / wy Czekaj?
  • Ile procesów Apache działa?
  • Ile połączeń pokazano w netstat?

Zgadywanie, procesor jest prawdopodobnie wąskim gardłem spowodowanym przez PHP. Korzystanie z APC i wtyczki buforowania WP jest dobrym sposobem na złagodzenie tego, co już zrobiłeś. Możesz także wypróbować model Apache „MPM” zamiast „Prefork”. Upewnij się, że masz wystarczającą ilość pamięci przydzielonej APC, aby mogła buforować twoje skrypty PHP, a nie „przegapić”.

Może to być także MySQL - sprawdź, czy to nie blokuje procesora lub dysku.

Rozważ wyłączenie mod_deflate, jeśli masz go włączoną - zapewnia to czas ładowania, ale może zwiększyć obciążenie procesora. Może warto spróbować.

Użyj narzędzia, takiego jak „oblężenie” lub „ab”, aby przeprowadzić test porównawczy serwera i dowiedzieć się, w którym momencie serwer zwalnia.

Oto niektóre z moich zakładek z dostrajania wydajności serwera WWW: 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/

Ale moja oryginalna rada pozostaje taka sama - dowiedz się, co jest wąskim gardłem! W przeciwnym razie ślepo próbujesz poprawić wydajność (i oczywiście poprawa wydajności jest zawsze dobra), ale nie wiedząc, na który obszar zwrócić uwagę.


0

Włącz także moduł statusu serwera i odwiedź tę stronę, aby dowiedzieć się, co się dzieje.

Możesz zamieniać. Czy sprawdziłeś już vmstat? 2 GB pamięci RAM dla 80 MaxClients to tylko 25 MB na każdy (zakładając, że pudełko nie robi nic innego). Twoje MaxClients mogą być zbyt wysokie. Rozwiązanie tego jest oczywiste: dodaj więcej pamięci RAM lub obniż MaxClients. Jeśli linia komend reaguje wolno po ponownym uruchomieniu apache, jest to jedna z oznak tej sytuacji.

Możliwe jest również, że karmisz łyżeczką niektórych klientów mobilnych (lub innych klientów korzystających z wolnych połączeń) „dużymi” plikami, zużywając w ten sposób wszystkie dostępne gniazda apache. Może masz za mało MaxClients. Sprawdzanie statusu serwera powie ci, co robią w tym czasie wszyscy klienci. Jednym z rozwiązań dla tej sytuacji jest zwiększenie MaxClients (ale może to również zmienić się w powyższą sytuację). Lepszym rozwiązaniem jest zainstalowanie akceleratora HTTP przed Apache (jedna bezpłatna opcja to perlbal.) Jeśli linia poleceń jest normalna prędkość po ponownym uruchomieniu apache, to jedna z oznak tej sytuacji.


0

Korzystanie z mod_status jest sposobem na sprawdzenie, co dzieje się w wielu instancjach Apache, ale należy pamiętać, że naprawdę wpłynie to na wydajność. Wygląda na to, że zjada pamięć i w jednym przypadku nie byłem w stanie zdiagnozować, czy to było przyczyną blokowania pojedynczego procesu w ustawieniu tylko do odwrotnego proxy, gdzie nic nie było podawane bezpośrednio. Są one oczywiście zgłaszane przez użytkowników jako „ładowanie strony trwa wieczność”. Nie rozumieją nawet różnicy między „czekaniem byłoby 10 sekund” i „nigdy się nie skończy”, ponieważ zwykle wciskają Stop w przeglądarce po kilku (<10) sekundach.

Sprawdź także, czy konfigurujesz właściwe miejsce (łatwo zobaczyć za pomocą mod_status, ponieważ widzisz liczbę instancji / procesów). Podstawowa konfiguracja przynajmniej w Ubuntu ma sekcje ifdef'ed na tryb MPM i można łatwo edytować tryb roboczy, gdy uruchomisz prefork (jak sugeruje konwencjonalna mądrość z niejasnego poczucia, że ​​PHP nie jest wątkowo bezpieczny).

No i przede wszystkim: działaj na szczycie jako root i uważaj na maksymalne zasoby. Pamięć, dysk, procesor - zobaczysz.

Jeszcze jedno: pomysł na dezaktywację mod_deflate może być dobry, chociaż twoje ustawienie nie jest podatne na błąd niepoprawnych informacji o długości treści, powodując, że przeglądarka czeka na dane „na zawsze”, dając ci raporty „martwego powolnego” do „nie odpowiadania”.

BTW: 10 000 stron dostarczanych dziennie plus pliki multimedialne na tym komputerze powinny stanowić problem tylko wtedy, gdy wszystkie odwiedzą w ciągu godziny.


0

Kilka porad, szczególnie jeśli hostujesz wiele plików multimedialnych:

  • Przenieś swoje media do dedykowanej instancji Apache (lub lepiej: nginx). Bez PHP, bez modułów, tylko czysty serwer HTTP, który dostarcza media tak szybko, jak to możliwe.
  • Pamięć podręczna, pamięć podręczna, pamięć podręczna! Użyj wtyczki super cache na wordpress. To bardzo pomaga.
  • Sprawdź konfigurację Apache na nagłówkach. Sprawdź, czy dla obrazów i innych „stabilnych” mediów czas wygaśnięcia jest ustawiony na odległą datę i czy twój apache zwraca kod HTTP 304 na żądanie klientów
  • Włącz mod_deflate. Może to zmniejszyć wydajność przez klientów, będą szybciej obsługiwane.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.