Tutorial zu FCGI gesucht

[Reiner]

Hi,

ich tüftel gerade an etwas, was eine sehr kurze Antwortzeit des Servers erfordert. Ziel ist es, bei einer dynamischen Anwendung ähnliche Antwortzeiten wie bei stat. Contens hinzubekommen.

Dabei bin ich jetzt so weit, daß ich mir zunächst einmal angesehen habe, welche Antwortzeiten bzw. Latencen ich bei statischem Content habe. Ich komme bei einem Apache2 auf ziemlich genau 30 Requests/Sekunde. Das ist schonmal gut.

Zudem habe ich mal probehalber ein Script geschrieben, was Content einmal per perl und einmal per php ausliefert. Dabei wird eine Schleife durchlaufen, die rel. groß ist.
Ich bin mir sicher, daß das vielleicht nicht direkt vergleichbar ist, aber bei mir kam heraus, daß perl ca. 3mal schneller als php ist.

Nächster Flaschenhals (und darauf bezieht sich meine eigentliche Frage) wäre, daß das Script bei jedem Aufruf neu geladen wird, was sicher auch Zeit kostet.
Die Idee wäre also, den Kram einfach im Speicher zu halten.
Da ich damit noch nie beschäftigt habe, wollte ich gerne wissen, ob es irgendwo ein gutes Beispiel gibt, wo sowas mal erklärt wird:
Ein Script öffnet eine DB-Verbindung und spuckt die Daten auf Anforderung aus, d.h. das sollte mit FCGI funktionieren.
Ich habe mir zwar schon einige Dinge angesehen, was man dazu alles braucht, aber ich habe nicht wirklich verstanden, was ich da beim Apache2 machen muß und wie das Script initiert wird. Durch den Start des Apache? Und nochwas: Muß ich bei einer persistenten Verbindung zu MySQL irgendwas beachten, damit die Verbindung möglichst gehalten wird (Stunden, Tage)??

Ich habe mit CGI::Fast und FCGI für Perl besorgt und auch ansatzweise verstanden, wie das über Sockets arbeitet. Aber den Rest noch nicht wirklich hinbekommen. Insbesondere, was ich genau beim Indianer einstellen muß.

Dann ein letzter Punkt:
Habt Ihr Erfahrungen, was wirklich Geschwindigkeit bringt?
Gibt es noch irgendwelche verborgenen Tricks bei Server, die man ausreizen könnte? Sind die 30 Requests/Sek. noch zu steigern?
Ich habe einen P4 mit 3GHz und 2GB Speicher.

Danke!

Reiner

[Andreas Korthaus]

Hallo Reiner!

ich tüftel gerade an etwas, was eine sehr kurze Antwortzeit des Servers erfordert. Ziel ist es, bei einer dynamischen Anwendung ähnliche Antwortzeiten wie bei stat. Contens hinzubekommen.

Das kannst Du wohl vergessen ;-)
Ich denke das effizienteste wäre Deine Anforderung in einem eigenen Server-Modul zu implementieren.

Dabei bin ich jetzt so weit, daß ich mir zunächst einmal angesehen habe, welche Antwortzeiten bzw. Latencen ich bei statischem Content habe. Ich komme bei einem Apache2 auf ziemlich genau 30 Requests/Sekunde. Das ist schonmal gut.

Naja... ich würde mir bei Deiner Anforderung ernsthaft überlegen, von Apache abzusehen. Ich selbst würde es auf jeden Fall mit lighttpd versuchen, der ist vor allem bei statischem Content dem Apachen um Längen überlegen. Weitere Vorteile sind eben die besonders einfache Einbindung von FastCGI (das ist beim Apachen wirklich deutlich komplizierter), und nicht zuletzt die einfachere API für eigene Module.

Zudem habe ich mal probehalber ein Script geschrieben, was Content einmal per perl und einmal per php ausliefert. Dabei wird eine Schleife durchlaufen, die rel. groß ist.
Ich bin mir sicher, daß das vielleicht nicht direkt vergleichbar ist, aber bei mir kam heraus, daß perl ca. 3mal schneller als php ist.

Beides CGI? Ist zwar ungewöhnlich in dem Ausmaß, aber solche synthetischen Benchmarks sagen ja auch nicht wirklich viel aus. Wäre mal interesant den jeweiligen Code zu sehen.

Nächster Flaschenhals (und darauf bezieht sich meine eigentliche Frage) wäre, daß das Script bei jedem Aufruf neu geladen wird, was sicher auch Zeit kostet.

Gut, bei mod_php und mod_perl hast Du ja wenigstens schonmal das Laden des Interpreters bei jedem Request gespart, bei PHP kannst Du das Laden des Scriptes mit Opcode-Caches wie eAccelerator, oder auch PECL::APC (letzteres installiert man gaz simpel per pear install APC in der shell) cachen. Hierbei werden Scripte in Form von ausführbaren Opcodes im RAM gecached. Das bringt allerdings erst was, wenn Du viel Code und viele eingebundene Scripte hast.

Die Idee wäre also, den Kram einfach im Speicher zu halten.
Da ich damit noch nie beschäftigt habe, wollte ich gerne wissen, ob es irgendwo ein gutes Beispiel gibt, wo sowas mal erklärt wird:
Ein Script öffnet eine DB-Verbindung und spuckt die Daten auf Anforderung aus, d.h. das sollte mit FCGI funktionieren.

Mit einiger Sicherheit deutlich effizienter mit einem eigenen Server-Modul. Du kannst auch Datenstrukturen per memcached im RAM halten, falls es Dir was bringt.

Ich habe mir zwar schon einige Dinge angesehen, was man dazu alles braucht, aber ich habe nicht wirklich verstanden, was ich da beim Apache2 machen muß und wie das Script initiert wird. Durch den Start des Apache?

Vielleicht hilft Dir folgendes Howto: http://www.debianhowto.de/howtos/de/apache2-phpfcgi-sarge/, allerdings wird hier fcgi in den Scripten so verwendet wie cgi, außer dass die Prozesse halt bestehen bleiben. Aber wie gesagt, ich würde es so oder so eher mit lighttpd versuchen, da ist das deutlich einfacher. Da kannst Du entweder die Prozesse durch die Server-Config starten, oder durch ein externes Script, siehe oben verlinkte Doku.

Und nochwas: Muß ich bei einer persistenten Verbindung zu MySQL irgendwas beachten, damit die Verbindung möglichst gehalten wird (Stunden, Tage)??

ich wüßte nicht warum die Verbindung beendet werden soll, oder?

Vielleicht sowas beachten:

interactive_timeout

The number of seconds the server waits for activity on an interactive connection before closing it. An interactive client is defined as a client that uses the CLIENT_INTERACTIVE option to mysql_real_connect(). See also wait_timeout.

Habt Ihr Erfahrungen, was wirklich Geschwindigkeit bringt?

Lighttpd, ein Server-Modul, Caching :-)

Gibt es noch irgendwelche verborgenen Tricks bei Server, die man ausreizen könnte? Sind die 30 Requests/Sek. noch zu steigern?

Guck Dir die Benchmarks an: http://www.lighttpd.net/benchmark/

Ich habe einen P4 mit 3GHz und 2GB Speicher.

die dort verwendeten Systeme sind langsamer.

Keine Ahnung was Du bisher optimiert hast. Wenn es denn Apache sein muss, und Du kein Server-Modul verwendest, dann das Worker-MPM verwenden, alle Module raus die Du nicht brauchst, evtl. keep-alive nutzen wenn sinnvoll, vielleicht noch lingerd... aber es ist schwer zu sagen wenn man das exakte Szenario nicht kennt. Was ist mit HTTP-Caching? Vermutlich nicht möglich, oder? Entsprechend wohl auch kein Reverse-Proxy, oder? Naja, dann sollte man Webserver-Module statisch einbinden, gut optimierte compiler-flags verwenden... und was man halt noch so machen kann auf OS-Level.

siehe auch:

• http://httpd.apache.org/docs-2.0/misc/perf-tuning.html
• http://perl.apache.org/docs/1.0/guide/strategy.html
• http://phplens.com/phpeverywhere/tuning-apache-php

Grüße
Andreas

[Reiner]

Hallo Andreas,

ich tüftel gerade an etwas, was eine sehr kurze Antwortzeit des Servers erfordert. Ziel ist es, bei einer dynamischen Anwendung ähnliche Antwortzeiten wie bei stat. Contens hinzubekommen.

Das kannst Du wohl vergessen ;-)

Ich sagte "ähnlich"! :-)

Ich denke das effizienteste wäre Deine Anforderung in einem eigenen Server-Modul zu implementieren.

Dabei bin ich jetzt so weit, daß ich mir zunächst einmal angesehen habe, welche Antwortzeiten bzw. Latencen ich bei statischem Content habe. Ich komme bei einem Apache2 auf ziemlich genau 30 Requests/Sekunde. Das ist schonmal gut.

Naja... ich würde mir bei Deiner Anforderung ernsthaft überlegen, von Apache abzusehen. Ich selbst würde es auf jeden Fall mit lighttpd versuchen, der ist vor allem bei statischem Content dem Apachen um Längen überlegen. Weitere Vorteile sind eben die besonders einfache Einbindung von FastCGI (das ist beim Apachen wirklich deutlich komplizierter), und nicht zuletzt die einfachere API für eigene Module.

Auch eine gute Idee.
Ich bin nicht auf den Indianer angewiesen! Es geht um eine Lösung des Problems, sehr hohe Geschwindigkeiten hinzubekommen, nicht eine bestimmte Art der Lösung!

