<?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>Comments on: Benchmarking PHP: eAccelerator und andere OpCode Caches</title>
	<atom:link href="http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/</link>
	<description>Interdose Ltd. &#38; Co KG.</description>
	<lastBuildDate>Mon, 01 Feb 2010 23:59:32 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mike</title>
		<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/comment-page-1/#comment-1263</link>
		<dc:creator>Mike</dc:creator>
		<pubDate>Thu, 10 Dec 2009 08:37:25 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.interdose.com/dominik/?p=22#comment-1263</guid>
		<description>Schöne Übersicht. Ich habe auch lange eAccelerator verwendet, bin aber jetzt auf APC umgestiegen. Das liegt hauptsächlich daran, dass APC bald in die PHP-Installation integriert ist und somit kein zusätzlicher Kompilieraufwand anfällt.

Die Unterschiede zwischen eAccelerator und APC sind zu gering als dass sich der Zusatzaufwand lohnen würde.</description>
		<content:encoded><![CDATA[<p>Schöne Übersicht. Ich habe auch lange eAccelerator verwendet, bin aber jetzt auf APC umgestiegen. Das liegt hauptsächlich daran, dass APC bald in die PHP-Installation integriert ist und somit kein zusätzlicher Kompilieraufwand anfällt.</p>
<p>Die Unterschiede zwischen eAccelerator und APC sind zu gering als dass sich der Zusatzaufwand lohnen würde.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Apache2 + xCache &#124; blog.i7x.de</title>
		<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/comment-page-1/#comment-1262</link>
		<dc:creator>Apache2 + xCache &#124; blog.i7x.de</dc:creator>
		<pubDate>Fri, 30 Oct 2009 19:20:04 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.interdose.com/dominik/?p=22#comment-1262</guid>
		<description>[...] Mit einfachen mitteln kann man seine Seite optimieren und um einiges Beschleunigen. Einen ausführlichen Benchmark Test findet ihr unteranderem hier. [...]</description>
		<content:encoded><![CDATA[<p>[...] Mit einfachen mitteln kann man seine Seite optimieren und um einiges Beschleunigen. Einen ausführlichen Benchmark Test findet ihr unteranderem hier. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael</title>
		<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/comment-page-1/#comment-321</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Tue, 07 Oct 2008 21:07:47 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.interdose.com/dominik/?p=22#comment-321</guid>
		<description>Hi,

wir nutzen auch den eAccelerator, auf 18 Webservern, welche Codeänderungen via svn update auschecken.
Lighttpd 1.4.19 + PHP5.2.6 + neusten eacc

Sobald sich das System unter mittlerer Last befindet und eine große Datei verändert wird (9000 Zeilen PHP Code), steigt die Last plötzlich ins unermessliche. Solange bis ich alle lightys neustarte. 

Gleicher Versuch mit xCache, hier war die Grundlast schon um einiges Höher, weswegen wir noch vor der Peaktime zurück zu eacc sind.

Ne Idee wie ich diese Loadsteigerungen verhindern kann, ohne jedesmal ein Skript zu starten, dass alle lightys durchstartet?</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>wir nutzen auch den eAccelerator, auf 18 Webservern, welche Codeänderungen via svn update auschecken.<br />
Lighttpd 1.4.19 + PHP5.2.6 + neusten eacc</p>
<p>Sobald sich das System unter mittlerer Last befindet und eine große Datei verändert wird (9000 Zeilen PHP Code), steigt die Last plötzlich ins unermessliche. Solange bis ich alle lightys neustarte. </p>
<p>Gleicher Versuch mit xCache, hier war die Grundlast schon um einiges Höher, weswegen wir noch vor der Peaktime zurück zu eacc sind.</p>
<p>Ne Idee wie ich diese Loadsteigerungen verhindern kann, ohne jedesmal ein Skript zu starten, dass alle lightys durchstartet?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dominik Deobald</title>
		<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/comment-page-1/#comment-320</link>
		<dc:creator>Dominik Deobald</dc:creator>
		<pubDate>Sun, 28 Sep 2008 13:03:21 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.interdose.com/dominik/?p=22#comment-320</guid>
		<description>Die machen (tendenziell) das gleiche, natürlich mit kleinen Implementierungsunterschieden. Der Geschwindigkeitsgewinn, den eAccelerator und X-Cache bringen kommt aber primär vom Caching. Der Optimizer hat denke ich daran nur relativ wenig Einfluss. Ich habe allerdings nicht getestet, was der Geschwindigkeitsunterschied zwischen eAccelerator mit und eAccelerator ohne (internem) Optimizer ist. Bin einfach mal davon ausgegangen, dass der Optimizer an der Stelle einfach die bessere Variante ist.</description>
		<content:encoded><![CDATA[<p>Die machen (tendenziell) das gleiche, natürlich mit kleinen Implementierungsunterschieden. Der Geschwindigkeitsgewinn, den eAccelerator und X-Cache bringen kommt aber primär vom Caching. Der Optimizer hat denke ich daran nur relativ wenig Einfluss. Ich habe allerdings nicht getestet, was der Geschwindigkeitsunterschied zwischen eAccelerator mit und eAccelerator ohne (internem) Optimizer ist. Bin einfach mal davon ausgegangen, dass der Optimizer an der Stelle einfach die bessere Variante ist.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin</title>
		<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/comment-page-1/#comment-319</link>
		<dc:creator>Martin</dc:creator>
		<pubDate>Sun, 21 Sep 2008 15:29:59 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.interdose.com/dominik/?p=22#comment-319</guid>
		<description>Was ist der Unterschied zwischen den in eaccelerator und x-cache implementierten optimizern und dem von Zend. Machen die nicht das selbe?</description>
		<content:encoded><![CDATA[<p>Was ist der Unterschied zwischen den in eaccelerator und x-cache implementierten optimizern und dem von Zend. Machen die nicht das selbe?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: It&#8217;s all in a day&#8217;s work &#187; Blog Archive &#187; PHP Acceleration with eAccelerator</title>
		<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/comment-page-1/#comment-296</link>
		<dc:creator>It&#8217;s all in a day&#8217;s work &#187; Blog Archive &#187; PHP Acceleration with eAccelerator</dc:creator>
		<pubDate>Wed, 07 May 2008 22:29:14 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.interdose.com/dominik/?p=22#comment-296</guid>
		<description>[...] Some benchmarks of opcode caches [...]</description>
		<content:encoded><![CDATA[<p>[...] Some benchmarks of opcode caches [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sBani Web Development</title>
		<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/comment-page-1/#comment-295</link>
		<dc:creator>sBani Web Development</dc:creator>
		<pubDate>Sun, 04 May 2008 11:31:21 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.interdose.com/dominik/?p=22#comment-295</guid>
		<description>&lt;strong&gt;eAccelerator auf Debian...&lt;/strong&gt;

Da ich ein richtiger Nimmersatt bin, möchte ich natürlich auch jetzt wieder mein PHP etwas verbessern.
Zürst hat sich mir allerdings folgende Frage gestellt:
Warum eAccelerator und nicht Zend Optimizer?
Es waren einige Benchmark-Tests, die mich dazu...</description>
		<content:encoded><![CDATA[<p><strong>eAccelerator auf Debian&#8230;</strong></p>
<p>Da ich ein richtiger Nimmersatt bin, möchte ich natürlich auch jetzt wieder mein PHP etwas verbessern.<br />
Zürst hat sich mir allerdings folgende Frage gestellt:<br />
Warum eAccelerator und nicht Zend Optimizer?<br />
Es waren einige Benchmark-Tests, die mich dazu&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dominik Deobald</title>
		<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/comment-page-1/#comment-294</link>
		<dc:creator>Dominik Deobald</dc:creator>
		<pubDate>Fri, 02 May 2008 08:56:03 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.interdose.com/dominik/?p=22#comment-294</guid>
		<description>@trickster:
Der Zeitraum ist irrelevant, weil es sich um ein reines Testsystem handelt, das sonst keine Last hat. Und da meines Wissens nach Server nicht je nach Tageszeit Wach- und Schlafphasen haben verhalten sie sich den ganzen Tag identisch.

Gleiches gilt für die Streuwerte: Der Server hat nur diese eine Aufgabe erledigt, die ich ihm gegeben habe - jeweils 10.000 mal das gleiche Script aufrufen. Somit war auch der &quot;Streufaktor&quot; irrelevant. Bei einer gleichmäßigen Belastung von 20 identischen Prozessen gab es hier nicht viel Variabilität.

Bei meinen Benchmarks ging es nicht darum, den &quot;realistischen Betrieb&quot; zu simulieren. Mir ging es rein um den direkten Vergleich der verschiedenen Optimierungs AddOns in unterschiedlichen Szenarien.

Vielleicht anzumerken sei, dass der Server damit an der Lastgrenze war - wenn man also 20.000 Requests statt 10.000 Requests abgefeuert hat, dann hat das doppelt so lang gedauert.</description>
		<content:encoded><![CDATA[<p>@trickster:<br />
Der Zeitraum ist irrelevant, weil es sich um ein reines Testsystem handelt, das sonst keine Last hat. Und da meines Wissens nach Server nicht je nach Tageszeit Wach- und Schlafphasen haben verhalten sie sich den ganzen Tag identisch.</p>
<p>Gleiches gilt für die Streuwerte: Der Server hat nur diese eine Aufgabe erledigt, die ich ihm gegeben habe &#8211; jeweils 10.000 mal das gleiche Script aufrufen. Somit war auch der &#8220;Streufaktor&#8221; irrelevant. Bei einer gleichmäßigen Belastung von 20 identischen Prozessen gab es hier nicht viel Variabilität.</p>
<p>Bei meinen Benchmarks ging es nicht darum, den &#8220;realistischen Betrieb&#8221; zu simulieren. Mir ging es rein um den direkten Vergleich der verschiedenen Optimierungs AddOns in unterschiedlichen Szenarien.</p>
<p>Vielleicht anzumerken sei, dass der Server damit an der Lastgrenze war &#8211; wenn man also 20.000 Requests statt 10.000 Requests abgefeuert hat, dann hat das doppelt so lang gedauert.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: trickster</title>
		<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/comment-page-1/#comment-293</link>
		<dc:creator>trickster</dc:creator>
		<pubDate>Thu, 01 May 2008 21:53:12 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.interdose.com/dominik/?p=22#comment-293</guid>
		<description>die Streudarstellung waere sinnvoll. Nur Mittelwerte sind etwas kritisch. Zeitraum des jeweiligen testes (Tageszeit??)
Überlagerte Zugriffszeitdiagramme würden helfen die Statistik zuordnen zu können.</description>
		<content:encoded><![CDATA[<p>die Streudarstellung waere sinnvoll. Nur Mittelwerte sind etwas kritisch. Zeitraum des jeweiligen testes (Tageszeit??)<br />
Überlagerte Zugriffszeitdiagramme würden helfen die Statistik zuordnen zu können.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: eAccelerator auf Debian installieren &#124; Sufijen's Web Developer Blog</title>
		<link>http://blogs.interdose.com/dominik/2008/04/11/benchmarking-php-eaccelerator-und-andere-opcode-caches/comment-page-1/#comment-291</link>
		<dc:creator>eAccelerator auf Debian installieren &#124; Sufijen's Web Developer Blog</dc:creator>
		<pubDate>Sat, 26 Apr 2008 12:12:01 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.interdose.com/dominik/?p=22#comment-291</guid>
		<description>Empfehlenswerter Link zu dem Thema: Dominik Deobald</description>
		<content:encoded><![CDATA[<p>Empfehlenswerter Link zu dem Thema: Dominik Deobald</p>
]]></content:encoded>
	</item>
</channel>
</rss>
