Optimierung Webserver [Apache2, nginx]


Eine Alternative zum direkten Ausliefern von statischen Inhalten über NGINX, wäre, statische Inhalte von NGINX cachen zu lassen. Ersteres wäre zwar besser, aber hier trotzdem ein Beispiel, wie das in etwa bei dir aussehen würde:

In der /etc/nginx/nginx.conf folgendes im http Block einfügen:

Code:
http {
    [...]

    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=nginxcache:10m inactive=6h max_size=1g;
    proxy_cache_key "$scheme://$host$request_uri";
    gzip on;
    gzip_http_version 1.1;
    gzip_comp_level 3;
    gzip_proxied any;
    gzip_min_length  1024;
    gzip_buffers 16 8k;
    gzip_types text/plain text/css text/javascript application/x-javascript application/xml text/xml;
    gzip_disable "MSIE [1-6].(?!.*SV1)";
    gzip_vary on;

    [...]
}
Und dann sollten deine vHosts etwa so aussehen:

Code:
server {

include   /etc/nginx/sites-enabled/urlfilter.inc;
include   /etc/nginx/sites-enabled/useragent.inc;
include   /etc/nginx/sites-enabled/ref.inc;
include   /etc/nginx/sites-enabled/remote_addr.inc;
include   /etc/nginx/sites-enabled/geoip.inc;

location /nginx_status {
  stub_status on;
  access_log off;
}

#location /phpmyadmin {
#  proxy_pass         http://127.0.0.1:82/phpmyadmin;
#  allow 1.1.1.1;
#  deny all;
# }

#location /wi {
#  proxy_pass         http://127.0.0.1:82/;
#  allow 1.1.1.1;
#  deny all;
# }


error_page   403  /403.html;
 location = /403.html {
  root   /var/www/sharedip;
 }

error_page 502 /502.html;
  location = /502.html {
        root /var/www/error;
  }

#    geoip_country  GeoIP.dat;

    listen       46.4.*.*:80;
    listen       46.4.*.*:80;
    listen       46.4.*.*:80;
    server_tokens off;
    access_log  /var/log/nginx/reverse.log;
    error_log /var/log/nginx/errorreverse.log;

    # proxy to Apache 2 and mod_python
    location / {
      location ~* \.(jpg|png|gif|jpeg|ico|js|css|doc|pdf|xls|ppt|docx|pptx|xlsx|swf|mp3|avi|mp4|m4a|wmv|wma)$ {
      proxy_cache_valid 200 4h;
      expires max;
      proxy_pass         http://127.0.0.1:80/;
      proxy_cache nginxcache;
      }
        proxy_pass         http://127.0.0.1:80/;
        proxy_redirect     off;

        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

        client_max_body_size       128m;
        client_body_buffer_size    128k;

        proxy_connect_timeout      180;
        proxy_send_timeout         180;
        proxy_read_timeout         180;

        proxy_buffer_size          16k;
        proxy_buffers              16 32k;
        proxy_busy_buffers_size    64k;
        proxy_temp_file_write_size 64k;
    }
}


server {

include   /etc/nginx/sites-enabled/urlfilter.inc;
include   /etc/nginx/sites-enabled/useragent.inc;
include   /etc/nginx/sites-enabled/ref.inc;
include   /etc/nginx/sites-enabled/remote_addr.inc;
include   /etc/nginx/sites-enabled/geoip.inc;

location /nginx_status {
  stub_status on;
  access_log off;
}
error_page   403  /403.html;
 location = /403.html {
  root   /var/www/sharedip;
 }

error_page 502 /502.html;
  location = /502.html {
        root /var/www/error;
  }

#    geoip_country  GeoIP.dat;

    listen       46.4.*.*:443;
    listen       46.4.*.*:443;
    listen       46.4.*.*:443;
    server_tokens off;

    ssl         on;
    ssl_certificate      /usr/local/nginx/conf/cert.crt;
    ssl_certificate_key  /usr/local/nginx/conf/cert.key;

    access_log  /var/log/nginx/reverse.log;
    error_log /var/log/nginx/errorreverse.log;

    # proxy to Apache 2 and mod_python
    location / {
      location ~* \.(jpg|png|gif|jpeg|ico|js|css|doc|pdf|xls|ppt|docx|pptx|xlsx|swf|mp3|avi|mp4|m4a|wmv|wma)$ {
      proxy_cache_valid 200 4h;
      expires max;
      proxy_pass         https://127.0.0.1:443/;
      proxy_cache nginxcache;
      }
        proxy_pass         https://127.0.0.1:443/;
        proxy_redirect     off;

        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

        client_max_body_size       128m;
        client_body_buffer_size    128k;

        proxy_connect_timeout      180;
        proxy_send_timeout         180;
        proxy_read_timeout         180;

        proxy_buffer_size          16k;
        proxy_buffers              16 32k;
        proxy_busy_buffers_size    64k;
        proxy_temp_file_write_size 64k;
    }
}
 