Zudem habe ich mal probehalber ein Script geschrieben, was Content einmal per perl und einmal per php ausliefert. Dabei wird eine Schleife durchlaufen, die rel. groß ist.
Ich bin mir sicher, daß das vielleicht nicht direkt vergleichbar ist, aber bei mir kam heraus, daß perl ca. 3mal schneller als php ist.

Beides CGI? Ist zwar ungewöhnlich in dem Ausmaß, aber solche synthetischen Benchmarks sagen ja auch nicht wirklich viel aus. Wäre mal interesant den jeweiligen Code zu sehen.

Nee, einfach nur auf der Konsole ausgeführt Schleife.
Wie gesagt, sicher nicht repräsantativ, aber php scheint schon um Länger langsamer zu sein.

Nächster Flaschenhals (und darauf bezieht sich meine eigentliche Frage) wäre, daß das Script bei jedem Aufruf neu geladen wird, was sicher auch Zeit kostet.
Gut, bei mod_php und mod_perl hast Du ja wenigstens schonmal das Laden des Interpreters bei jedem Request gespart, bei PHP kannst Du das Laden des Scriptes mit Opcode-Caches wie eAccelerator, oder auch PECL::APC (letzteres installiert man gaz simpel per pear install APC in der shell) cachen. Hierbei werden Scripte in Form von ausführbaren Opcodes im RAM gecached. Das bringt allerdings erst was, wenn Du viel Code und viele eingebundene Scripte hast.

Ich glaube, ich fange von vorne an, d.h. mache mal ein paar Tests mit dem anderen Server.
Das wird sowieso noch lustig genug, weil dann sicherlich noch an der DB gedreht werden muß.

Ach nochwas:
Ich sprach die ganze Zeit von einem gleichzeitigen Request. Wenn man z.B. 10 gleichzeitig abfeuert, geht die Latence natürlich hoch.
Dazu benutze ich einen zweiten Server. Bei habe ich über PEN verbunden.
Das Teil ist super, scheint keinerlei eigene Latence zu haben. Aber bei den meisten Linux-Distris ist noch ein anderes (etwas komplexeres) Paket dabei, das sich pound nennt.
Wenn ich es richtig verstanden habe, hat das zusätzlich noch einen Cache/Proxy, was der PEN nicht hat. Hat jemand damit Erfahrungen?

Um es kurz zu sagen:
Ich betreibe gerade etwas Forschung, wie ich mit möglichst wenig (Hardware-)Aufwand auf ca. 60 Anfragen pro Sekunde kommen kann...

Gruß
Reiner

[Andreas Korthaus]

Hallo!

Beides CGI? Ist zwar ungewöhnlich in dem Ausmaß, aber solche synthetischen Benchmarks sagen ja auch nicht wirklich viel aus. Wäre mal interesant den jeweiligen Code zu sehen.

Nee, einfach nur auf der Konsole ausgeführt Schleife.
Wie gesagt, sicher nicht repräsantativ, aber php scheint schon um Länger langsamer zu sein.

Naja, das sagt ja erstmal nicht viel, PHP ist halt eher auf Web-Entwicklung ausgelegt, siehe z.B.:

$ ls -sh /usr/bin/php  
3\.6M /usr/bin/php  
$ ls -sh /usr/bin/perl  
988K /usr/bin/perl  
$ time php -v  
PHP 5.0.3 (cli) (built: Apr  1 2005 01:51:12)  
  
[...]  
  
real    0m0.038s  
user    0m0.030s  
sys     0m0.010s  
$ time perl -v  
  
This is perl, v5.8.2 built for i686-linux  
  
[...]  
  
real    0m0.007s  
user    0m0.010s  
sys     0m0.000s  

Ich habe eigentlich die Erfahrung gemacht, dass es hier im Webumfeld zwar Unterschiede gibt, aber man kann nicht wirklich sagen ob jetzt mod_php schneller ist oder auch mod_perl, mal das eine, mal das andere, je nach Aufgabe und Implementierung. Auch die verwendete Konfiguration und Version hat teilweise erheblichen Einfluss. Z.B. gab es kürzlich einen Bug in scandir(), nach dessen Behebung die Funktion um mehr als eine Zehnerpotenz schneller wurde. Dafür gabe es letztens auch einen neuen Bug, durch den die Serialisierung von Daten ebenfalls in vergleichbaren Dimensionen langsamer wurde... Dazu kommen auch Verbesserung, z.B. in foreach() in einer der letzten Versionen... und in Perl wird es vermutlich ähnlich sein, wenngleich die Entwicklung hier etwas anders verläuft ;-)
In PHP 5.0 z.B. lag das Augenmerk eher nicht so auf der Geschwindigkeit, sondern an neuen Features. Sehr viele größere Patches die die Geschwindigkeit sehr positiv beeinflussen sind erst jetzt in 5.1 eingeflossen, usw...

Das wird sowieso noch lustig genug, weil dann sicherlich noch an der DB gedreht werden muß.

Ja, aber kommt halt drauf an was Du da für Anfragen hinschickst, und wieviele Daten die DB verarbeiten/speichern muss. Ist wieder die Frage was man hier cachen kann, in jedem Fall sollte man wohl die neue Client-Lib seit 4.1 verwenden, evtl. Prepared Statements oder noch besser Stored Procedures.

Ich sprach die ganze Zeit von einem gleichzeitigen Request. Wenn man z.B. 10 gleichzeitig abfeuert, geht die Latence natürlich hoch.
Dazu benutze ich einen zweiten Server. Bei habe ich über PEN verbunden.
Das Teil ist super, scheint keinerlei eigene Latence zu haben. Aber bei den meisten Linux-Distris ist noch ein anderes (etwas komplexeres) Paket dabei, das sich pound nennt.
Wenn ich es richtig verstanden habe, hat das zusätzlich noch einen Cache/Proxy, was der PEN nicht hat. Hat jemand damit Erfahrungen?

ich nicht, aber was bringt Dir das? Ich gehe davon aus dass Du Dir ja was schönes zum Daten sammeln basteln willst (wie diese Bildchen hin und wieder), also muss ja jeder Request zum Server durchkommen. Bringt ein Cache davor also nix. Ich würde auch erstmal keinen Load-Balancer verwenden, bis zu einem bestimmten Level wird er Dich eher ausbremsen, nämlich so lange bis die eine Maschien am Ende ist. Aber solange sie das nicht ist, kostst es nur unnötige Resourcen. Und bevor ich dann einen Load-Balancer anschaffe, würde bei mir erstmal der DB-Server auf eine eigene Maschine ausgelagert. Ich vermute auch, dass die DB viel schneller zum Engpass wird, als die Verarbeitung des Requests. Einen LoadBalancer davorschalten kann man immer noch. Muss man nur bei der Entwicklung im Hinterkopf haben, aber solange ein Zustand nur in einer einzigen DB gehalten wird, ist auch das weniger ein Problem.

Ich betreibe gerade etwas Forschung, wie ich mit möglichst wenig (Hardware-)Aufwand auf ca. 60 Anfragen pro Sekunde kommen kann...

Das kommt drauf an was Du genau machen musst um einen Request zu bearbeiten. Noch effizienter als ein eigenes Webserver Modul wäre vermutlich ein eigener Webserver (zumindest wenn man weiß was man tut ;-)). Wenn Du Perl verwenden willst, wäre es vielleicht Dank cpan nicht so schwer ein Perl Script als Webserver laufen zu lassen, der wirklich nur das macht und kann, was Du brauchst. Wenn Du nur so Sachen machst wie DB-Zugriffe und das senden von ganz bestimmten Bildern und Headern, dann sollte es kein großes Problem sein. Deutlich effizienter dürfte es mit C funktionieren, allerdings auch deutlich anspruchvoller.

Grüße
Andreas

[Reiner]

Hi,

Ich habe eigentlich die Erfahrung gemacht, dass es hier im Webumfeld zwar Unterschiede gibt, aber man kann nicht wirklich sagen ob jetzt mod_php schneller ist oder auch mod_perl, mal das eine, mal das andere, je nach Aufgabe und Implementierung. Auch die verwendete Konfiguration und Version hat teilweise erheblichen Einfluss. Z.B. gab es kürzlich einen Bug in scandir(), nach dessen Behebung die Funktion um mehr als eine Zehnerpotenz schneller wurde. Dafür gabe es letztens auch einen neuen Bug, durch den die Serialisierung von Daten ebenfalls in vergleichbaren Dimensionen langsamer wurde... Dazu kommen auch Verbesserung, z.B. in foreach() in einer der letzten Versionen... und in Perl wird es vermutlich ähnlich sein, wenngleich die Entwicklung hier etwas anders verläuft ;-)
In PHP 5.0 z.B. lag das Augenmerk eher nicht so auf der Geschwindigkeit, sondern an neuen Features. Sehr viele größere Patches die die Geschwindigkeit sehr positiv beeinflussen sind erst jetzt in 5.1 eingeflossen, usw...

ok, ob perl oder php ist letztlich egal.
Ich entscheide das noch nicht.
Ich muß erstmal statisch extreme Geschwindigkeit hinbekommen.
Wenn ich auch Christophs Beitrag ansehe und die Benchmarks, die Du verlinkt hast, scheint mir im Moment schon der Apache nicht besonders toll zu sein.
Vielleicht wurde das aber dort auch lokal gemessen. Ich habe eine Fernmessung von einem anderen Server (allerdings im selben Netzwerk) gemacht. Mehr als 30 Seiten kamen da pro Sek. nicht.

