Lighttpd mit PHP-FPM

Die meisten Root- oder V-Server werden in der Standard-Konfiguration ganz ohne Webserver oder mit Apache2 ausgeliefert. Mein Tipp hier: Alternativen testen! Lighttpd oder Nginx sind in vielen Fällen schneller und benötigen weniger Ressourcen. Jeder Webserver hat seine Vor- und Nachteile, es kann also nicht schaden die Alternativen einmal zu testen. Ich persönlich verwende schon seit längerem Lighttpd und bin sehr zufrieden damit. Die Konfiguration der verschieden Webserver sollte Dank zahlreicher Tutorials die im Netz verfügbar sind kein Problem darstellen.
Desweiteren empfehle ich dringen statt des “üblichen” PHP-Moduls (mod_php) PHP-FPM zu verwenden. Zusammen mit Lighttpd oder Nginx schafft ein Server so nicht selten wesentlich mehr Requests/Sec abzuarbeiten. Darüber hinaus bietet PHP-FPM einige sehr nützliche Features wie z.b. das Anlegen verschiedener Pools. Damit ist es möglich verschiedenen PHP-Prozesse mit verschiedenen Benutzern zu starten. Das bringt Sicherheits-Vorteile mit sich und lässt Schreibrechte-Probleme der Vergangenheit angehören. Zum Thema Lighttpd und PHP-FPM habe ich hier auch schon andere Beiträge verfasst.

Opcode Caching mit XCache

Da PHP keinen eigenen Opcode-Cache mit sich bringt fehlt dieser häufig auf Webserver. Ein Opcode oder Bytecode-Cache sorgt dafür, dass PHP-Scripte nicht bei jedem Aufruf neu in Bytecode übersetzt werden müssen. Besonders bei vielen gleichzeitigen Anfragen an den Webserver kann ein solcher Cache die CPU-Last erheblich verringern. Neben dem Zend-Optimizer, eAccelerator und APC gibt es hier noch meinen persönlichen Favoriten XCache. Installation und Konfiguration sollten keine Probleme bereiten, da es für quasi jede Linux-Distribution bereits fertige Pakete gibt.
Hinweisen möchte ich jedoch noch auf das XCache-Admin Feature denn hier kann man gut sehen ob und wie gut der Opcode-Cache tatsächlich arbeitet. Die obere “Total” Zeile zeigt an wie viele der Requests aus dem Cache (hits) ausgeliefert werden konnten und wie viele nicht (misses). Ausserdem kann man sehen wie viel der zur Verfügung stehen Speichers aktuell benutzt wird. Sollte der Wert der Misses im Verhältnis zu den Hits sehr hoch sein, ist es ggf. sinnvoll XCache etwas mehr Speicher zu Verfügung zu stellen.

Requests begrenzen – mod_evasive und mod_status

Über Sinn oder Unsinn von Modulen wie mod_evasive kann man sich selbstverständlich streiten und mir ist klar, dass keines dieser Module einem richtigen DDoS Angriff entgegenwirken kann, das liegt in der Natur der Sachen. Dennoch halte ich den Einsatz für sinnvoll, denn vielen “Script-Kiddy”-, Spam-, Brutforce- und sonstigen Attacken kann man damit einen Riegel vorschieben. Mod_evasive mach im Prinzip nichts weiter als die Requets pro IP auf den Webserver zu limitieren. Eine gute Übersicht über die Requests die Lighttp aktuell verabeitet liefert das Modul mod_status.