nginx liegt auf dem gleichen Server:
Das ganze befindet sich auf einem EQ4 bei Hetzner.
Vor dem Apache2 ist nginx als Reverse-Proxy installiert.

Es ist also Quatsch einen Cache anzulegen.

Nachteile, die aus einem Cache resultieren:
- man muss beim Apache auf die GZIP Einstellungen achten, sonst komprimiert man doppelt
- alle Dateien werden doppelt abgespeichert (1x Apache und 1x nginx)
- alle Dateien werden mindestens 1x beim Apache abgerufen = Last auf dem Apache
- alle fehlerhaften Zugriffe gehen durch bis zum Apache (Fehlerseiten kann man cachen ist aber gefährlich, wenn die Datei später doch existieren soll)

Genau deswegen ist der einzig richtige Weg "root" zu benutzen. nginx greift dann direkt auf das htdocs Verzeichnis zu und liefert die Dateien so aus, wie sie auf der Platte sind und komprimiert sie bei Bedarf.

Einen Cache nutzt man nur, wenn der Proxy auf einem separaten Server liegt, der keinen direkten Zugang zu den Festplatten des Webservers hat.
 
Last edited by a moderator:
Ich habe gleich zu Anfang meines Beitrags erwähnt, dass es sich um eine schlechtere Alternative handelt, als statische Dateien direkt ohne Caching von NGINX serven zu lassen.
Trotzdem ist es mit Caching (auch auf dem selben Server) immer noch besser, als alle Anfragen zum Apache weiterzuleiten. Oder etwa nicht? :)
 
Ich würde nicht "schlechter" sagen, sondern einfach für eine andere Hardware-Konstellation gedacht. Wenn man mehrere Server nutzt (z.B. CDN), dann geht es ja nur mit Cache und da ist es dann die "gute" Variante ^^
 
Natürlich auf diesen speziellen Fall bezogen "schlechter", hier geht es ja um einen einzelnen Server und nicht um ein CDN.
Man könnte auch noch Varnish zwischen NGINX und Apache laufen lassen und natürlich einen Opcode Cacher wie APC oder eAccelerator verwenden, sofern noch nicht vorhanden.
 
APC etc. aber nur, wenn PHP nicht per fcgi läuft. Ansonsten hat man keinen zentralen Cache.

Varnish habe ich noch nicht getestet. mod_pagespeed wäre auch noch eine Idee, habe ich aber auch noch nicht getestet.
 
Soweit ich sehe, redet der OP nur von einer Website auf dem Server und nicht von vielen. In diesem Fall würde APC o.Ä. also sehr wohl auch mit FCGI Sinn machen.

mod_pagespeed könnte in diesem Fall auch interessant sein, persönlich habe ich es allerdings noch nicht in einer Live Umgebung getestet.
 
Du meinst mit PHP-FPM? Sonst kenne ich nichts, wo man eine zentralen Cache realisieren kann.
 
Die Frage ist doch, wozu benötigt man einen zentralen Cache, wenn PHP mit FCGI bei einer Website sowieso nur unter einem User ausgeführt wird?
 
Weil jedes Child einen eigenen Cache bekommt. Man kann da wohl tricksen und nur 1 Child pro Prozess zulassen, aber das ist auch keine gute Lösung. Besonders wenn man per PHP Daten im RAM ablegen will z.B. mit vBulletin.

Genau diesen Misstand haben wir aktuell (bei jedem Reload neuer Cache):
http://www.maxrev.de/php/apc.php

Mit PHP-FPM soll das gehen:
http://serverfault.com/questions/387941/php-fpm-and-apc-for-shared-hosting

Nachteil ist, wie Du dort lesen kannst, dass es nicht geeignet ist für Shared Hosting (also mehrere Kunden auf einem Server), weil alle auf einen Cache zugreifen würden. Aber das ist in dem Fall hier ja egal.
 
Last edited by a moderator:

Back
Top