Das wird sowieso noch lustig genug, weil dann sicherlich noch an der DB gedreht werden muß.
Ja, aber kommt halt drauf an was Du da für Anfragen hinschickst, und wieviele Daten die DB verarbeiten/speichern muss. Ist wieder die Frage was man hier cachen kann, in jedem Fall sollte man wohl die neue Client-Lib seit 4.1 verwenden, evtl. Prepared Statements oder noch besser Stored Procedures.

Ist schon klar. Die Fragen dazu kommen morgen! ;-)

Ich sprach die ganze Zeit von einem gleichzeitigen Request. Wenn man z.B. 10 gleichzeitig abfeuert, geht die Latence natürlich hoch.
Dazu benutze ich einen zweiten Server. Bei habe ich über PEN verbunden.
Das Teil ist super, scheint keinerlei eigene Latence zu haben. Aber bei den meisten Linux-Distris ist noch ein anderes (etwas komplexeres) Paket dabei, das sich pound nennt.
Wenn ich es richtig verstanden habe, hat das zusätzlich noch einen Cache/Proxy, was der PEN nicht hat. Hat jemand damit Erfahrungen?
ich nicht, aber was bringt Dir das? Ich gehe davon aus dass Du Dir ja was schönes zum Daten sammeln basteln willst (wie diese Bildchen hin und wieder), also muss ja jeder Request zum Server durchkommen.

Nee, für unsere Statistik brauche ich solche Antwortzeiten nicht!
Da gibt es ganz andere Anforderungen.
Aber Du liegst nicht ganz falsch, daß es mit einem unserer Produkte zusammenhängt! ;-)

Bringt ein Cache davor also nix. Ich würde auch erstmal keinen Load-Balancer verwenden, bis zu einem bestimmten Level wird er Dich eher ausbremsen, nämlich so lange bis die eine Maschien am Ende ist. Aber solange sie das nicht ist, kostst es nur unnötige Resourcen. Und bevor ich dann einen Load-Balancer anschaffe, würde bei mir erstmal der DB-Server auf eine eigene Maschine ausgelagert. Ich vermute auch, dass die DB viel schneller zum Engpass wird, als die Verarbeitung des Requests. Einen LoadBalancer davorschalten kann man immer noch. Muss man nur bei der Entwicklung im Hinterkopf haben, aber solange ein Zustand nur in einer einzigen DB gehalten wird, ist auch das weniger ein Problem.

Das sehe ich wirklich anders!
Ich habe Messungen gemacht, wo ich vorher 14-16 Anfragen (nicht statisch!) hinbekommen habe, entstanden mit zwei Servern mehr als 25.
D.h. es ergibt sich keine Verdopplung durch zwei Server, aber erstens beugt man einem Ausfall vor und die Latenzen gehen runter.
Zudem dient es der Datensicherung. Der zweite Server läuft in Replikation.

Ich betreibe gerade etwas Forschung, wie ich mit möglichst wenig (Hardware-)Aufwand auf ca. 60 Anfragen pro Sekunde kommen kann...
Das kommt drauf an was Du genau machen musst um einen Request zu bearbeiten. Noch effizienter als ein eigenes Webserver Modul wäre vermutlich ein eigener Webserver (zumindest wenn man weiß was man tut ;-)). Wenn Du Perl verwenden willst, wäre es vielleicht Dank cpan nicht so schwer ein Perl Script als Webserver laufen zu lassen, der wirklich nur das macht und kann, was Du brauchst. Wenn Du nur so Sachen machst wie DB-Zugriffe und das senden von ganz bestimmten Bildern und Headern, dann sollte es kein großes Problem sein. Deutlich effizienter dürfte es mit C funktionieren, allerdings auch deutlich anspruchvoller.

By the way, nochmals vielen Dank für die Tips.
Ich glaube, da sind viele brauchbare Dinge dabei!

Gruß
Reiner

[Andreas Korthaus]

Hi!

Wenn ich auch Christophs Beitrag ansehe und die Benchmarks, die Du verlinkt hast, scheint mir im Moment schon der Apache nicht besonders toll zu sein.
Vielleicht wurde das aber dort auch lokal gemessen.

in dem von mir verlinkten Benchmark nicht, da ist die Hardware der Client-Maschine sogar angegeben. Und mit dem (schwächeren) Server dort kommt er immerhin auf >70 Request beim Apachen mit _dynamischen_ Inhalten. Bei statischen Inhalten kommt er sogar auf > 1000 Request pro Sekunde. Bei localhost ist das nochmal deutlich mehr.

Testserver war ein AMD Athlon mit 1666 MHz und 512 Mb RAM.

Ich habe eine Fernmessung von einem anderen Server (allerdings im selben Netzwerk) gemacht. Mehr als 30 Seiten kamen da pro Sek. nicht.

dann läuft da wohl irgendwas nicht ganz optimal - womit hast Du gemessen?

Ich gehe davon aus dass Du Dir ja was schönes zum Daten sammeln basteln willst (wie diese Bildchen hin und wieder), also muss ja jeder Request zum Server durchkommen.

Nee, für unsere Statistik brauche ich solche Antwortzeiten nicht!
Da gibt es ganz andere Anforderungen.
Aber Du liegst nicht ganz falsch, daß es mit einem unserer Produkte zusammenhängt! ;-)

Den genauen Zweck zu kennen wäre nicht schlecht. Was genau soll das Script denn machen? Was für DB-Abfragen wird das Script bei einem Request durchführen? In welcher Größenordnung liegt die DB? Was soll das Script antworten? Wie oft kommen Requests vom selben Client? Welcher Teil der Antwort ließe sich evtl. cachen? ...

Ich habe Messungen gemacht, wo ich vorher 14-16 Anfragen (nicht statisch!) hinbekommen habe, entstanden mit zwei Servern mehr als 25.
D.h. es ergibt sich keine Verdopplung durch zwei Server, aber erstens beugt man einem Ausfall vor und die Latenzen gehen runter.
Zudem dient es der Datensicherung. Der zweite Server läuft in Replikation.

Die Frage ist welche Anforderungen an die Skalierbarkeit gestellt werden. 60 Requests pro Sekunde ließen sich (je nach notwendigem Aufwand) möglicherweise mit einem System abwickeln. Wenn aber in Zukunft auch 500 Requests bearbeitet werden sollen, ist das was anderes. Was Ausfallsicherheit angeht ist es natürlich ein Voreil, da gebe ich Dir Recht, nur mit der kleinen Einschränkung dass der LoadBalancer ein Single-Point-of-Failure darstellt, und wenn diese Maschine vergleichbar mit den Servern dahinter ist, hat man IMHO nicht viel gewonnen, da es genauso wahrscheinlich ist dass der Load-Balancer ausfällt, wie eine Maschine dahinter. Daher würde ich immer einen Hardware-Loadbalancer nehmen, wenn ich denn diese Performance oder Ausfallsicherheit brauche. Ist auch gar nicht so teuer wenn man es mietet ;-)

By the way, nochmals vielen Dank für die Tips.
Ich glaube, da sind viele brauchbare Dinge dabei!

Bin mal gespannt ob sich das auch in einer höheren Anzahl an Requests pro Sekunde widerspiegelt ;-)

Ich erwarte dann Deinen Bericht Montag 7:00 auf meinem Schreibtisch *g*

Grüße
Andreas

[Reiner]

Hi,

Wenn ich auch Christophs Beitrag ansehe und die Benchmarks, die Du verlinkt hast, scheint mir im Moment schon der Apache nicht besonders toll zu sein.
Vielleicht wurde das aber dort auch lokal gemessen.
in dem von mir verlinkten Benchmark nicht, da ist die Hardware der Client-Maschine sogar angegeben. Und mit dem (schwächeren) Server dort kommt er immerhin auf >70 Request beim Apachen mit _dynamischen_ Inhalten. Bei statischen Inhalten kommt er sogar auf > 1000 Request pro Sekunde. Bei localhost ist das nochmal deutlich mehr.

Testserver war ein AMD Athlon mit 1666 MHz und 512 Mb RAM.

oha! Wenn ich diese Zahl schon statisch hinbekäme wäre ich sehr glücklich!

Ich habe eine Fernmessung von einem anderen Server (allerdings im selben Netzwerk) gemacht. Mehr als 30 Seiten kamen da pro Sek. nicht.
dann läuft da wohl irgendwas nicht ganz optimal - womit hast Du gemessen?

Mit pounder.pl von Herrn Schilli!

Ich gehe davon aus dass Du Dir ja was schönes zum Daten sammeln basteln willst (wie diese Bildchen hin und wieder), also muss ja jeder Request zum Server durchkommen.

Nee, für unsere Statistik brauche ich solche Antwortzeiten nicht!
Da gibt es ganz andere Anforderungen.
Aber Du liegst nicht ganz falsch, daß es mit einem unserer Produkte zusammenhängt! ;-)

Den genauen Zweck zu kennen wäre nicht schlecht. Was genau soll das Script denn machen? Was für DB-Abfragen wird das Script bei einem Request durchführen? In welcher Größenordnung liegt die DB? Was soll das Script antworten? Wie oft kommen Requests vom selben Client? Welcher Teil der Antwort ließe sich evtl. cachen? ...

Wenn das klappt, wirst Du den Zweck vielleicht irgendwann bei Heise o.ä. nachlesen können. Die DB wird ein paar MB groß sein. Nichts extremes.

Ich habe Messungen gemacht, wo ich vorher 14-16 Anfragen (nicht statisch!) hinbekommen habe, entstanden mit zwei Servern mehr als 25.
D.h. es ergibt sich keine Verdopplung durch zwei Server, aber erstens beugt man einem Ausfall vor und die Latenzen gehen runter.
Zudem dient es der Datensicherung. Der zweite Server läuft in Replikation.

