PHP Performance
PHP Performance
Hat jemand einen Link wie stark die Performance sich ändert wenn PHP als suPHP, mod_fastCGI bzw. als mod_php verwendet wird?
Mir ist klar, das suPHP am langsamsten ist und mod_php am schnellsten. Allerdings würde mich eben interessieren, inwieweit sich das ganze nun wirklich bemerkbar macht.
Mir ist klar, das suPHP am langsamsten ist und mod_php am schnellsten. Allerdings würde mich eben interessieren, inwieweit sich das ganze nun wirklich bemerkbar macht.
-
bananenbieger
- Posts: 6
- Joined: 2005-12-22 01:42
Re: PHP Performance
Ich würde mal sagen: Kommt drauf an.
Einer unserer Server in den USA hat Apache und CGI-PHP und ist genau so schnell wie sein deutsches Ã?quivalent mit MOD_PHP - Und das, obwohl die Systeme fast identisch sind. Fast, weil sich die Apache und PHP-Versionen leicht unterscheiden.
Da hilft wohl nur selber testen.
Einer unserer Server in den USA hat Apache und CGI-PHP und ist genau so schnell wie sein deutsches Ã?quivalent mit MOD_PHP - Und das, obwohl die Systeme fast identisch sind. Fast, weil sich die Apache und PHP-Versionen leicht unterscheiden.
Da hilft wohl nur selber testen.
-
lord_pinhead
- Posts: 774
- Joined: 2004-04-26 15:57
Re: PHP Performance
Auf einen Rootie wo ich betreute war PHP als CGI und FastCGI am laufen, ich hab kein Unterschied gemerkt und die auslieferung der Daten war auch sehr flott, also gemerkt habe ich nichts muss ich sagen.
Re: PHP Performance
dann werd ich mal am WE auf ner Testmaschine das ganze ein wenig testen. Gibts da evtl. schon tools oder fertige Pakete?
Ansonsten würde ich einfach ein PHP Skript schreiben, das die Zeit zum ausführen in ner DB oder .txt Datei schreibt.
Ansonsten würde ich einfach ein PHP Skript schreiben, das die Zeit zum ausführen in ner DB oder .txt Datei schreibt.
-
bananenbieger
- Posts: 6
- Joined: 2005-12-22 01:42
Re: PHP Performance
Am Besten, Du nimmst das Skript, das Du auch nachher einsetzen willst. Generell ist ein etwaiger Perfomanceeinbruch auch stark abhängig vom eingesetzten PHP-Skript.
Falls Du kein Benchmark-Skript hast, versuch doch einfach mal eZ Publish (http://ez.no) und dessen Debug-Modus (gibt detailliert Skript- und SQL-Laufzeiten an). Beliebige andere Programme mit ähnlichen Debug-Optionen sind natürlich auch geeignet.
Falls Du kein Benchmark-Skript hast, versuch doch einfach mal eZ Publish (http://ez.no) und dessen Debug-Modus (gibt detailliert Skript- und SQL-Laufzeiten an). Beliebige andere Programme mit ähnlichen Debug-Optionen sind natürlich auch geeignet.
Re: PHP Performance
danke, werd ich mir heut Abend mal genauer anschauen. :)
Eigentlich müsste der apachebenchmark2 doch hierfür auch geeignet sein?
Eigentlich müsste der apachebenchmark2 doch hierfür auch geeignet sein?
-
bananenbieger
- Posts: 6
- Joined: 2005-12-22 01:42
Re: PHP Performance
Alles, was irgendwie die Zeit messen kann, ist geeignet.
Benchmarks sind aber für die Katz. Was wirklich zählt, ist Echt-Performance. Deshalb immer möglichst realitätsnah (also mit den tatsächlich eingesetzten Anwendungen) die Geschwindigkeit testen.
Benchmarks sind aber für die Katz. Was wirklich zählt, ist Echt-Performance. Deshalb immer möglichst realitätsnah (also mit den tatsächlich eingesetzten Anwendungen) die Geschwindigkeit testen.
Re: PHP Performance
Das das Quatsch ist, ist ja wohl offensichtlich.Bananenbieger wrote:Alles, was irgendwie die Zeit messen kann, ist geeignet.
Eben so kann man eben nicht die Unterschiede zwischen mod_php, php-cgi oder php als FastCGI rausfinden. Was zählt ist die Verzögerung und die Downloadrate bei Auslieferung. Nicht nur die Skriptlaufzeit. Das ist nur ein Teil des Gesamtpakets.
Denn, was bringt es mir, wenn ein Script in wenigen Millisekunden abläuft, der Interpret aber erstmal Sekunden zum laden braucht?
Die Anwendung selbst testen lassen, macht vielleicht Sinn um die Anwendung zu optimieren, z.B. um full joins zu eleminieren. Aber nicht um die Umgebung zu testen.
-
bananenbieger
- Posts: 6
- Joined: 2005-12-22 01:42
Re: PHP Performance
Stimmt, SO kann man die Frage auch verstehen... Sorry, als PHP-Entwickler verstehe ich "PHP Performance" als Geschwindigkeit, die der PHP Interpreter braucht, um ein Skript abzuarbeiten.øxygen wrote:Das das Quatsch ist, ist ja wohl offensichtlich.
Eben so kann man eben nicht die Unterschiede zwischen mod_php, php-cgi oder php als FastCGI rausfinden. Was zählt ist die Verzögerung und die Downloadrate bei Auslieferung. Nicht nur die Skriptlaufzeit. Das ist nur ein Teil des Gesamtpakets.
Re: PHP Performance
hab jetzt mal den ab2 verwendet:
suPHP-Version
mod Version
Irgendwie schon ein Unterschied :(
suPHP-Version
Code: Select all
Document Path: /test.php
Document Length: 50000 bytes
Concurrency Level: 1
Time taken for tests: 150.653844 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 50269000 bytes
HTML transferred: 50000000 bytes
Requests per second: 6.64 [#/sec] (mean)
Time per request: 150.654 [ms] (mean)
Time per request: 150.654 [ms] (mean, across all concurrent requests)
Transfer rate: 325.85 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 84 150 42.9 141 368
Waiting: 0 44 7.6 45 85
Total: 84 150 42.9 141 368
Percentage of the requests served within a certain time (ms)
50% 141
66% 155
75% 166
80% 177
90% 208
95% 239
98% 278
99% 294
100% 368 (longest request)
Code: Select all
Document Path: /test.php4
Document Length: 50000 bytes
Concurrency Level: 1
Time taken for tests: 20.147294 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 50280000 bytes
HTML transferred: 50000000 bytes
Requests per second: 49.63 [#/sec] (mean)
Time per request: 20.147 [ms] (mean)
Time per request: 20.147 [ms] (mean, across all concurrent requests)
Transfer rate: 2437.10 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 17 19 1.2 19 47
Waiting: 0 2 3.1 3 45
Total: 17 19 1.2 19 47
Percentage of the requests served within a certain time (ms)
50% 19
66% 20
75% 20
80% 20
90% 20
95% 21
98% 21
99% 21
100% 47 (longest request)
-
Roger Wilco
- Posts: 5923
- Joined: 2004-05-23 12:53
Re: PHP Performance
Klar, SuPHP lädt bei jedem Request den PHP-Interpreter neu, während er bei mod_php schon mit dem Apache geladen wurde. Richtig interessant wird es aber erst, wenn du mal das Concurrency Level erhöhst...chaosad wrote:Irgendwie schon ein Unterschied :(
Re: PHP Performance
Das wusste ich auch schon, nur war mir nicht bewusst das der Unterschied so gewaltig ist.
Dann werd ich mal versuchen das ganze als cgi und suexec bzw. cgiwrap zum laufen zu kriegen. Für suexec gibts ja ein nettes Howto auf http://debianhowto.de Ã?ber cgiwrap bin ich eben grad mehr so gestolpert.
Dann werd ich mal versuchen das ganze als cgi und suexec bzw. cgiwrap zum laufen zu kriegen. Für suexec gibts ja ein nettes Howto auf http://debianhowto.de Ã?ber cgiwrap bin ich eben grad mehr so gestolpert.
Re: PHP Performance
Naja, PHP als CGI oder mit suPHP nimmt sich von der Performance nicht viel. Wenn das ganze schnell und sicher sein soll, kommt eigentlich nur FastCGI in frage.
Re: PHP Performance
Und passender VM (PHP 5.1.x) ;)øxygen wrote:Wenn das ganze schnell und sicher sein soll, kommt eigentlich nur FastCGI in frage.
PayPal.Me/JoeUser ● FreeBSD Remote Installation
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Re: PHP Performance
hab mir jetzt mal das howto durchgelsen und bin auf folgenden Punkt gestossen:
Bin zwar kein Fan von perl ;) Allerdings gibts ja doch einige die es PHP vorziehen. Wie löst ihr das Problem?
Code: Select all
man sollte keine CGI Scripte zulassen da das I Bit damit wieder entfernt werden könnte