2GB RAM E6500 CPU'da günde 10K + wordpress görüntülemesi için apache'yi optimize edin


10

Wordpress blogumu günde yaklaşık 10 bin + sayfa görüntüleme ile sunan ubuntu'da apache / php ile özel bir sunucum var. APC ile kurulu W3TC fişim var.

Ancak her zaman ve sonra sunucu yanıt vermiyor veya yavaş yavaş ölüyor ve geri almak için apache'yi yeniden başlatmam gerekiyor.

Heres benim yapılandırma ne yanlış yapıyorum?

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/

Yanıtlar:


23

WordPress Performansım ve Önbellek Yığını

Bu, düşük ila orta aralıklı tek bir sunucu veya VPS için harika bir WordPress performans yığınıdır. Orta menzili yaklaşık 1G bellek ve oldukça hızlı sürücülerle tek çekirdekli olarak sınıflandırıyorum.

Kutunuzda bu, saatte 10.000'den fazla sayfa görüntüleme sunabilecektir.

Sunucu Yığını

  • Linux - Debian Lenny veya Ubuntu
  • Nginx - Ters proxy statik dosya önbelleği olarak yapılandırıldı
  • Apache - Apache alternatif bir bağlantı noktasında Nginx tarafından yüklenen PHP'yi işleyecek
  • MySql - WP için gereklidir, en son kararlı sürümü çalıştırdığınızdan emin olun
  • PHP - 5.2 veya 5.3 şubesinin son kararlı sürümü

PHP Önbellek

  • APC - mmap bellek ve shm boyutu en az 128M ile yapılandırın

WordPress Performans Eklentisi Yığını

  • Nginx proxy önbellek entegratörü
  • W3 Total Cache - Sayfa önbelleğini geliştirilmiş diske ayarla, diske küçült ve nesne ile db'yi APC'ye ayarla.
  • Kendi Kendine Barındırılan CDN - Sunucuda yalnızca statik dosya sunmak üzere ayarlanmış etki alanına işaret eden 4 cname diğer adı oluşturun

W3 Toplam Önbellek ile sayfa önbelleği için diski kullanıyoruz ve küçültüyoruz çünkü Nginx statik dosyalarımıza çok hızlı hizmet verecek.

Nginx'i statik dosyaları sunacak ve PHP'yi Apache'ye geçirecek şekilde nasıl yapılandırılır

Apache'yi tek başına kullanmayla ilgili sorun, bir bağlantı açar ve statik dosyalar için bile her istekte php'ye vurmasıdır. Bu bağlantıyı boşa harcar, çünkü Apache onları açık tutacaktır ve çok fazla trafiğiniz olduğunda bağlantılarınız kullanılmasa bile bataklığa uğramış olacaktır.

Varsayılan olarak Apache, varsayılan web bağlantı noktası olan 80 numaralı bağlantı noktasındaki istekleri dinler. Öncelikle Apache conf ve sanal ana makineler dosyalarımızda 8080 numaralı bağlantı noktasını dinlemek için değişiklikler yapacağız.

Apache Yapılandırması

httpd.conf

KeepAlive'yi kapalı olarak ayarla

ports.conf

NameVirtualHost *:8080
Listen 8080

Site Başına Sanal Ana Bilgisayar

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

Ayrıca günlükleriniz ziyaretçilerinizin gerçek ip adreslerini içerecek şekilde mod_rpaf da kurmalısınız . Aksi takdirde, günlükleriniz kaynak IP adresi olarak 127.0.0.1'e sahip olacaktır.

Nginx Yapılandırması

Debian'da depoları yüklemek için kullanabilirsiniz, ancak yalnızca 0.6.33 sürümünü içerirler. Daha sonraki bir sürümü kurmak için lenny backports paketlerini eklemelisiniz

$ nano /etc/apt/sources.list

Bu satırı dosyaya ekle deb http://www.backports.org/debian lenny-backports main

$ nano /etc/apt/preferences