Die Frage ist welche Anforderungen an die Skalierbarkeit gestellt werden. 60 Requests pro Sekunde ließen sich (je nach notwendigem Aufwand) möglicherweise mit einem System abwickeln. Wenn aber in Zukunft auch 500 Requests bearbeitet werden sollen, ist das was anderes. Was Ausfallsicherheit angeht ist es natürlich ein Voreil, da gebe ich Dir Recht, nur mit der kleinen Einschränkung dass der LoadBalancer ein Single-Point-of-Failure darstellt, und wenn diese Maschine vergleichbar mit den Servern dahinter ist, hat man IMHO nicht viel gewonnen, da es genauso wahrscheinlich ist dass der Load-Balancer ausfällt, wie eine Maschine dahinter. Daher würde ich immer einen Hardware-Loadbalancer nehmen, wenn ich denn diese Performance oder Ausfallsicherheit brauche. Ist auch gar nicht so teuer wenn man es mietet ;-)

Ja, die Kosten für Hardwarebalancer sind aber unvergleichlich hoch.
Ich glaube auch nicht, daß die soviel ausfallsicherer als ein etwas hochgezüchteter Server mit dem PEN o.ä.
Zudem kann man auch Loadbalancer kaskadieren. Der mögliche Ausfall an sich soll aber vorerst mal unbeachtet bleiben.

By the way, nochmals vielen Dank für die Tips.
Ich glaube, da sind viele brauchbare Dinge dabei!
Bin mal gespannt ob sich das auch in einer höheren Anzahl an Requests pro Sekunde widerspiegelt ;-)

Ich erwarte dann Deinen Bericht Montag 7:00 auf meinem Schreibtisch *g*

Da muß ich Dich schon jetzt enttäuschen.
Um 7 Uhr bin ich im ICE nach Berlin unterwegs.

Gruß
Reiner

[Andreas Korthaus]

Hi!

oha! Wenn ich diese Zahl schon statisch hinbekäme wäre ich sehr glücklich!

Die aufgerufene PHP-Seite ist übrigens die index.php von PHPmyAdmin ;-)

Großen Anteil daran hat aber der Opcode-Cache. Was so einer erreichen kann siehst Du z.B. hier: http://turck-mmcache.sourceforge.net/index_old.html#bench
Wenn Du Dir das genauer anguckst, siehst Du was sich nochmal für ein enormer Sprung durch einen Content-Cache (also qasi statische Inhalte) erreichen lässt. Aber das wird wohl keine Option sein, weil die Requests dann nicht mehr durch Deine Programm-Logik laufen. Wenn Du allerdings in der Lage bist komplett den Content für bestimmte Requests zu Cachen, und Du das nicht durch HTTP-Caching erreichen kannst, kannst Du auf diese Weise ne ganze Menge gewinnen.

womit hast Du gemessen?

Mit pounder.pl von Herrn Schilli!

von 98? Vielleicht ist das Script auch etwas langsam ;-) Ich würde es mal mit ab versuchen, so kannst Du wenigstens mal im direkten Vergleich mit den von mir geposteten Benchmarks (mit identischen Einstellungen) sehen, ob sich da was verändert. Ich verwende immer entweder eben ab oder siege.

Wenn das klappt, wirst Du den Zweck vielleicht irgendwann bei Heise o.ä. nachlesen können. Die DB wird ein paar MB groß sein. Nichts extremes.

Wenn es keine komplizierten Queries sind, könnte man die Daten ja auch direkt im Ram halten, so wie im Forum hier. Oder in memcached.

Ich erwarte dann Deinen Bericht Montag 7:00 auf meinem Schreibtisch *g*

Da muß ich Dich schon jetzt enttäuschen.
Um 7 Uhr bin ich im ICE nach Berlin unterwegs.

immer diese Ausreden... ;-)

Grüße
Andreas

[Reiner]

»» »» »» womit hast Du gemessen?

Mit pounder.pl von Herrn Schilli!

von 98? Vielleicht ist das Script auch etwas langsam ;-) Ich würde es mal mit ab versuchen, so kannst Du wenigstens mal im direkten Vergleich mit den von mir geposteten Benchmarks (mit identischen Einstellungen) sehen, ob sich da was verändert. Ich verwende immer entweder eben ab oder siege.

ich habe ab2 genutzt und komme auf 150 Requ./Sek.
Ich bekomme die Krise. Das bedeutet, ich bin die ganze Zeit einem Geist hinterher gejagt.
Ich danke Dir, denn die anderen Hinweise sind jetzt umso wichtiger!

Gruß
Reiner

[Andreas Korthaus]

Hi!

ich habe ab2 genutzt und komme auf 150 Requ./Sek.

Auf dynamische oder statische Resourcen? Bei letzterem wäre es immer noch nicht der Renner ;-)
Was genau verwendest Du denn im Moment für eine "dynamische Resource"? (Sprache, SAPI, enthaltene Logik...)

Ich bekomme die Krise.

;-)

Grüße
Andreas

[Reiner]

Hi!

ich habe ab2 genutzt und komme auf 150 Requ./Sek.
Auf dynamische oder statische Resourcen? Bei letzterem wäre es immer noch nicht der Renner ;-)

Test I)
statisch auf /index.html

• ohne PEN-Loadbalancer: 960
• mit PEN (2 Server): 520

Test II)
statisch auf /

• ohne PEN: 150
• mit PEN: 110

Test III)
dynamisch auf /index.php (keine DB-Anfrage)

• ohne PEN: 140
• mit PEN: 110

Interessant ist der Unterschied zwischen I) und II).

Gruß
Reiner

[Andreas Korthaus]

Hi!

Test I)
statisch auf /index.html

• ohne PEN-Loadbalancer: 960
• mit PEN (2 Server): 520

siehste? ;-) Aber das sieht ja schon langsam nach was aus..

Interessant ist der Unterschied zwischen I) und II).

Kann es sein dass / auf /index.php mappt?

Grüße
Andreas

[Reiner]

Test I)
statisch auf /index.html

• ohne PEN-Loadbalancer: 960
• mit PEN (2 Server): 520

siehste? ;-) Aber das sieht ja schon langsam nach was aus..

ja, danke Dir!

Interessant ist der Unterschied zwischen I) und II).

Kann es sein dass / auf /index.php mappt?

natürlich... *grummel*
Ist ja in der Konfiguration beim indexieren als erstes eingetragen.
Ich habe wohl ein Brett vorm Kopf gehabt.
Naja, egal. Nächster Schritt, der nun anliegt, ist jetzt wohl, entweder php oder perl per proxy o.ä. schneller zu machen.
Dann geht's ans Eingemachte bzgl. Datenbank. Das wird auch noch lustig.

Aber jetzt sehe ich wenigstens eine Chance, daß das, was letztendlich dabei rauskommen soll, keine Zauberei darstellt.

Gruß
Reiner

[Andreas Korthaus]

Hi!

Kann es sein dass / auf /index.php mappt?

natürlich... *grummel*

dachte ichs mir ;-)

Naja, egal. Nächster Schritt, der nun anliegt, ist jetzt wohl, entweder php oder perl per proxy o.ä. schneller zu machen.

Ein Proxy bringt Dir nur was, wenn Du HTTP-Requests cachen kannst, was dazu führt dass nicht jeder Request Dein Script erreicht. PHP kannst Du wie gesagt per Opcode-Cache beschleunigen, aber das bringt Dir nur einen nennenswerten Vorteil, wenn Du ein komplexes Script verwendest (z.B. PEAR-Pakete, Smarty...). Die 150 Requests pro Sekunde sehen ja nett aus, aber das kann sich sehr schnell ändern je nachdem was Du im Script veranstaltest. Das größte Einsparpotential hast Du durch 1. HTTP-Caching, 2. durch Content-Caching. Die Frage ist, ob das geht oder nicht. Wie gesagt, wenn man auf einer dieser beiden Ebenen cached, erreichen nicht mehr _alle_ Requests Deinen PHP/Perl Code. Wenn Du jeden Request brauchst, solltest Du evtl. etwas anderes verwenden als eine interpretierte Sprache, siehe meine anderen Postings. FastCGI wird sicher noch ein wenig besser sein als die Modul-Versionen, allerdings kann ich mir nicht vorstellen, dass Du damit den großen Wurf landen wirst.

Ich stehe so ein bisschen vor einem ähnlichen Problem, ich brauche für den größten Teil meiner Requests zumindest einen Teil der Funktionalität die ich in meinem PHP-Framework habe, aber es sollte erheblich schneller gehen.  Das einfachste wäre wohl einen PHP-Daemon nebenher laufen zu lassen, weil der problemlos vorhandenen Code nutze könnte, aber will man das wirklich? ;-)
Der interessanteste Ansatz bisher ist der von lighttpd mit dem Cache-Modul: http://www.incremental.de/talks/phpconf-2003-caching/lighttpd_cache/index.html ff. (die gesamte Präsentation wird Dich vermutlich interessieren)
Allerdings ist die Flexibilität noch etwas begrenzt, aber wie Du an den Benchmarks in der Präsentation siehst ist dort genau die richtige Stelle wo man eigentlich ansetzen muss um wirklich was zu bewegen. Irgendwie müsste man es doch hinbekommen ein Modul so zu entwickeln, dass es sich schön in eine Applikation integriert. Bisher funktioniert nur die Kommunikation über das Dateisystem oder MySQL. Ich persönlich halte von beidem nicht sooo viel. Irgendwie müssten PHP-Scripte mit so einem Modul direkt kommunizieren können, hab allerdings keine Ahnung wie man sowas elegant machen könnte. Direkte kommunikation zw. PHP und einem Server-Modul ist vermutlich Quatsch, denn wie soll das gehen? PHP muss sich nicht im selben Prozess befinden, bei FCGI sogar nichtmal auf demselben Server (gut, letzteres ließe sich ja sicherstellen). Das beste wäre da IMHO noch ein zusätzlicher Caching-Server der da vermittelt, vielleicht ginge das sogar mit memcached.  Aber das ganze erhöht natürlich die Komplexität ganz erheblich...

