Code Styling Project

WordPress Sprachdateiverarbeitung Betatest - erste Analysen

codestyling | 25. Juli 2009 | 12:42

Nachdem nun eine Menge Rückmeldungen eingegangen sind, habe ich ein paar Auswertungen vorgenommen. Die komplette Analyse folgt noch, denn ich hoffe noch auf weitere Meldungen. Dennoch zeigen sie 3 Sachen deutlich:

auf vielen Systemen gibt es eine Verbesserung
auf 64Bit Systemen gibt es Probleme
PHP 4 Support ist notwendig und gewünscht

Ich hab noch Forschungen in Richtung PHP Bugs betrieben und dort interessante Dinge entdeckt.

PHP 4 Support

Ich habe bereits Schnurpsel zum Test eine an PHP 4 angepasste Variante geschickt, bei positivem Testergebnis wird diese als nächstes verfügbar gemacht. Damit sollte es auch unter PHP 4 laufen.

Probleme mit 64bit Versionen

Die Probleme scheinen auf Systemen aufzutreten, auf denen PHP in 64bit läuft und dessen Version kleiner ist als 5.2.10, zumindest nach den Testdaten. Ich habe mich also auf die Suche begeben, ob der Bug Trac von PHP dazu etwas hergibt. Hier die Liste der für 64bit Systeme relevanten Bugs, die gefixt wurden:

ID	Version	Titel	Details
47564	5.2.10	unpacking unsigned long 32bit bit endian returns wrong result	Bugfix
47365	5.2.10	ip2long: 32bit vs. 64bit	Bugfix
45877	5.2.10	Array key ‘2147483647′ left as string	Bugfix
47422	5.2.9	modulus operator returns incorrect results on 64 bit linux	Bugfix
44209	5.2.6	strtotime doesn’t support 64 bit timestamps	Bugfix
42512	5.2.5	ip2long(’255.255.255.255′) should return 4294967295 on 64-bit PHP	Bugfix
41765	5.2.4	Recode crashes/does not work on amd64	Bugfix
38770	5.2.1	pack/unpack is broken on 64bit	Bugfix

Die angegebene PHP Version ist diejenige, in welcher der Fehler laut Changelog von PHP behoben wurde.
Da die Pack/Unpack sowie Integer Probleme direkt beim Verwenden von Sprachdateien zum Tragen kommen, würde ich davon ausgehen, das die beobachteten Phänomene auf 64bit Systemen (Sprachdateien werden nicht mehr geladen) in direktem Zusammenhang mit einem oder mehreren dieser Bugs steht. Dies werde ich noch eingehender untersuchen, denn die Sprachdateiverarbeitung beruht stark auf den o.g. Funktionen.

grundsätzliche Probleme im Umgang mit Speicher

Auch hier ist es nicht nur allein die “Schuld” von WordPress, Speicher zu verschwenden (auch wenn man sicher einiges effizienter programmieren könnte) sondern PHP selbst trägt auch je nach Version gehörig dazu bei, das der Speicher knapp wird. Auch hier erstmal eine Liste der Probleme, die ich ausgegraben hab:

ID	Version	Titel	Details
48643	5.3.0	String functions memory issue (was:Memory not freed with FilterIterator)	Bugfix
47038	5.3.0	Memory leak in include()	Bugfix
46711	5.3.0	cUrl leaks memory	Bugfix
46115	5.3.0	Memory leak when calling a method using Reflection	Bugfix
45392	5.2.7 (scheinbar noch offen)	ob_start()/ob_end_clean() and memory_limit	Bugfix
42663	5.2.10	gzinflate() try to allocate all memory with truncated $data	Bugfix
46889	5.2.9	Memory leak in strtotime()	Bugfix
44798	5.2.7	Memory leak assigning value to attribute (Fixed in PHP_5_3 branch!)	Bugfix
44069	5.2.6	Huge memory usage with concatenation using . instead of .=	Bugfix
42818	5.2.5	$foo = clone(array()); leaks memory	Bugfix
41713	5.2.4	Persistent memory consumption since 5.2	Bugfix
37864	5.2.0	file_get_contents leaks memory on empty file	Bugfix

