<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Kommentare zu: PHP Prozessor optimiert kompilieren &#8211; ein Performance Vorteil oder Mythos ?</title>
	<atom:link href="http://www.phphatesme.com/blog/allgemein/php-prozessor-optimiert-kompilieren-ein-performance-vorteil-oder-mythos/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.phphatesme.com/blog/allgemein/php-prozessor-optimiert-kompilieren-ein-performance-vorteil-oder-mythos/</link>
	<description>PhpHatesMe, but that&#039;s ok!</description>
	<lastBuildDate>Mon, 06 Feb 2012 20:59:49 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Von: Axel</title>
		<link>http://www.phphatesme.com/blog/allgemein/php-prozessor-optimiert-kompilieren-ein-performance-vorteil-oder-mythos/comment-page-1/#comment-277</link>
		<dc:creator>Axel</dc:creator>
		<pubDate>Mon, 17 Nov 2008 18:52:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.phphatesme.com/?p=1020#comment-277</guid>
		<description>Hi Johannes,

ich gebe dir Recht, im &quot;Real Life&quot; spielen viele andere Faktoren eine viel größere Rolle als das PHP Binary. Wie schon erwähnt anständige SQL Statments, oder einen Apache anständig als &quot;mpm worker&quot; konfiguriert ;)

Ich habe absichtlich die Debian Distri gewählt, da ich dort den &quot;krassesten&quot; Unterschied verzeichnen konnte :D

gruss axel</description>
		<content:encoded><![CDATA[<p>Hi Johannes,</p>
<p>ich gebe dir Recht, im &#8220;Real Life&#8221; spielen viele andere Faktoren eine viel größere Rolle als das PHP Binary. Wie schon erwähnt anständige SQL Statments, oder einen Apache anständig als &#8220;mpm worker&#8221; konfiguriert <img src='http://www.phphatesme.com/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
<p>Ich habe absichtlich die Debian Distri gewählt, da ich dort den &#8220;krassesten&#8221; Unterschied verzeichnen konnte <img src='http://www.phphatesme.com/wp-includes/images/smilies/icon_biggrin.gif' alt=':D' class='wp-smiley' /> </p>
<p>gruss axel</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Johannes</title>
		<link>http://www.phphatesme.com/blog/allgemein/php-prozessor-optimiert-kompilieren-ein-performance-vorteil-oder-mythos/comment-page-1/#comment-276</link>
		<dc:creator>Johannes</dc:creator>
		<pubDate>Mon, 17 Nov 2008 17:58:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.phphatesme.com/?p=1020#comment-276</guid>
		<description>Ein paar Dinge sind dabei zu berücksichtigen:

a) Manche Distributoren sind schlauer als andere und verwenden bessere Optimierungen, Dinge die Otto-Normal-Anwender nicht kennt. Dadurch kann es schneller sein. Gibt aber auch Distributoren, die PHP blöd finden und das nur irgendwie kompilieren ;-)

b) Manche Distributoren patchen PHP, teils backporting von Security Dingen, teils Suhoshin patch, teils eigene &quot;kreative&quot; Dinge, hat definitv auswirkungen in die eine oder andere Richtungen

c) bench.php is ein Engine-Benchmark, das für Engine-Entwickler gedacht ist um bestimmte Kernteile der Engine zu testen und dort Regressionen zu entdecken. Es hat nichts mit real-life zu tun. Es nutzt z.B. keinen extension Code (also für die einzelnen tests, für sowas wie time() schon, aber das is zu ignorieren) nun wollen Distributoren flexibel sein machen also aus allen Extensions eigene packages die dann per php.ini geladen werden. Dies hat &quot;massive&quot; Kosten beim Start, was insbesondere bei CGI (ok, wer CGI nutzt will keine Performance (FastCGI ist _nicht_ gemeint)) Auswirkungen hat und _kann_ auch Auswirkungen auf PHP-Performance zur Laufzeit haben.

d) Die PHP Performance hängt nicht nur an PHP selber sondern auch an allen libs die genutzt werden, da wird evtl. auch naders kompiliert

e) Neben der single-prozess-Geschwindigkeit muss man auch Dinge wie z.B. Speicherverbrauch ansehen - wenn ein Kompilat deutlich mehr Speicher verbraucht bekomme ich davon weniger auf eine Ksite -&gt; geringere Performance