Grüße
Andreas

[Reiner]

Hi,

Kann es sein dass / auf /index.php mappt?

natürlich... *grummel*

dachte ichs mir ;-)

Naja, egal. Nächster Schritt, der nun anliegt, ist jetzt wohl, entweder php oder perl per proxy o.ä. schneller zu machen.

Ein Proxy bringt Dir nur was, wenn Du HTTP-Requests cachen kannst, was dazu führt dass nicht jeder Request Dein Script erreicht.

Ist klar und dann auch so gewollt!

Der interessanteste Ansatz bisher ist der von lighttpd mit dem Cache-Modul: http://www.incremental.de/talks/phpconf-2003-caching/lighttpd_cache/index.html ff. (die gesamte Präsentation wird Dich vermutlich interessieren)

Das witzige ist - fällt mir jetzt erst auf - das lighthttpd ist von Jan Kneschke. Den kenne ich, der ist Mitarbeiter bei MySQL AB.

Gruß
Reiner

[Andreas Korthaus]

Hi!

Der interessanteste Ansatz bisher ist der von lighttpd mit dem Cache-Modul: http://www.incremental.de/talks/phpconf-2003-caching/lighttpd_cache/index.html ff. (die gesamte Präsentation wird Dich vermutlich interessieren)

Das witzige ist - fällt mir jetzt erst auf - das lighttpd ist von Jan Kneschke. Den kenne ich, der ist Mitarbeiter bei MySQL AB.

Ja, der macht da AFAIK Schulungen oder sowas, oder? Jedenfalls ist aus lighttpd inzwischen ein recht ansehnliches Projekt geworden, bereits in vielen Distributionen enthalten. Der Webserver ist eigentlich genau für Deinen Einsatzzweck geschrieben worden. Und inzwischen verbreitet er sich auch langsam im Netz: http://article.gmane.org/gmane.comp.web.lighttpd/1612/match=netcraft ;-)

Grüße
Andreas

[Reiner]

Hi,

Ja, der macht da AFAIK Schulungen oder sowas, oder?

genau, für Zertifizierungen.

Jedenfalls ist aus lighttpd inzwischen ein recht ansehnliches Projekt geworden, bereits in vielen Distributionen enthalten. Der Webserver ist eigentlich genau für Deinen Einsatzzweck geschrieben worden. Und inzwischen verbreitet er sich auch langsam im Netz: http://article.gmane.org/gmane.comp.web.lighttpd/1612/match=netcraft ;-)

ich habe das kurz mal installiert. Aber wie man z.B. php ans Laufen bekommt, habe ich nicht verstanden. Perl dürfte leichter sein.

Nur, ich mache gerade ein paar Meßreihen. Der Apache ist nun wirklich nicht mehr der Flaschenhals! ;-)
Jetzt brauche ich einen Proxy und wenn das klappt, gehts an die Datenbanken.

Irgendeinen Tip, was man zum Cachen nutzen sollte?
Grundsätzlich sollte alles, was (egal ob mit Parametern oder nicht) gecached und wenn vorhanden zurückgeworfen werden, sofern es innerhalb einer bestimmten Zeitspanne liegt.
Per GET ist das vielleicht trivial, was passiert eigentlich bei einem POST? Gibt es dafür auch Proxys, die das beherrschen?

Gruß
Reiner

[Andreas Korthaus]

Hi!

ich habe das kurz mal installiert. Aber wie man z.B. php ans Laufen bekommt, habe ich nicht verstanden.

Entweder per CGI, oder erheblich effizienter, per FCGI. Irgendwo im Surce findest Du eine kommentierte Beispiel-Config, das fand ich beim ersten mal recht hilfreich. Ich habe das ganze relativ problemlos auf Gentoo über Portage installieren können.

Die Doku zu FastCGI ist da ganz hilfreich bei der Konfiguration: http://lighttpd.net/documentation/fastcgi.html

Ich habe external spawning verwendet, beim kopilieren hat lighttpd ein 2. binary installiert: spawn-fcgi. (keine Ahnung ob es hier eines bestimmten configure-switches bedarf). Eine beispielhafte Konfig findest Du in der verlinten Doku, ist sehr simpel.

Beim kompilieren von PHP ist es wichtig, dass nicht --with-apxs bzw. --with-apxs2 verwendet wird, dafür wird --enable-fastcgi,  --enable-discard-path und --enable-force-cgi-redirect benötigt.

Meine Lighttpd-Konfiguration sieht etwas so aus:

# cat  /etc/lighttpd.conf  
  
server.modules              = ( "mod_access",  
                                "mod_fastcgi",  
                                "mod_accesslog" )  
  
server.document-root        = "/var/www/localhost/htdocs/"  
  
server.errorlog             = "/var/log/lighttpd/error.log"  
  
server.indexfiles           = ( "index.php", "index.html",  
                                "index.htm", "default.htm" )  
  
accesslog.filename          = "/var/log/lighttpd/access.log"  
  
fastcgi.server              = ( ".php" =>  
                                ( "localhost" =>  
                                  (  
                                    "host" => "127.0.0.1",  
                                    "port" => 1026  
                                  )  
                                )  
                              )  
  
mimetype.assign             = (  
  ".pdf"          =>      "application/pdf",  
  ".sig"          =>      "application/pgp-signature",  
  ".spl"          =>      "application/futuresplash",  
...  
[GEKÜPRZT]  
...  
  ".asx"          =>      "video/x-ms-asf",  
  ".wmv"          =>      "video/x-ms-wmv"  
 )  

Das finde ich schon sehr simpel. Wenn man einmal durchgestiegen ist.

Perl dürfte leichter sein.

keine Ahnung - warum?

Irgendeinen Tip, was man zum Cachen nutzen sollte?

Ich finde folgendes sehr interessant: http://turck-mmcache.sourceforge.net/index_old.html#bench

Benchmark phpmyadmin Startseite (Requests/Sekunde):
1. PHP ohne alles: 8.91
2. mit opcode-Cache: 43.27
3. mit content-Cache: 543.48

Bei 1. und 2. wird der PHP-Code ausgeführt, bei letzterem wird die Ausgabe von PHP im RAM gecached, also kein PHP mehr ausgeführt. Passiert aber alles noch in der "PHP-Engine". Bei letzterem bist Du nicht mehr weit von statischen Requets enfernt. Weiter geht es dann mit einem Squid als Reverse-Proxy, der Requests für gewisse Zeit komplett vom Webserver fernhält, vermutlich ähnlich effizient wie das lighttpd cache-modul. Also wieder zum lighttpd-benchmark ff. (Tests mit AMD Duron 2000):

ohne lighttpd Cache

* statische Seite: 17.000 R/s (100%)
    * Hello-world PHP: 1.200 R/s (7%)
    * PHP jan.kneschke.de: 100 R/s (0,58%)

mit lighhtpd Cache (letzter Request):

*  4900 R/s für einen Cache-Hit
    * 100 R/s für einen Cache-Miss

Und dann gibt es ja noch die Möglichkeit per HTTP-Header dafür zu sorgen, dass die Browser die Resource eine gewisse Zeit lokal cachen, ohne bei neuem Zugriff auf Änderungen zu prüfen, siehe: http://aktuell.de.selfhtml.org/artikel/server/apachetuning/index.html#a8

Grundsätzlich sollte alles, was (egal ob mit Parametern oder nicht) gecached und wenn vorhanden zurückgeworfen werden, sofern es innerhalb einer bestimmten Zeitspanne liegt.

Wenn das geht kannst Du sehr gut cachen, auch auf der effizientesten Ebene, HTTP. Denn nur damit kannst Du Requests komplett verhindern!

Grüße
Andreas

[Reiner]

Hi Andreas,

super, danke für die ganzen Details!

Der Thread hat echt Wert!!!
Ich glaube, nicht nur für mich.

Gruß
Reiner

[Andreas Korthaus]

Hi Reiner!

Der Thread hat echt Wert!!!
Ich glaube, nicht nur für mich.

Falls Du bereits irgendwelche Ergebnisse von Deinen "Meßreihen" hast, würden diese den Wert des Threads sicher noch weiter steigern;-)
Und nicht zuletzt interessieren es mich auch was Du bisher erreicht hast und vor allem wie/womit!

Viele Grüße
Andreas

[Reiner]

Hi Reiner!

Der Thread hat echt Wert!!!
Ich glaube, nicht nur für mich.

Falls Du bereits irgendwelche Ergebnisse von Deinen "Meßreihen" hast, würden diese den Wert des Threads sicher noch weiter steigern;-)
Und nicht zuletzt interessieren es mich auch was Du bisher erreicht hast und vor allem wie/womit!

Also, ich schaffe mit zwei replizierenden Servern jetzt ca. 2000 bis 2500 Anfragen pro Sekunde (100 gleichzeitige Requests).
Ich habe jetzt aus Deinen ganzen Hinweisen mir das für mich beste bzw. am leichtesten zu realisierende rausgesucht.
Ich benutze jetzt den Apache, einen PEN-Loadbalancer, den Turck-Cache und Squid als Accelator.

