Reproduzierbar ist er folgendermaßen:

$from = new DateTime();
$from->setTime(0, 0, 0);
$from->setISODate(2010, 28, 1); //Montag der 28ten Woche 2010
 
echo $from->format('d.m.Y H:i'); //A
echo $from->getTimestamp(); //B
echo date('Y-m-d H:i', $from->getTimestamp()); //C

A: das ausgegeben Datum stimmt, es ist der 12.07.2010
B: der Timestamp ist viel zu hoch: 1291849200
C: der Beweis, der Timestamp gehört zum 29.05.2011 00:00

Wir haben lange versucht herauszufinden, warum dies passiert. Ein hässlicher Workaround ist dieser:

$from->add(new DateInterval('P0D'));

Wir fügen also ein Interval von 0 Tagen (oder Stunden, Minuten etc) hinzu, wodurch sich eigentlich nichts ändern sollte. Danach stimmt das Ergebnis von ->getTimestamp() allerdings, nämlich 1278885600.

Nachdem wir absolut keinen Grund feststellen konnten, haben wir das Vertrauen verloren und nutzen seitdem Zend_Date, welches, meiner Meinung nach, besser und einfacher zu bedienen ist. Das ZendFramework ist sowieso schon im aktuellen Projekt eingebunden (nicht als Framework an sich, eher als Klassensammlung), als sprach es auch nicht dagegen, einen riesen Klotz an Dateien/Klassen zu integrieren, um nur eine Klasse zu nutzen.

$date = new Zend_Date();
$date->setWeek(28)->setYear(2010)->setWeekday(1);
$date->setHour(0)->setMinute(0)->setSecond(0);
echo $date->getTimestamp();

Liefert das erwartete Ergebnis: 1278885600

Ist das nun wirklich ein riesen DateTime Bug oder liegt ein Denkfehler unsererseits vor?

class MyClass implements Interator {
  private $array;
}
 
$obj = new MyClass();
foreach($obj as $key => $val){
  ...
}

Damit dieses Konstrukt funktioniert, benötigt die Klasse “MyClass” ein paar weitere Methoden und ein Attribut, welche vom Interface vorgeschrieben werden:

public function rewind(){
  $this->pointer = 0;
}
public function current(){
  return $this->array[$this->pointer];
}
public function key(){
  return $this->pointer;
}
public function next(){
  $this->pointer++;
}
public function valid(){
  return isset($this->array[$this->pointer]);
}

Nun geht das ganze aber auch viel einfacher und mit saubererem Code, mit dem IteratorAggregate Interface und einem schon vorhandenem Iterator (wie dem ArrayIterator). Das Interface ist ziemlich Ähnlich und implementiert ebenfalls Traversable.

class MyClass implements IteratorAggregate {
  private $array;
  public function getIterator(){
    return new ArrayIterator($this->array);
  }
}
 
$obj = new MyClass();
foreach($obj as $key => $value){
  ...
}

Da auf meinem Websever lighttpd und nicht apache läuft, konnte ich mich nicht 100%ig an die Anleitung auf der WP MU Seite halten.

In lighttpd gibt es kein .htaccess, also müssen die Rewriteregeln (ich nutze Subdomains, keine Unterverzeichnisse), in die lighttpd-config. Das ganze sieht so aus:

$HTTP["host"] =~ "^((.*).?example\.de)$" {
  server.document-root = "/var/www/.../wp3/"
  server.error-handler-404 = "/index.php"  #hierdurch erspart man sich rewrite regeln für schöne permalinks
  url.rewrite-once = (
    "^/(.*/)?files/$" => "/index.php",
   "^/(.*/)?files/(.*)" => "/wp-content/blogs.php?file=$2",
    "^/([_0-9a-zA-Z-]+/)?(wp-.*)" => "/$2",
    "^/([_0-9a-zA-Z-]+/)?(.*\.php)$" => "/$2",
  )
}

Der Rest lief einwandfrei nach offizieller Anleitung, da in einigen der anderen Blogs allerdings recht viele Bilder sind, viel mir sofort die mangelnde Performance diesbezüglich auf. Der Grund war schnell gefunden, gab es 40 Bilder auf einer Seite, bedeutete dies, aufgrund der zweiten Rewriteregel, jeweils einen Aufruf eines PHP Skriptes, welches einen ganzen Schweif an includes inkl. Datenbankverbindungen und Queries mit sich bringt.

Die Lösung war, mit ein wenig Linuxwissen, aber schnell gefunden: Symlinks für jeden einzelnen Blog. Erfordert zwar ein wenig mehr Verwaltungsaufwand, spart aber das Umleiten über ein PHP Skript, um Bilder anzuzeigen. Die Regel muss dann so aussehen:

    "^/(.*/)?files/(.*)$" => "/wp-content/blogs.dir/%0/files/$2",

Das %0 funktioniert so nur, weil die Hostdefinition (Zeile 1 im oberen Code) als Pattern definiert ist!