Dosyaya aşağıdakileri ekleyin:

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

Paketleri doğrulamak ve sisteminizin paket veritabanını güncellemek için anahtarı backports.org'dan içe aktarmak için aşağıdaki komutları verin:

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

Şimdi apt-get ile yükleyin

apt-get install nginx

Bu kaynaktan derlemekten çok daha kolaydır.

Nginx conf ve sunucu dosyaları yapılandırması

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

Şimdi Nginx sanal hostinginizi kurmanız gerekecek. Ben siteler kullanılabilir yöntem siteleri kullanılabilir dizindeki bir dosyaya bağlı her v ana bilgisayar sym ile kullanmak istiyorum.

$ 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

Not:

Aşağıdaki dosyalardaki statik önbellek ayarları yalnızca Nginx proxy önbellek entegratörü eklentisi etkinse çalışır.

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 site başına conf (Çoklu site için sadece bir vhost'a ihtiyacınız olacak)

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

        }

Kendinden Barındırmalı CDN conf

Kendi barındırdığınız CDN conf için yalnızca proxy geçişi olmadan statik dosyaları sunacak şekilde ayarlamanız gerekir

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

    }

Şimdi sunucuları başlatın

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

Deney Sonuçları

Apache Bench'te bu kurulum teorik olarak saniyede 1833.56 istek sunabilir

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

alternatif metin


Nginx statik dosyaları işlemek ve apache php dosyalarını işlemek, ancak statik dosya bloğunda "proxy_pass wordpressapache ;" Apache'nin statik dosyaları işlediği anlamına gelmiyor mu?
srchulo

0

Bu, standart bir Apache yapılandırmasına benziyor, ancak bir kısmı HTML'ye benzediği için çıkarılmış görünüyor.

Sunucunuz yavaş yanıt verdiğinde neler olduğunu araştırmanız gerekir. Sunucunuzun özelliklerini söylemezsiniz, ancak sunucunun adanmış ve 10k / gün kolayca ele alınmalıdır.

  • Top ne gösteriyor?
  • Darboğaz nerede? CPU, Bellek, G / Ç Bekle?
  • Kaç tane Apache işlemi çalışıyor?
  • Netstat'ta kaç bağlantı gösteriliyor?

Tahmin edersek, CPU muhtemelen PHP'nin neden olduğu darboğazdır. APC ve bir WP önbellek eklentisi kullanmak, bunu zaten hafifletmek için iyi yöntemlerdir. Ayrıca "Prefork" yerine Apache'nin "MPM" işlem modelini de deneyebilirsiniz. PHP betiklerinizi önbelleğe alabilmesi için 'özledim' değil, APC'ye yeterli bellek ayırdığınızdan emin olun.

Ayrıca MySQL de olabilir - CPU'nun veya diskin üzerinde olup olmadığını kontrol edin.

Etkinleştirdiyseniz mod_deflate'i kapatmayı düşünün - yükleme sürelerine fayda sağlar, ancak CPU yükünü artırabilir. Denemeye değer olabilir.

Sunucunuzu kıyaslamak ve sunucunuzun hangi noktada yavaşladığını bulmak için 'kuşatma' veya 'ab' gibi bir araç kullanın.

İşte web sunucusu performans ayarındaki yer işaretlerimden bazıları: 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/

Ama orijinal tavsiyem aynı kalıyor - darboğazın ilk önce ne olduğunu öğrenin! Aksi takdirde, dikkatinizi hangi alana odaklayacağınızı bilmeden, körü körüne performansı iyileştirmeye çalışıyorsunuz (ve performansı iyileştirmek her zaman iyidir).


0

Ayrıca sunucu durumu modülünü etkinleştirin ve neler olduğunu öğrenmek için bunu ziyaret edin.