Das Ding hat jetzt richtig Dampf!
Jetzt geht es ans Optimieren von Datenbanken bzw. Querys. Das ist aber kein Softwareproblem.

By the way zur Messung:
Ich habe mir zu dem Tool von M.Schilli nochmals Gedanken gemacht.
Ich denke, es ist nicht völlig falsch, nur ein anderer Ansatz.
Wenn ich es richtig verstehe, mißt das Benchmark vom Apache, auf wieviel Anfragen ein Server reagieren kann - unbesehen, ob das Ausliefern 1ms oder 10 Minuten dauert.
pounder.pl wartet aber auf die Auslieferung (ist ja einfach nur ein Robot).

Gruß
Reiner

[Andreas Korthaus]

Hallo!

Also, ich schaffe mit zwei replizierenden Servern jetzt ca. 2000 bis 2500 Anfragen pro Sekunde (100 gleichzeitige Requests).

Was heißt "replizierend"? Was wird bei einem Request ausgeführt? Du musst natürlich aufpassen wenn Du mit so einem simplen tool wie ab benchmarkst, und dabei alle möglichen Caches verwendest. Das kann zu einem bösen Erwachen führen wenn die Requests auf einmal von ganz verschiedenen, echten Clients kommen. Wenn ich das richtig verstehe generierst Du immer eine Ausgabe für alle Clients, und lässt die dann X Sekunden cachen, ja?

Ich benutze jetzt den Apache, einen PEN-Loadbalancer, den Turck-Cache und Squid als Accelator.

kein lighttpd? Schade ;-) Das ist für mich die einfachste/beste Vatiante:

-> lighttpd
-> PHP-FastCGI
-> eAccelerator
-> Squid

gut, aber so viel wird sich da nicht tun. Bedenke allerdings dass der Entwickler des Turck-Cache vor 1,5 Jahren zu Zend gewechselt ist, und der Turck-Cache einige Bugs enthält, die bis heute nicht behoben wurden, weil sich niemand mehr drum kümmert. Da der Turck-Cache unter der GPL steht wird der Code inzwischen in einem neuen Projekt weitergeführt -> eAccelerator. Da sind die versammelt, die Turck weiterentwickeln. Hatte sich ca. ein Jahr nichts getan, dann kam vor ein paar Monaten eben eAccelerator mit allen möglichen Patches, die dann auch den Betrieb von PHP5 erlaubten. Allerdings sind bzgl. PHP5 noch ein paar kleinere Bugs vorhanden. Turck würde ich nicht mehr nehmen. Ich habe nach Turck (mit dem ich ein paar segfault-Probleme bekam) ne ganze Zeit mit PECL::APC gearbeitet (daran arbeiten einige PHP-Devs, so auch Rasmus), das läuft auch super-stabil udn schnell, allerdings nicht mit PHP5. Daher bin ich inzwichen auf eAccelerator umgestiegen. APC kannst Du schön einfach installieren:

pear install APC

das als superuser und Du bist fertig.

Das Ding hat jetzt richtig Dampf!

jo, sieht so aus ;-)

Verwendest Du Turck auch als Conent-Cache?

<?php  
  mmcache_cache_page($_SERVER['PHP_SELF'].'?GET='.serialize($_GET), 30);  
  echo time();  
  phpinfo();  
?>

http://turck-mmcache.sourceforge.net/index_old.html#api

Ich habe mir zu dem Tool von M.Schilli nochmals Gedanken gemacht.
Ich denke, es ist nicht völlig falsch, nur ein anderer Ansatz.
Wenn ich es richtig verstehe, mißt das Benchmark vom Apache, auf wieviel Anfragen ein Server reagieren kann - unbesehen, ob das Ausliefern 1ms oder 10 Minuten dauert.
pounder.pl wartet aber auf die Auslieferung (ist ja einfach nur ein Robot).

das mach ab AFAIK auch:

Time per request:       56.10 [ms] (mean)
Time per request:       1.87 [ms] (mean, across all concurrent requests)

Connnection Times (ms)
              min   avg   max
Connect:        0     2     4
Processing:    30    47   106
Total:         30    49   108

Aber ab startet AFAIK viele Threads die parallel arbeiten. Vielleicht liegt es daran.

Grüße
Andreas

[Andreas Korthaus]

Hallo!

Jetzt geht es ans Optimieren von Datenbanken bzw. Querys. Das ist aber kein Softwareproblem.

Außer den normalen Optimierungen wie Indexe (?), kleinst mögliches Spaltenformat..., könnte man je nach Situation auch noch folgende Sachen machen (zumindest wenn es vergleichsweise wenige Daten sind):

• bei MySQL evtl. HEAP als Tabellentreiber verwenden (aber vorsicht, Daten werden nur im RAM gespeichert und gehen verloren wenn MySQL beendet wird, also noch irgendwo anders speichern, ist dafür optimiert für schnellen Zugriff)

• oder evtl. MyISAM Tabellen einem Dateisystem im RAM ablegen, z.B. tmpfs (gilt dasselbe wie bei HEAP -> Datenverlust)

• evtl. Daten in einer für die Abfrage optimierten Struktur speichern, Du könntest also die Dten parallel pflegen, einmal in einer schön ordentlich normalisierten Struktur, und einmal optimiert, am besten in einer Tabelle die dann im RAM liegt (hängt stark von den Daten ab ob und wie das am besten funktioniert).

Und halt auf PHP-Ebene Cachen. Aber nicht mit einem Cache in PHP implementiert, das bringt nur einiges bei sehr komplexen Datenbank-Abfragen die selber sehr lange dauern. Einen viel besseren Effekt bekommt man, wenn man Caches (in C geschrieben) im SHM verwendet, wie es z.B. eAccelerator und auch memcached ermöglichen, mal 3 Beispiele:

<?php  
// so lange soll lokal gecached werden  
define('CACHE_TTL', 1800);  
  
// Content-Cache: fertige HTML-Ausgabe im SHM für x Sekunden cachen  
// (PHP wird maximal alle X Sekunden neu ausgeführt und für X Sekunden gecached)  
eaccelerator_cache_page($_SERVER['PHP_SELF'].'?GET='.serialize($_GET), CACHE_TTL);  
  
// Datensatz aus der DB bzw. Memcached lesen  
// (benötigt memcached, einen speziellen Caching-Daemon)  
function &get_memcache_Data($id, $db, $memcache) {  
    $cached_data =& $memcache->get($id);  
    if ($cached_data) return $cached_data;  
    $res = $db->query("SELECT test1, test2... FROM table WHERE id='$id'");  
    $data = $res->fetchRow();  
    $memcache->set($id, $data, CACHE_TTL);  
    return $data;  
}  
  
// Datensatz aus der DB bzw. eAccelerator-Cache lesen  
function &get_eaccelerator_data($id, $db) {  
    $cached_data =& eaccelerator_get($id);  
    if ($cached_data) return $cached_data;  
    $res = $db->query("SELECT test1, test2... FROM table WHERE id='$id'");  
    $data = $res->fetchRow();  
    eaccelerator_put($id, $data, CACHE_TTL);  
    return $data;  
}  
?>

Die Referenzen brauchst wenn Du für die Daten Arrays verwendest (dürfte minimal schneller sein als Objekte), oder wenn Du Objekte in PHP4 verwendest. Du solltest Apache und PHP statisch kompilieren, oder wenigstens PHP mit --prefer-non-pic kompilieren, siehe auch http://talks.php.net/show/perf-oscom4/6 (PHP-Version muss entsprechend neu sein).

eAccelerator README (API-Dokumentation): http://cvs.sourceforge.net/viewcvs.py/eaccelerator/eaccelerator/README?rev=1.7&view=auto
PECL::memcached example.php: http://cvs.php.net/co.php/pecl/memcache/example.php
Ein interessantes HOWTO bzgl. PHP-Optimierungen: http://phplens.com/lens/php-book/optimizing-debugging-php.php

Würd mich hinterher mal interessieren was Du einsetzen kannst und wie sich welche Maßnahme gelohnt hat ;-)

Grüße
Andreas

[Anonymous]

[...] wie Indexe (?), [...]

Indexes (englisch) oder Indizes.

[Reiner]

[...] wie Indexe (?), [...]

Indexes (englisch) oder Indizes.

war wahrscheinlich auch der einzige Punkt zu dem Du überhaupt was sagen konntest, gell?!

Gruß
Reiner

[Anonymous]

[...] wie Indexe (?), [...]

Indexes (englisch) oder Indizes.

war wahrscheinlich auch der einzige Punkt zu dem Du überhaupt was sagen konntest, gell?!

*gähn*
Streng dich bitte etwas mehr an. Wenn du mich schon anmachen willst, dann gib dir bitte auch etwas Mühe und sei kreativ.

[Andreas Korthaus]

Hallo Reiner!

war wahrscheinlich auch der einzige Punkt zu dem Du überhaupt was sagen konntest, gell?!

Naja, sowas bringt halt die Anonymität des Internets mit sich (typische Reaktion von Leuten die auf einmal richtig "mutig" werden weil sie sich im Internet endlich hinter der Anonymität verstecken können...). Aber das wurde ja schon oft genug diskutiert.

Grüße
Andreas

[Anonymous]

war wahrscheinlich auch der einzige Punkt zu dem Du überhaupt was sagen konntest, gell?!

Naja, sowas bringt halt die Anonymität des Internets mit sich (typische Reaktion von Leuten die auf einmal richtig "mutig" werden weil sie sich im Internet endlich hinter der Anonymität verstecken können...). Aber das wurde ja schon oft genug diskutiert.