Lasttest
Nachdem man nun alle (oder einen Teil) dieser Optimierungen vorgenommen hat. Sollte man seinen Webserver mit einem simplen Lasttest durchführen um zu sehen ob der Webserver wirklich durchhält wenn er ein paar parallele Requests abzuarbeiten hat. Tools für diese Aufgabe sind zum Beispiel Apache Benchmark oder LoadUI. Am besten startet man mit einigen wenigen Anfragen pro Sekunde und schaut auf der Konsole des Server wie sich da auf die Last auswirkt. Da man bei solchen Lasttests in der Regel nur von einer IP aus testet kann man hier auch direkt prüfen ob mod_evasive korrekt funktioniert. Ist das der Falls sollte man die Anfragen pro Sekunde im Lasttest-Tools quasi beliebig nach oben schrauben können ohne das die Serverlast merklich steigt. Wie viele Requests/Sec ein Server verträgt hängt natürlich start von der Hardware und dem aufgerufenen Script ab.
Neben den Requests pro Sekunde sollte man auch noch darauf achten ob alle Anfragen nach einer bestimmten Zeit wieder geschlossen werden. Hierzu kann an einen Blick auf die mod_status Weboberfläche werden. Normalerweise sollten allen Verbindungen nach einer kurzen Zeit wieder geschlossen werden. Wenn Verbindungen für eine sehr lange Zeit offen bleiben oder gar nicht geschlossen werden, sollten die entsprechenden Parameter in der Konfiguration noch einmal überprüft werden.

Ich hoffe ich konnte in diesem kurzen Anriss zum Thema Webserver-Konfiguration auf die häufigsten Performance-Bremsen eingehen und ein paar nützliche Tipps geben. Anregungen natürlich wie immer hin den Kommentaren.

Im zweiten Teil der “Performance-Reihe” wird es dann um Datenbank-Abfragen gehen, bzw. darum wie man hier optimieren kann.

Das Projekt bietet Twitterwalls in Echtzeit. Dazu werden Tweets aus der Twitter Streaming-API direkt per Websocket-Server an den Browser weitergeleitet. Ausserdem dient das Projekt natürlich auch dazu die Stabilität des Websocket-Servers im Live-Betrieb zu testen und weiter zu optimieren.
Falls ihr in Zukunft also mal eine Twitterwall für ein Event o.Ä. braucht behaltet jitt.li im Hinterkopf.

Allerdings waren (zumindest bei mir) nach der Installation noch einige kleine Kniffe notwendig bis der Tunnel vernünftig lief. An dieser Stelle noch kurz der Hinweis, dass als Clients Windows 7 bzw. Windows XP Rechner zum Einsatz kommen.

Problem 1: Clients können sich einwandfrei verbinden, es können jedoch keine Daten empfangen werden.
Lösung: Damit der Server empfangene Daten zu den Clients “weiterrouten” kann ist eine IPTables Regel notwendig. Bei mir brachte folgendes die Lösung:

iptables --table nat --append POSTROUTING  --out-interface eth0 --jump MASQUERADE

Problem 2: Der Tunnel funktioniert grundlegend, die Verbindung “friert jedoch bei gößeren Datenmenegen ein”.
Lösung: Auch hier hilft ein Regeln in den IPTables weiter:

iptables --append FORWARD --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu

Desweiteren habe ich zur Lösung dieses Problems die MTU und MRU angepasst und auf einen Wert von 1400 eingestellt.
Diese Werte können in der Datei /etc/ppp/pptpd-options angepasst werden.

Problem 3: Clients werden immer wieder vom VPN-Server getrennt.
Lösung: In meinem Fall brachten mich diese Zeilen in den Logfiles auf die Lösung:

No response to 4 echo-requests
Serial link appears to be disconnected.

Offensichtlich antworteten einige Clients nicht (oder nicht zuverlässig) auf die vom Server verschickten LCP-Echo-Requests. Nachdem auch die Erhöhung der maximal nicht beantworteten Requests keine Abhilfe brachte habe ich die Echo-Anfragen schließlich komplett deaktiviert. Dies kann man in der Datei /etc/ppp/options erledigen indem man folgende zwei Werte auf 0 setzt:

lcp-echo-interval 0
lcp-echo-failure 0

Ich hoffe dieser Beitrag kann helfen falls jemand auf die gleichen Probleme stößt, z.B. ich wenn ich in ein paar Monaten mal wieder einen pptpd aufsetze