Im, laut Anleitung angelegten, blogs.dir Verzeichnis müssen nun Symlinks angelegt werden:

ln -s /var/www/.../wp3/wp-content/blogs.dir/[BlogID] /var/www/.../wp3/wp-content/blogs.dir/[subdomain].example.de

Falls jemand eine elegantere Lösung kennt, als für jeden Blog einen Symlink anzulegen, als her damit!

Zuerst sollte erwähnt werden, dass MySQL im Normalfall pro Query nur EINEN pro Tabelle Index auf einmal nutzen kann (es gibt Ausnahmen, merged-index, aber nur unter bestimmten Umständen in bestimmten Queries).

Ein Beispiel für den Einsatz eines Index über mehrere Spalten, wäre z.B. das folgende:

Eine Tabelle, in welcher Nachrichten zwischen Benutzern aufbewahrt werden, folgende Spalten sind vorhanden:

ID (int), receiverUserID(int), senderUserID(int), subject(varchar), text(text), time(int)

Wollen wir nun alle Nachrichten finden, die User 123 an User 234 geschickt hat und das Ergebnis noch nach Zeit sortieren, brauchen wir folgendes Query:

SELECT ID, subject, text, time
FROM message
WHERE receiverUserID = 234 AND senderUserID = 123
ORDER BY time ASC

Zuerst fällt auf, dass man die Nachrichten nach ID sortieren kann, was im Normalfall besser ist, als nach time, da wir davon ausgehen, dass die ID sich von Nachricht zu Nachricht um eins erhöht und die neusten somit die höchsten IDs haben.

Ohne das Wissen, dass es mehrspaltige Indizes gibt, würde man einen Index auf receiverUserID oder senderUserID legen, alternativ sogar beides, allerdings würde MySQL dann nur einen von beiden nutzen.
Also legt man einen über beide an, was bei großen Datenmengen einen extremen Geschwindigkeitsschub bringen kann.

Um die Sortierung nun auch noch über den Index zu regeln, könnten man als dritte Spalte nun noch die ID in den Index aufnehmen, was allerdings nur sinnig ist, wenn man davon ausgeht, dass das Ergebnis wirklich viele Ergebnisse erzielen wird.

Es gibt definitiv keine Konfiguration, die allgemeingültig ist, aber ich versuche hiermit eine Hilfestellung zu geben, wie man die besten Werte für die eigenen Bedürfnisse findet.

Nicht nur der Server spielt eine Rolle, auch die Storage-Engine, um sich viel Stress zu ersparen, sollte man im vorraus planen, was man braucht und für welche Engine man sich entscheidet. Auch hier gibt es keine Universallösung, jede hat ihre Vor- und Nachteile, aber darauf will ich in diesem Eintrag nicht eingehen.

Da ich für das aktuell laufende Projekt nur InnoDB einsetze, beziehen sich die Ratschläge auf eine reine InnoDB Konfiguration und sollten ab MySQL Version 5.0 funktionieren.

“innodb_dirty_pages_pct”
Gibt an, wie viele  InnoDB-Buffer-Pages im RAM vorhanden sein dürfen, ohne auf Festplatte geschrieben worden zu sein. Standard ist 90%, was für die meisten Umgebungen absolut OK sein sollte.

“thread_cache_size”
Wie viele Threads dürfen sich im Cache befinden? Jede Verbindung zum Server braucht einen eigenen Thread, ist die Verbindung beendet, kann der Thread im Cache gelagert werden und steht der nächsten Verbindung zur Verfügung. Threads zu erstellen ist unnötiger Overhead, “SHOW GLOBAL STATUS” auf der MySQL Konsole gibt in der Variable “threads_created” aus, wie viele Threads erstellt werden. Dieser Wert sollte um maximal 10 pro Sekunde steigen, steigt er schneller, kann der Thread-cache vergrößert werden.

“table_definition_cache”
Sollte größer oder gleich der Anzahl der vorhandenen Tabellen sein um unnötigen I/O Overhead zu ersparen.

“innodb_open_files”
Sollte größer oder gleich der Anzahl der vorhandenen .ibd Dateien im MySQL-Datenverzeichnis sein (bei Debian meistens /var/lib/mysql).

“innodb_log_buffer_size”
Die globale Variable “innodb_os_log_written” hilft hier bei der Ermittlung eines sinnvollen Wertes, der Wert sollte nicht zu schnell steigen, hier kann I/O Performance gewonnen werden.

“skip_name_resolve”
Sollte aktiv sein, damit nicht für jeden Client 2 DNS-Lookups stattfinden, gleichzeitig bedeutet dies, dass Berechtigungen nur noch auf IP und nicht auf Hostnamen-Ebene verteilt werden können.

“innodb_flush_method”
Falls ein Hardware-Raid mit ordentlichem Cache und Battery-Backup genutzt wird, sollte hier 0_direct eingestellt werden, um zu verhindern, dass OS-Buffer genutzt werden, welche das Logfile unbrauchbar machen könnten, wenn der Server abstürzt.