Der war auch nicht viel besser.

[Reiner]

war wahrscheinlich auch der einzige Punkt zu dem Du überhaupt was sagen konntest, gell?!

Naja, sowas bringt halt die Anonymität des Internets mit sich (typische Reaktion von Leuten die auf einmal richtig "mutig" werden weil sie sich im Internet endlich hinter der Anonymität verstecken können...). Aber das wurde ja schon oft genug diskutiert.

Der war auch nicht viel besser.

Wer ist mit _der_ gemeint?

[Anonymous]

Der war auch nicht viel besser.

Wer ist mit _der_ gemeint?

Der Versuch.

[Andreas Korthaus]

Hallo Reiner, hallo Anonymous,

Der war auch nicht viel besser.

Wer ist mit _der_ gemeint?

Der Versuch.

Warum müssen interessante Threads immer in solchen sinnlosen Diskussionen enden? Ich würde vorschlagen, dass wir es hiermit auf sich beruhen lassen. Bitte.

Grüße
Andreas

[Reiner]

Hi Andreas,

Der war auch nicht viel besser.

Wer ist mit _der_ gemeint?

Der Versuch.

Warum müssen interessante Threads immer in solchen sinnlosen Diskussionen enden? Ich würde vorschlagen, dass wir es hiermit auf sich beruhen lassen. Bitte.

Gerne!

Ich hätte auch direkt eine Frage zum letzten Schritt:
Querys.

Explain:

EXPLAIN SELECT DISTINCT a,b,c,.....
FROM res, res_text, (
SELECT res_words.res_id, res_words.rank
FROM words, res_words
WHERE word LIKE '%irgendwas%'
AND words.id = res_words.word_id
) AS wort
WHERE server_id =1
AND res.id = res_text.res_id
AND res.id = wort.res_id
GROUP BY res.id
ORDER BY score DESC , id ASC

Ergebnis ist:

meine Bezeichnung|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra

A|1|PRIMARY|<derived2>|ALL|NULL|NULL|NULL|NULL|35996|Using temporary; Using filesort

B|1|PRIMARY|res|eq_ref|PRIMARY|PRIMARY|8|wort.res_id|1|Using where

C|1|PRIMARY|res_text|eq_ref|PRIMARY|PRIMARY|8|node.res.id|1|--

D|2|DERIVED|words|All|PRIMARY|NULL|NULL|NULL|199878|Using where

E|2|DERIVED|res_words|ref|word_id|word_id|4|node.words.id|10

Details:
A ist ok, muß ein Tablescan sein, wg. "like '%xxx%'" ist so gewollt!
B und C sind sowieso gut.
D macht mir Kopfweh:
Obwohl ist auf die derived-Tabelle zugreife(/n will?), ist das Resultset größer als die Anzahl der Rows des subselects (siehe A).
Zudem kommt ein Index nicht zum tragen.

Was mache ich da falsch?

Viele Grüße,
Reiner

[Reiner]

etwas übersichtlicher, was explain ausgibt...

Explain:

EXPLAIN SELECT DISTINCT a,b,c,.....
FROM res, res_text,
(
SELECT res_words.res_id, res_words.rank
FROM words, res_words
(A)
WHERE word LIKE '%irgendwas%'
(B)
AND words.id = res_words.word_id
) AS wort
WHERE server_id =1
(C)
AND res.id = res_text.res_id
(D) (woher kommt eigentlich (E)?)
AND res.id = wort.res_id
GROUP BY res.id
ORDER BY score DESC , id ASC

Ergebnis ist:

meine Bezeichnung|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra

A|1|PRIMARY|<derived2>|ALL|NULL|NULL|NULL|NULL|35996|Using temporary; Using filesort

B|1|PRIMARY|res|eq_ref|PRIMARY|PRIMARY|8|wort.res_id|1|Using where

C|1|PRIMARY|res_text|eq_ref|PRIMARY|PRIMARY|8|node.res.id|1|--

D|2|DERIVED|words|All|PRIMARY|NULL|NULL|NULL|199878|Using where

E|2|DERIVED|res_words|ref|word_id|word_id|4|node.words.id|10

[Reiner]

res.id = wort.res_id
ist -denke ich- das Problem, oder?
wort.res_id liefert ja eine Liste.

Ich probiere mal einen einfachen join, ist wahrscheinlich effektiver.

Danke fürs zuhören! ;-))

Gruß
Reiner

[Andreas Korthaus]

Hi!

Naja, ich bin nicht wirklich der große Datenbank-Optimierungs Experte ;-)

Nur fürs Verständnis, Du hast eine Tabelle mit viel Text in der Spalte "word". Jeder Datensatz verfügt über eine res_id (die nicht unique ist), wozu Du in zwei anderen Tabellen zusätzliche Informationen gespeichert hast. Jetzt hast Du also einen Suchbegriff ("irgendwas"), und willst jetzt diese zusätzlichen Informationen abfragen, die den Datensätzen mit der res_id zugeordent sind, wo der Suchbegriff "irgendwas" irgendwo im langen Text enthalten ist. War das grob richtig?

In dem Fall würde ich als erstes mal einen richtigen FULLTEXT Index nehmen, und nicht LIKE (alternativ alle Substrings der Wörter in einer indizierten Tabelel speichern, so ähnlich wie bei der neuen SELF-Suche von Daniela - AFAIK).

EXPLAIN SELECT DISTINCT a,b,c,.....

hm, muss das DISTINCT hier sein?
a,b,c bei GROUP BY?

FROM res, res_text,

Du solltest Dir vielleicht besser einen optimalen JOIN-Typ überlegen und angeben

(
SELECT res_words.res_id, res_words.rank
FROM words, res_words
(A)
WHERE word LIKE '%irgendwas%'

Todsünde ;-)
Warum keinen Volltext-Index?
Kannst Du auf die Subquery nicht verzichten?

(B)
AND words.id = res_words.word_id
) AS wort
WHERE server_id =1
(C)
AND res.id = res_text.res_id
(D) (woher kommt eigentlich (E)?)

hat vermutlich mit "Using temporary; " zu tun, oder?

AND res.id = wort.res_id
GROUP BY res.id
ORDER BY score DESC , id ASC

Ergebnis ist:

meine Bezeichnung|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra

A|1|PRIMARY|<derived2>|ALL|NULL|NULL|NULL|NULL|35996|Using temporary; Using filesort

das ist schlecht! Er muss eine nichtmal so kleine temporäre Tabelle erstellen, wenn ich das richtig interpretiere, und kann entsprechend auch keinen Index verwenden.

D|2|DERIVED|words|All|PRIMARY|NULL|NULL|NULL|199878|Using where

auch nicht gut, das kommt vermutlich von LIKE %...%.

Wieso kannst Du nicht einfach einen FULLTEXT-Index auf "word" legen, diese Spalte abfragen, und dann per LEFT JOINs anhand von res_id den zugehörigen Rest auslesen?

Wenn das nicht geht, würde ich mir überlegen eine HEAP-Tabelle mit passenden Daten als Index zu erstellen.

Grüße
Andreas

[Reiner]

Hi!

Naja, ich bin nicht wirklich der große Datenbank-Optimierungs Experte ;-)

Ich auch noch nicht!

Nur fürs Verständnis, Du hast eine Tabelle mit viel Text in der Spalte "word". Jeder Datensatz verfügt über eine res_id (die nicht unique ist), wozu Du in zwei anderen Tabellen zusätzliche Informationen gespeichert hast. Jetzt hast Du also einen Suchbegriff ("irgendwas"), und willst jetzt diese zusätzlichen Informationen abfragen, die den Datensätzen mit der res_id zugeordent sind, wo der Suchbegriff "irgendwas" irgendwo im langen Text enthalten ist. War das grob richtig?

Mal ganz grob, gibt es eine Tabelle, die Texte enthält, aus der werden Worte in eine andere Tabelle herausgesplittet und einem Rank zugeordnet.

In dem Fall würde ich als erstes mal einen richtigen FULLTEXT Index nehmen, und nicht LIKE (alternativ alle Substrings der Wörter in einer indizierten Tabelel speichern, so ähnlich wie bei der neuen SELF-Suche von Daniela - AFAIK).

EXPLAIN SELECT DISTINCT a,b,c,.....

hm, muss das DISTINCT hier sein?
a,b,c bei GROUP BY?

Stimmt, ist doppelt gemoppelt.

FROM res, res_text,

Du solltest Dir vielleicht besser einen optimalen JOIN-Typ überlegen und angeben

(
SELECT res_words.res_id, res_words.rank
FROM words, res_words
(A)
WHERE word LIKE '%irgendwas%'

Todsünde ;-)
Warum keinen Volltext-Index?

Weil wir ein "pensch"-Feature *) benötigen.
Zudem ist der Volltext bei sehr großen Datenmengen nicht besonders effektiv.

*) "pensch" kommt innerhalb von "Lampenschirm" vor.
Mit einem Volltextindex kann über eine boolsche Suche höchstens "lampe" als Treffer gefunden werden.

Kannst Du auf die Subquery nicht verzichten?

(B)
AND words.id = res_words.word_id
) AS wort
WHERE server_id =1
(C)
AND res.id = res_text.res_id
(D) (woher kommt eigentlich (E)?)

hat vermutlich mit "Using temporary; " zu tun, oder?

AND res.id = wort.res_id
GROUP BY res.id
ORDER BY score DESC , id ASC

Ergebnis ist:

meine Bezeichnung|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra

A|1|PRIMARY|<derived2>|ALL|NULL|NULL|NULL|NULL|35996|Using temporary; Using filesort