Viel Spass bei basteln

HINWEIS: Da der Server aktuell ständig weiterentwickelt wird habe ich ein Repository auf Github angelegt. Bitte den jeweils aktuelle Code verwenden: https://github.com/lemmingzshadow/php-websocket

UPDATE: As the project is constantly updated and improved I created a repository on github. Please get the code here: https://github.com/lemmingzshadow/php-websocket

Hier die Klasse + Beispielaufruf:

ACHTUNG: Eine aktuellere Version dieser Klasse gibt es hier: PHP Websocket Server/Client nach Draft hybi-10

/**
 * Very basic websocket client.
 * Supporting handshake from drafts:
 *	draft-hixie-thewebsocketprotocol-76
 *	draft-ietf-hybi-thewebsocketprotocol-00
 * 
 * @author Simon Samtleben <web@lemmingzshadow.net>
 * @version 2011-09-15
 */
 
class WebsocketClient
{
	private $_Socket = null;
 
	public function __construct($host, $port)
	{
		$this->_connect($host, $port);	
	}
 
	public function __destruct()
	{
		$this->_disconnect();
	}
 
	public function sendData($data)
	{
		// send actual data:
		fwrite($this->_Socket, "\x00" . $data . "\xff" ) or die('Error:' . $errno . ':' . $errstr); 
		$wsData = fread($this->_Socket, 2000);
		$retData = trim($wsData,"\x00\xff");        
		return $retData;
	}
 
	private function _connect($host, $port)
	{
		$key1 = $this->_generateRandomString(32);
		$key2 = $this->_generateRandomString(32);
		$key3 = $this->_generateRandomString(8, false, true);		
 
		$header = "GET /echo HTTP/1.1\r\n";
		$header.= "Upgrade: WebSocket\r\n";
		$header.= "Connection: Upgrade\r\n";
		$header.= "Host: ".$host.":".$port."\r\n";
		$header.= "Origin: http://foobar.com\r\n";
		$header.= "Sec-WebSocket-Key1: " . $key1 . "\r\n";
		$header.= "Sec-WebSocket-Key2: " . $key2 . "\r\n";
		$header.= "\r\n";
		$header.= $key3;
 
 
		$this->_Socket = fsockopen($host, $port, $errno, $errstr, 2); 
		fwrite($this->_Socket, $header) or die('Error: ' . $errno . ':' . $errstr); 
		$response = fread($this->_Socket, 2000);
 
		/**
		 * @todo: check response here. Currently not implemented cause "2 key handshake" is already deprecated.
		 * See: http://en.wikipedia.org/wiki/WebSocket#WebSocket_Protocol_Handshake
		 */		
 
		return true;
	}
 
	private function _disconnect()
	{
		fclose($this->_Socket);
	}
 
	private function _generateRandomString($length = 10, $addSpaces = true, $addNumbers = true)
	{  
		$characters = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"§$%&/()=[]{}';
		$useChars = array();
		// select some random chars:    
		for($i = 0; $i < $length; $i++)
		{
			$useChars[] = $characters[mt_rand(0, strlen($characters)-1)];
		}
		// add spaces and numbers:
		if($addSpaces === true)
		{
			array_push($useChars, ' ', ' ', ' ', ' ', ' ', ' ');
		}
		if($addNumbers === true)
		{
			array_push($useChars, rand(0,9), rand(0,9), rand(0,9));
		}
		shuffle($useChars);
		$randomString = trim(implode('', $useChars));
		$randomString = substr($randomString, 0, $length);
		return $randomString;
	}
}
 
$WebSocketClient = new WebsocketClient('127.0.0.1', 8000);
echo $WebSocketClient->sendData('1337');
unset($WebSocketClient);

Kurz zur Technik: Das Projekt ist eine komplette Eigenentwicklung, ich habe kein Framework benutzt. Als Templateengine verwende ich Smarty. Es werden einige HTML5- und CSS3-Elemente verwendet. Als Basis diente die HTML5-Boilerplate.