f) Die Unterschiede sind, in einem realen System, wo 80% der Zeit mit warten auf Datenbank und sonstige Netzwerkoperationen (Daten an Client z.B.) verbracht werden am Ende nicht messbar, wohingegen einfache Administration und regelmäßige &quot;automatische&quot; Sicherheitsupdates messbar sind.

g) Oh und das Thema Support - Firmen wie Zend, RedHat und Sun bieten kommerziellen Support für ihre Builds - wenn man also jemanden zur Hand haben will wenn es kracht kann das auch was Wert sein</description>
		<content:encoded><![CDATA[<p>Ein paar Dinge sind dabei zu berücksichtigen:</p>
<p>a) Manche Distributoren sind schlauer als andere und verwenden bessere Optimierungen, Dinge die Otto-Normal-Anwender nicht kennt. Dadurch kann es schneller sein. Gibt aber auch Distributoren, die PHP blöd finden und das nur irgendwie kompilieren <img src='http://www.phphatesme.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>b) Manche Distributoren patchen PHP, teils backporting von Security Dingen, teils Suhoshin patch, teils eigene &#8220;kreative&#8221; Dinge, hat definitv auswirkungen in die eine oder andere Richtungen</p>
<p>c) bench.php is ein Engine-Benchmark, das für Engine-Entwickler gedacht ist um bestimmte Kernteile der Engine zu testen und dort Regressionen zu entdecken. Es hat nichts mit real-life zu tun. Es nutzt z.B. keinen extension Code (also für die einzelnen tests, für sowas wie time() schon, aber das is zu ignorieren) nun wollen Distributoren flexibel sein machen also aus allen Extensions eigene packages die dann per php.ini geladen werden. Dies hat &#8220;massive&#8221; Kosten beim Start, was insbesondere bei CGI (ok, wer CGI nutzt will keine Performance (FastCGI ist _nicht_ gemeint)) Auswirkungen hat und _kann_ auch Auswirkungen auf PHP-Performance zur Laufzeit haben.</p>
<p>d) Die PHP Performance hängt nicht nur an PHP selber sondern auch an allen libs die genutzt werden, da wird evtl. auch naders kompiliert</p>
<p>e) Neben der single-prozess-Geschwindigkeit muss man auch Dinge wie z.B. Speicherverbrauch ansehen &#8211; wenn ein Kompilat deutlich mehr Speicher verbraucht bekomme ich davon weniger auf eine Ksite -&gt; geringere Performance</p>
<p>f) Die Unterschiede sind, in einem realen System, wo 80% der Zeit mit warten auf Datenbank und sonstige Netzwerkoperationen (Daten an Client z.B.) verbracht werden am Ende nicht messbar, wohingegen einfache Administration und regelmäßige &#8220;automatische&#8221; Sicherheitsupdates messbar sind.</p>
<p>g) Oh und das Thema Support &#8211; Firmen wie Zend, RedHat und Sun bieten kommerziellen Support für ihre Builds &#8211; wenn man also jemanden zur Hand haben will wenn es kracht kann das auch was Wert sein</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Nils Langner</title>
		<link>http://www.phphatesme.com/blog/allgemein/php-prozessor-optimiert-kompilieren-ein-performance-vorteil-oder-mythos/comment-page-1/#comment-259</link>
		<dc:creator>Nils Langner</dc:creator>
		<pubDate>Mon, 17 Nov 2008 12:00:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.phphatesme.com/?p=1020#comment-259</guid>
		<description>Sind auf jeden Fall beeindruckende Zahlen. Hätte nie gedacht, dass hier wirklich ein Faktor von 1,4 rauszuholen ist. Nur leider ist das Problem, dass man nicht immer Herr des eigenen Servers ist und man nicht die Wahl hat.</description>
		<content:encoded><![CDATA[<p>Sind auf jeden Fall beeindruckende Zahlen. Hätte nie gedacht, dass hier wirklich ein Faktor von 1,4 rauszuholen ist. Nur leider ist das Problem, dass man nicht immer Herr des eigenen Servers ist und man nicht die Wahl hat.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

