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.

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

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

Gearman ist ein Jobserver und ermöglicht es Aufgaben auf verschiedene Prozesse und/oder Maschinen auszulagern. Dabei arbeitet man mit sogenannten “Workern” die auf einem beliebigen Server darauf warten Aufgaben zu erledigen. Besonders schön ist, dass diese Worker ebenfalls in PHP programmiert werden können. Zunächst jedoch ein paar Worte zur Installation.

Auf einem Debian Squeeze System ist die Installation denkbar einfach. Einfach den Jobserver via Aptitude oder apt-get installieren. Das Paket heisst “gearman”. Im init.d Ordner liegt dann auch direkt ein Script mit dem der Server gestartet werden kann:

/etc/init.d/gearman-job-server start

Um den Gearman Server in PHP “ansprechen” zu können benötigt man nun noch die Gearman-Extension welche über PECL installiert werden kann.
Hinweis: Es wird das Paket “php5-dev” benötigt. Falls dieses noch nicht installiert ist sollte man das an dieser Stelle tun.

Dann die PHP-Extenstion über PECL installieren:

pecl install gearman

Hinweis: Falls das Paket hier nicht installiert werden kann weil es eine Beta Version ist, stattdessen folgenden Befehl verwenden:

pecl install gearman-beta

Damit sollte die Extension erstellt sein und kann in der php.ini geladen werden. Dazu einfache folgendes in der php.ini ergänzen:

extension = gearman.so

Hinweis: Da die Worker normalerweise als CLI-Programme laufen, die entsprechende php.ini nicht vergessen.

Nun sollte alles soweit sein, dass Gearman verwendet werden kann.

Zunächst brauchen wir einen Worker welcher im Hintergrund läuft und darauf wartet Aufgaben zu erledigen. Hier ein Beispiel:

<?php
class WorkerExample
{
	private $_GearmanWorker = null;
 
	public function  __construct()
	{
		$this->_GearmanWorker = new GearmanWorker;
		$this->_GearmanWorker->addServer('127.0.0.1', 4730);
 
		$this->_startupWorker();
	}
 
	private function _startupWorker()
	{
		$this->_GearmanWorker->addFunction('foobar', array($this, 'foobar'));
		while($this->_GearmanWorker->work());
	}
 
	public function foobar($Job)
	{
		$params = array();
		$params = unserialize($Job->workload());
 
		// do some work here...
		var_dump($params);
	}
}
 
$Worker = new WorkerExample;

Diesen Worker kann man nun z.B. als worker.php speichern und dann zum testen in einem Screen laufen lassen:

php worker.php

Nun brauchen wir noch ein Script welches diesen Worker aufruft, der sogenannte Client:

<?php
$Client = new GearmanClient();
$Client->addServer('127.0.0.1', 4730);
 
$data = array(
	'foo' => 42,
	'bar' => 1337
);
$data = serialize($data);
$Client->doBackground('foobar', $data);

Wenn nun dieser Client aufgerufen wird sollte man in dem Screen in dem der Worker läuft eine Ausgabe der übergebenen Parameter sehen.
Im Code sieht man sofort dass die IP des Servers auf dem Gearman läuft angegeben wird. Hier kann natürlich auch ein anderer Server als localhost benutzt werden. Mit “doBackground” wird der Worker aufgerufen und das Script läuft direkt weiter ohne auf irgendeine Antwort des Workers zu warten.

Über die vielen weiteren Möglichkeiten des Gearman-Servers kann man sich am besten informieren wenn man einen Blick auf die Methoden der Gearman-Extension auf php.net wirft. Und nun viel Spass beim experimentieren.

Eine sftp-upload Funktion könnte beispielsweise so aussehen:

public function sftp_putfile($local_file, $remote_file, $mode = 0664)
{
	$remote_file = (substr($remote_file, 0, 1) != '/') ? '/' . $remote_file : $remote_file;
	$sftp_stream = fopen('ssh2.sftp://' . $this->sftp_connection . $remote_file, 'w');
 
	if(!$sftp_stream)
	{
		$this->set_sftp_error(7);
		return false;
	}
 
	$data_to_send = file_get_contents($local_file);
 
	if ($data_to_send === false)
	{
		$this->set_sftp_error(7);
		return false;
	}
 
	if(fwrite($sftp_stream, $data_to_send) === false)
	{
		$this->set_sftp_error(7);
		return false;
	}
	fclose($sftp_stream);
	return true;
}

Diese beispielhafte Methode stammt aus einer SFTP Klasse die ich vor kurzem für eine Projekt geschrieben habe. Die komplette Klasse habe ich hier zum download hinterlegt.

Da es mittlerweile schon einige PHP Klassen gibt welche oAuth unterstützen ist die Umstellung relativ einfach zu bewerkstelligen. Hier ein kleines Tutorial:

Zunächst muss man auf http://dev.twitter.com/ eine neue “App” anlegen. (Vorher einloggen) Der Prozess ist selbsterklärend. Nachdem man die App angelegt hat erhält man einen “Consumer key” und ein “Consumer secret”. Diese beiden Strings benötigen wir später für die Authentifizierung. Weiterhin braucht man den “oAuth Token” und das “oAuth Token Secret”. Um diese zu bekommen oben auf Your apps klicken. Dann auf “Edit Details” der entsprechen App. Nach zwei weiteren Klicks auf “Application detail” (rechts) und “My Access Token” (auch rechts) hat man alle benötigten Tokens und Passwörter zusammen die man in einem PHP-Script benötigt.

Nun kann man entweder selbst damit anfangen eine oAuth Authentifizierung zu coden oder man benutzt eine der fertigen Klassen. Ich habe für dieses Beispiel eine fertige oAuth Klasse von Abraham Williams benutzt.
Hier ein kleines Codebeispiel für die Authentifizierung mit oAuth und dem anschließenden posten eines Tweets:

$consumer_key = 'insert_key';
$consumer_secret = 'insert_secret';
$access_key = 'insert_key';
$access_secret = 'insert_secret';
 
require_once('twitteroauth/twitteroauth.php');
 
$twitter = new TwitterOAuth ($consumer_key, $consumer_secret, $access_key, $access_secret);
$twitter->post('statuses/update', array('status' => 'Testing oAuth. Please ignore...'));

1

echo date(DATE_COOKIE, time());

Alle dieser nützlichen Konstanten sind hier dokumentiert: Datumskonstanten bei php.net