“innodb_flush_log_at_trx”
Sollte auf 1 gestellt werden, damit jede beendete Transaktion sofort im Binarylog landet, um Datenverlust zu verhindern, falls der Server abstürzt. Der Wert 1 ist der beste Kompromiss zwischen Performance und Datensicherheit!

Diverse Key-Buffers und andere Caches (ausgenommen dem Query-Cache) können sehr klein gehalten werden (nicht abschalten, MySQL nutzt MyISAM für die Metatabellen). Hier würde nur sinnlos RAM belegt werden!

Auf Linux-Systemen sollte die swappiness noch auf 0 oder 1 gestellt werden, um zu verhindern, dass der Kernel MySQL Buffers in den SWAP-Space verschiebt, falls diese länger nicht genutzt werden. Swap-I/O ist weitaus schlimmer als normaler HDD-I/O, da MySQL “denkt” es würde mit schnellem RAM arbeiten, welcher in Wirklichkeit aber auf der HDD im Swap zu finden ist. Auf Debian-Systemen kann man diesen Wert mittels /etc/sysctl.conf setzen (vm.swappiness = 0) und danach “sysctl -p” ausführen.

Der restlich verfügbare Arbeitsspeicher sollte dem InnoDB-Buffer-Pool zur Verfügung gestellt werden, ist dieser groß genug, kann auf nahezu alle HDD-Leseabfragen verzichtet werden und es entsteht nahezu nur noch Schreib-I/O.

Es gibt noch weitere Einstellungen bezüglich des InnoDB-Tablespace und allgemeinen Einstellungen, falls hier noch Intresse besteht, hinterlasst nen Kommentar, werde dann versuchen zeitnah einen weiteren Beitrag zu schreiben.

Auf der Karte sind alle Toplevel Domains verzeichnet, macht sich im Büro bestimmt nicht schlecht.

Hier übrigens der Link zur Aktion. Gleichzeitig kann man seinen eigenen Blog noch ein wenig pushen:

Wenn Sie die Domain-Weltkarte dann von uns per Post erhalten haben (dauert etwa 1 bis 2 Wochen), machen Sie ein Foto von sich und der Wand in Ihrem Büro/Wohnung, an der die Domain-Weltkarte ihren Platz gefunden hat und veröffentlichen das ganze wieder in Ihrem Blog als kleinen Beitrag.

Schicken Sie den Link zu diesem Beitrag wieder an aktion@united-domains.de. Im April werden wird dann auf unserer Website alle Links zu diesen Beiträgen/Fotos veröffentlichen und auch im Newsletter wieder darüber berichten …. Sie haben so also die Möglichkeit, etwas Werbung für Ihren eigenen Blog zu machen und weitere Besucher zu bekommen.

Nach langem hin und her und viel Recherche habe ich mir aus diversen Codefragmenten das hier zusammengebaut und es scheint zu funktionieren:

	function price2float($string){
	    $string = trim($string);
		if(preg_match('/([0-9\.,-]+)/', $string, $matches)){
			// Zahl gefunden also können wir weitermachen
			$string = $matches[0];

			if(preg_match('/^[0-9.-\s]*[\,]{1}[0-9-]{0,2}$/', $string)){
				// Komma als Dezimal Separator
				// Alle Punkte entfernen und anschließend das Komma in einen Punkt umwandeln
				$string = str_replace(' ', '', $string);
				$string = str_replace('.', '', $string);
				$string = str_replace(',', '.', $string);
				return floatval($string);
			}
			elseif(preg_match('/^[0-9,-\s]*[\.]{1}[0-9-]{0,2}$/', $string)){
				// Punkt als Dezimal Separator
				// Alle Kommata entfernen
				$string = str_replace(' ', '', $string);
				$string = str_replace(',', '', $string);
				return floatval($string);
			}
			elseif(preg_match('/^[0-9.-\s]*[\.]{1}[0-9-]{0,3}$/', $string)){
				// Es gibt nur Tausender Separatoren
				// Alle Punkte enfernen
				$string = str_replace(' ', '', $string);
				$string = str_replace('.', '', $string);
				return floatval($string);
			}
			elseif(preg_match('/^[0-9,-\s]*[\,]{1}[0-9-]{0,3}$/', $string)){
				// Es gibt nur Tausender Separatoren
				// Alle Kommata enfernen
				$string = str_replace(' ', '', $string);
				$string = str_replace(',', '', $string);
				return floatval($string);
			}
			else{
				return floatval($string);
			}
		}
		else{
			return 0;
		}
	}

Beispiele zum selbsttesten:
1234.456,78 => 123456.78
1234,456.78 => 123456.78
12.34 => 12.34
12,34 => 12.34
123.456.789 => 123456789
123,456,789 => 123456789

wie immer bin ich für Verbesserungsvorschläge offen!