Angenommen ich möchte Daten aus verschiedenen Quellen verwenden, dann kann bzw. wird es vorkommen, dass diese Daten unterschiedliche Formate haben. Ein ganz simples Beispiel:

Quelle A: 44793 Bochum – Sonnig – 19 Grad
Quelle B: 44793 Bochum – 19 Grad – Sonnig

Die gleichen Daten, aber ein andere Reihenfolge.
Wenn ich nun für jede Datenquelle einen reguläre Ausdruck verwende um die Daten zu teilen, hatte man früher oft folgendes Problem:

$string = "44793 Bochum - Sonnig - 19 Grad";
preg_match('/(.+)\s-\s(.+)\s-\s(.+)/', $string, $temp);

Bei diesem Code finde ich die Temperatur einmal in $temp[3] und einmal in $temp[2]. Somit müsste ich für jede Datenquelle zusätzlich speichern in welchem Feld welcher Wert liegt. Und genau hier kommen die benannten Suchmuster ins Spiel. Durch eine kleine Modifikation des regulären Ausdrucks kann man den Teilmustern Namen geben:

$string = "44793 Bochum - Sonnig - 19 Grad";
preg_match('/(?<ort>.+)\s-\s(?<descr>.+)\s-\s(?<temperatur>.+)/', $string, $temp);

ergibt dann:

Array
(
    [0] => 44793 Bochum - Sonnig - 19 Grad
    [ort] => 44793 Bochum
    [1] => 44793 Bochum
    [descr] => Sonnig
    [2] => Sonnig
    [temperatur] => 19 Grad
    [3] => 19 Grad
)

Keine Magie, aber ungemein hilfreich wenn man es noch nicht kennt

Vorher:

$iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_DEV_RANDOM);

Nacher:

$iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_DEV_URANDOM);

Aus einem mir unbekannten Grund verabschiedeten sich auf meinem Debian Squeeze Server die PHP-CGI Prozesse mit folgender Meldung im Error-Log:

(mod_fastcgi.c.3001) backend is overloaded; we'll disable it for 1 seconds and send the request to another backend instead

Ich habe zwar eine generelle Lösung für dieses Problem gefunden (Link), diese konnte ich bei meiner Serverkonfiguration aber leider nicht anwenden. Da ich mehrere PHP-CGI-Pools mit verschiedenen UIDs/GIDs starte und diese in der Lighttpd-Config über die Sockets zuordne, konnte ich hier den “var.PID” Teil nicht anhängen. Davon abgesehen hatte es vorher viele Monate ohne diese Änderung funktioniert. Also habe ich mich kurzerhand dazu entschlossen zu PHP-FPM zu wechseln.

Leider gibt es das php-fpm Paket (noch?) nicht im Debian-Squeeze Repository deswegen habe ich die Paketquellen von Dotdeb verwendet. Die Umstellung funktionierte wunderbar einfach, denn man kann PHP-CGI und PHP-FPM problemlos parallel laufen lassen und einen Vhost nach dem anderen umstellen.
Ein recht gutes Tutorial zur Konfiguration von PHP-FPM gibt es hier. Nachdem FPM konfiguriert und gestartet ist kann man in den Vhost-Konfigurationen von Lighttpd einfach den PHP-CGI Teil durch die neue FPM-Konfiguration ersetzen. Das sieht in etwa so aus:

fastcgi.server = ( ".php" =>
      ( "localhost" =>
        (
          "host" => "127.0.0.1",
          "port" => "9001"
        )
      )
    )

Ein enormer Vorteil von PHP-FPM: Man kann mehrere Pools konfigurieren die mit unterschiedlichen UIDs/GIDs laufen, was die Sicherheit auf dem Server ein gutes Stück erhöht.

Mein Fazit: Die Umstellung von PHP-CGI auf PHP-FPM ist relativ leicht zu bewerkstelligen und den Aufwand in jeden Fall wert!