Die meisten hier aufgezählten Bugs haben direkt mit der Verarbeitung von Daten in WordPress zu tun. Mit 2.8 wurden ja teilweise PHP 5 Funktionalitäten eingebaut wie Reflections für die Feeds (deshalb ist das Dashboard u.a. so hungrig). Auch gzinflate zum Packen von Scripten oder CSS gibt es ja jetzt neu, auch das ist also relevant. Da curl nun der Standard für den Transport im Backend ist (Feeds lesen, Updates holen etc), ist auch der beteiligt. Und das Beste ist der Bug 44069 in PHP 5.2.6 erst gefixt. Den sollte ich näher erläutern.

PHP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
 
$string = str_repeat('This is a teststring.', 50);
 
echo 'Length: '.strlen($string).'<br>';
echo 'Memory Before:'.memory_get_usage(true).'<br>';
 
for($i = 1; $i <= 2000; $i++)
{
//	$newstring .= $string; //This uses an expected amount of mem.
	$newstring = $newstring . $string; //This uses very much mem.
 
	for($j = 1; $j <= 10; $j++)
	{
		$array[] = 'test';
	}
}
echo 'Memory After:'.memory_get_usage(true).'<br>';
echo 'Total Length of String: '.strlen($newstring).'<br>';
 
?>
timing: 0.032s

PHP
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	<?php $string = str_repeat('This is a teststring.', 50); echo 'Length: '.strlen($string).'<br>'; echo 'Memory Before:'.memory_get_usage(true).'<br>'; for($i = 1; $i <= 2000; $i++) { // $newstring .= $string; //This uses an expected amount of mem. $newstring = $newstring . $string; //This uses very much mem. for($j = 1; $j <= 10; $j++) { $array[] = 'test'; } } echo 'Memory After:'.memory_get_usage(true).'<br>'; echo 'Total Length of String: '.strlen($newstring).'<br>'; ?>
timing: 0.032s

Erwartetes Ergebnis:

Length: 1050
Before:262144
After:4456448
Length: 2100000

Aktuelles Ergebnis:

Length: 1050
Before:262144
After:161742848
Length: 2100000

Erster Kommentar eines PHP Entwickler zu einem anderen:

Dmitry, can you check this out please? The example script kills my
machine totally if I don’t use the .=

Um es nochmal klar zu formulieren:

erwarteter Speicherverbrauch: 4456448 Bytes = 4,25MB
tatsächlicher Speicherverbrauch: 161742848 = 154,25 MB !

Das o.g. Script macht nichts anderes, als die meisten WordPress Templates, Plugins oder der Core: Texte verketten und zwischendurch ein paar Aktionen mit Arrays veranstalten, also ganz normale Sachen, wie man sie in PHP Scripten zu Hunderten finden kann.
Das dabei die Maschine förmlich platzen kann, war mir so nicht klar. Zumal hier offensichtlich die Speicherveraltung von PHP einen deutlichen Knacks weg hatte. Ab der PHP Version 5.2.6 sollte dies behoben sein, es würde u.a. auch erklären, warum einige Server sehr viel mehr Speicher brauchen als andere mit den gleichen Plugins/Themes.

Soviel erstmal von der Analysefront, ich bin weiter an dem Thema dran, um das mal in brauchbare Bahnen zu bekommen. Bitte nicht ungeduldig werden, wenn ich nicht gleich Kommentare freigebe, bin auch mal auf einer Feier …
Und das Thema subscribe to comments ist in Planung, nur kollidiert es im Moment mit meinem Multi-Lingual Theme und der Kommentarbehandlung, wie sie mein Blog derzeit vornimmt. Wird aber demnächst möglich sein.

Update: Eine neue Version (v2) der Sprachdatei Speicherminimierung steht zum Download bereit, die Historie kann man jetzt vor dem Download mitlesen.