Takas ediyor olabilirsiniz. Bu sırada vmstat'a baktınız mı? 80 MaxClients için 2GB RAM, her biri için sadece 25 MB'dir (kutunun başka bir şey yapmadığını varsayarsak.) MaxClients'ınız çok yüksek olabilir. Bunun çözümü açıktır: daha fazla RAM veya daha düşük MaxClients ekleyin. Apache'yi yeniden başlattığınızda komut satırı yavaş yanıt veriyorsa, bu durumun bir göstergesidir.

Bazı mobil istemcileri (veya yavaş bağlantılardaki diğer istemcileri) 'büyük' ​​dosyalarla kaşıkla beslemeniz ve böylece mevcut tüm apache yuvalarınızı tüketmeniz de mümkündür. Belki de çok az MaxClients'ınız var. Sunucu durumunu kontrol etmek, o istemcilerin o anda ne yaptığını size söyleyecektir. Bu durum için bir çözüm MaxClients'ı artırmaktır (ancak bu yukarıdaki duruma da dönüşebilir.) Bunun için daha iyi bir çözüm apache'nin önüne bir HTTP hızlandırıcısı kurmaktır (bir boş seçenek perlbal'dir.) Komut satırınız normalse apache'yi yeniden başlattığınızda hız, bu durumun bir göstergesidir.


0

Mod_status kullanmak , birden fazla Apache örneğinde neler olup bittiğini görmenin bir yoludur, ancak performansın gerçekten düşeceğini lütfen unutmayın. Hafızayı yiyor gibi görünüyor ve bir durumda, doğrudan hiçbir şeyin sunulmadığı bir ters proxy sunucu ayarında tek işlem kilitlemelerinin nedeni olup olmadığını teşhis edemedim. Bunlar elbette kullanıcılar tarafından "sayfayı yüklemek sonsuza dek sürüyor" olarak bildirilir. "Beklemek 10 saniye daha sürecek" ve "hiç bitmeyecek" arasındaki farkı bile anlamıyorlar, çünkü tarayıcılarında genellikle (<10) saniye sonra Stop'u vuruyorlar.

Ayrıca doğru yeri yapılandırıp yapılandırmadığınızı da kontrol edin (örneklerin / işlemlerin miktarını gördüğünüz için mod_status kullanarak kolayca görülebilir). En azından ubuntu altında hisse senedi yapılandırması, MPM modu başına ifdef'ed bölümlerine sahiptir ve prefork çalıştırırken işçi modunu düzenlemek kolaydır (PHP'nin iş parçacığı olmadığı bulanık bir duygudan gelen geleneksel bilgelik tarafından önerildiği gibi).

Oh ve en önemlisi: Run tepesinde maxed ressources için root ve saatin olarak. Bellek, disk, CPU - göreceksiniz.

Bir tane daha: Ayarınız yanlış İçerik Uzunluğu bilgisinde hataya yatkın olmamasına rağmen, mod_deflate'i devre dışı bırakma fikri, tarayıcının "sonsuza kadar" veriyi "yanıt vermemesine" ilişkin raporlar vermesini beklemesine neden olur.

BTW: Günde 10.000 sayfa yayınlanan sayfalar ve bu makinedeki ortam dosyaları yalnızca bir saat içinde ziyarete gelirse sorun teşkil etmelidir.


0

Bazı tavsiyeler, özellikle çok fazla medya dosyası barındırıyorsanız:

  • Ortamlarınızı özel bir Apache (veya daha iyisi: nginx) örneğine taşıyın. PHP yok, modül yok, medyaları olabildiğince hızlı dağıtacak çıplak bir http sunucusu.
  • Önbellek, önbellek, önbellek! Süper önbellek eklentisini wordpress'te kullanın. Çok yardımcı olur.
  • Başlıklarda apache yapılandırmanızı kontrol edin. Resimlerin ve diğer "sabit" ortamların son kullanma tarihinin uzak bir tarihe ayarlandığını ve apache'nizin istemciler tarafından istendiğinde HTTP 304 kodu döndürdüğünü doğrulayın
  • Mod_deflate'i etkinleştirin. Müşterilerin performanslarını düşürebilir daha hızlı servis edilecektir.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.