das ist schlecht! Er muss eine nichtmal so kleine temporäre Tabelle erstellen, wenn ich das richtig interpretiere, und kann entsprechend auch keinen Index verwenden.

D|2|DERIVED|words|All|PRIMARY|NULL|NULL|NULL|199878|Using where
auch nicht gut, das kommt vermutlich von LIKE %...%.

Wieso kannst Du nicht einfach einen FULLTEXT-Index auf "word" legen, diese Spalte abfragen, und dann per LEFT JOINs anhand von res_id den zugehörigen Rest auslesen?

Volltext kommt aus obigen Grund nicht in Frage. Zudem ist mindest. eine wichtige Tabelle aus Geschwindigkeitsgründen eine Heap-Tab.
Bei denen funktioniert ein Volltext nicht!

Der Table-Scan am Anfang macht auch nichts, denn die Tabelle ist gegenüber dem Gesamtvolumen der Daten sehr klein.
Ich kann den Table-Scan durch einen kleinen Trick auch noch unterbinden (Stichwort: soundex).

Wenn das nicht geht, würde ich mir überlegen eine HEAP-Tabelle mit passenden Daten als Index zu erstellen.

Genau! ;-)

Gruß
Reiner

[Anonymous]

WHERE word LIKE '%irgendwas%'

Todsünde ;-)
Warum keinen Volltext-Index?

Weil wir ein "pensch"-Feature *) benötigen.

Warum macht ihr dann nicht einen Index, bei dem jedes Wort Buchstabenweise vorne verkürt wird? Beispiel: Lampenschirm im Index gäbe die Einträge Lampenschirm, ampenschirm, mpenschirm, penschirm, enschirm, nschirm, schirm, chirm, hirm, irm (ich würde bei drei Buchstaben aufhören). Dadurch kann die Datenbank trotzdem noch den Baum-Index nutzen und du bekommst deine O(ld n)-Ordnung.

[Reiner]

WHERE word LIKE '%irgendwas%'

Todsünde ;-)
Warum keinen Volltext-Index?

Weil wir ein "pensch"-Feature *) benötigen.

Warum macht ihr dann nicht einen Index, bei dem jedes Wort Buchstabenweise vorne verkürt wird? Beispiel: Lampenschirm im Index gäbe die Einträge Lampenschirm, ampenschirm, mpenschirm, penschirm, enschirm, nschirm, schirm, chirm, hirm, irm (ich würde bei drei Buchstaben aufhören). Dadurch kann die Datenbank trotzdem noch den Baum-Index nutzen und du bekommst deine O(ld n)-Ordnung.

Die Idee hatte ich auch (und ist auch nicht verworfen bisher), aber das ist ein zeitliches Problem. Selbst mit sehr starken Rechnern dauert das Stunden, um das aufzubauen. Und leider muß das regelmäßig gemacht werden.

Gruß
Reiner

[Anonymous]

Weil wir ein "pensch"-Feature *) benötigen.

Warum macht ihr dann nicht einen Index, bei dem jedes Wort Buchstabenweise vorne verkürt wird? Beispiel: Lampenschirm im Index gäbe die Einträge Lampenschirm, ampenschirm, mpenschirm, penschirm, enschirm, nschirm, schirm, chirm, hirm, irm (ich würde bei drei Buchstaben aufhören). Dadurch kann die Datenbank trotzdem noch den Baum-Index nutzen und du bekommst deine O(ld n)-Ordnung.

Die Idee hatte ich auch (und ist auch nicht verworfen bisher), aber das ist ein zeitliches Problem. Selbst mit sehr starken Rechnern dauert das Stunden, um das aufzubauen. Und leider muß das regelmäßig gemacht werden.

Das stimmt, ja. Wenn das regelmäßig neu gemacht werden muss, würde ich zwei Datenbanken machen: eine Datenbank, wo dieser Index aufgebaut wird und eine Datenbank, die gerade "Live" ist. Ist die aufzubauende Datenbank fertig, wird geswitcht.

Alternativ kann man diese Indizes auch inkrementell aufbauen, wenn die alten Datenbestände nicht oder nur kaum ändern. Also immer nur das neue einfügen. Aber dazu müsste man jetzt mehr wissen über die genaueren Umstände.

[Reiner]

Das stimmt, ja. Wenn das regelmäßig neu gemacht werden muss, würde ich zwei Datenbanken machen: eine Datenbank, wo dieser Index aufgebaut wird und eine Datenbank, die gerade "Live" ist. Ist die aufzubauende Datenbank fertig, wird geswitcht.

Alternativ kann man diese Indizes auch inkrementell aufbauen, wenn die alten Datenbestände nicht oder nur kaum ändern. Also immer nur das neue einfügen. Aber dazu müsste man jetzt mehr wissen über die genaueren Umstände.

das sowieso!

[Andreas Korthaus]

Hallo Anonymous,

[...] wie Indexe (?), [...]

Indexes (englisch) oder Indizes.

War mir halt nicht sicher, denn: http://app.mr-check.de/35041c8629ae4a997b2368fac3ff226a/v2.0/Mrcheck.php?SB=Indexe&CID=tanto1, sorry. Ich hoffe Du konntest trotzdem einigermaßen verstehen was ich meinte.

Grüße
Andreas

[Anonymous]

[...] wie Indexe (?), [...]

Indexes (englisch) oder Indizes.

War mir halt nicht sicher, denn: http://app.mr-check.de/35041c8629ae4a997b2368fac3ff226a/v2.0/Mrcheck.php?SB=Indexe&CID=tanto1, sorry. Ich hoffe Du konntest trotzdem einigermaßen verstehen was ich meinte.

Sicher konnte ich. Ich war darauf nur wegen deines Fragezeichens eingegangen. Sollst ja nicht dumm sterben ;-)

[Christoph Zurnieden]

Hi,

womit hast Du gemessen?

Mit pounder.pl von Herrn Schilli!

von 98? Vielleicht ist das Script auch etwas langsam ;-)

Jaja, ich hab' da auch viel vermutet ob der wirklich _grausam_ niedrigen Werte, aber einen kaputten Benchmark?
Oh je, Reiner, da hast Du mich ja schön auf's Glatteis geführt ;-)

Au, halt, verkehrte Stelle im Thread! Ach egal, Andreas, fühl' Dich einfach nicht angesprochen ;-)

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hi,

ich tüftel gerade an etwas, was eine sehr kurze Antwortzeit des Servers erfordert.

Du hast also eine Wette laufen, das Du eine längeren ... äh ... es schneller kannst ... nein, uh ... Du Deinen Webserver schneller Daten rausschicken lassen kannst als Dein Wettpartner? Realtime über's Netz betreiben?

Aber wenn ich Deine Postings so zusammensammel möchtest Du mit einem P4 mit 3GHz und 2GB Speicher 60 Requests/Sekunde parallel bearbeiten können, ja? Da das eine recht kräftige Unterforderung für so einen Boliden darstellt (wenn man mal durchschnittlichen Content annimmt. Was auch immer das sein soll ;-) muß der Flaschenhals woanders liegen. Einiges hast Du ja auch schon erzählt bekommen.

An einer Stelle läßt Du verlautbaren, das eine DB im Spiel ist. Bist Du Dir sicher, das sich diese Abfragen nicht weiter reduzieren und/oder optimieren lassen?
Wenn es viele Daten sind: läßt sich die Menge reduzieren?
Statische Seiten sind naturgemäß schneller: lassen sich die Daten oder wesentliche Teile davon Cachen?
Ist Dein Programm sauber optimiert? Sprich: sind alle Wege so kurz wie möglich und wird stets der passende Algorithmus benutzt?

Bist Du da überall durch und fehlt dann trotzdem noch das letzte Haar kannst Du anfangen mit der Microoptimierung. Oder gleich stärkere Hardware kaufen, das macht auch weniger Kopfschmerzen.

so short

Christoph Zurnieden

[Andreas Korthaus]

Hallo!

Eine ganz andere Sache, heute gibt es bei Zend so ein Live-Event über große skalierbare PHP-Webanwendungen. Ich weiß selbst nicht genau wie das ablaufen wird, ich glaube das wird erst so eine Art Präsentation, mit anschließender Diskussion. Ist zwar nicht direkt auf Dein Problem bezogen, aber sicher nicht uninteressant!

Titel: PHP Rocks! How Signatures Network Builds Highly Scalable Web Sites for Major Music Artists

Beschreibung:  In this WebCast, Signatures' VP Django Bayless will discuss how PHP was used to build these sites, and will share advise on using PHP to build high-volume, scalable Web applications.

Zeitpunkt: Thursday, April 28, 2005, 9am PDT, 12 noon EDT, 16:00 GMT (heute)

Ist kostenlos, aber man muss sich anmelden: http://www.zend.com/webcast.php

Grüße
Andreas

[Andreas Korthaus]

Hallo!

Da sich das Thema im Verlauf des Threads inzwischen sehr weit von den ersten Postings entfernt hat, erlaube ich mir hier mal kurz drauf hinzuweisen.

Ab dem folgenden Posting:

https://forum.selfhtml.org/?t=106313&m=661525

geht es nur noch um die Optimierung von SQL-Abfragen mit Volltextsuche. Vielleicht hat ja jemand von den DB-Profis hier im Forum noch gute Tipps/Ideen ;-)

Viele Grüße
Andreas

PS: Man sollte vielleicht das Thema anpassen wenn die Diskussion in eine vollkommen andere Richtung driftet, nicht jeder mit guten DB-Kenntnissen liest auch gerne PHP/FastCGI Diskussionen bis zum Ende ;-)