aus http://www.heise.de/newsticker/meldung/54666 vom 29.12.:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
wird darüber nachgedacht mal zu einer anderen Sprache zu wechseln, die nicht erst interpretiert werden muss? Dadurch könnte man immerhin auf einen Schlag den Faktor 5 erreichen!
mijobe
On Tue, Jan 04, 2005 at 03:29:52PM +0100, wikipede wrote:
aus http://www.heise.de/newsticker/meldung/54666 vom 29.12.:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
und? Wie lange braucht MW für eine Seite? Vielleicht sind aber auch die anderen 17% dermaßen optimiert dass dort schon das maximum getan ist. Ich bezweifle dass irgendjemand große Lust hat den ganze Code schon wieder neu zu schreiben, obendrein in einer anderen Sprache.
wird darüber nachgedacht mal zu einer anderen Sprache zu wechseln, die nicht erst interpretiert werden muss? Dadurch könnte man immerhin auf einen Schlag den Faktor 5 erreichen!
wirf nicht so mit Zahlen um dich...
ciao, tom
wikipede schrieb:
aus http://www.heise.de/newsticker/meldung/54666 vom 29.12.:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
Mal davon abgesehen, dass Skriptsprachen interpretiert und nicht kompiliert werden, ist das schon wahrscheinlich. PHP ist nicht besonders schnell. Kompilierte Programme sind das schon, dafür aber nicht plattformunabhängig (das sollte MediaWiki aber bitte bleiben), mal abgesehen von Java, das eine Hybridform darstellt, die sowohl relativ schnell als auch plattformunabhängig ist. Dafür ist es aber keine "freie" Software. Grrrr...
wird darüber nachgedacht mal zu einer anderen Sprache zu wechseln, die nicht erst interpretiert werden muss? Dadurch könnte man immerhin auf einen Schlag den Faktor 5 erreichen!
Vorteil: Geschwindigkeitsverbesserung (das wäre schon nicht schlecht) Nachteile: Probleme mit Plattformunabhängigkeit (also entweder Skript oder VM), Lizenz der Software (also doch eher nicht VM) und einer unglaublichen Mehrarbeit (da ohnehin Skriptsprache, warum dann nicht PHP? [Perl wäre evtl. eine Alternative, ich kenne die Perfomance-Unterschiede der beiden allerdings nicht genau]).
Julian Waldner (alias Serpens)
Julian Waldner wrote:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
Mal davon abgesehen, dass Skriptsprachen interpretiert und nicht kompiliert werden, ist das schon wahrscheinlich.
Guggst du hier: http://www.php-faq.de/q/q-php4-neu.html
Dann findest du dort: "PHP4/Zend ist ein Bytecode-Compiler, der beim Programmstart aufgerufen wird und das komplette Programm in eine interne Darstellung einer virtuellen Maschine überführt. Danach beginnt die Interpretation des Bytecodes der VM. Dies ist dasselbe Funktionsprinzip wie bei Perl, und ganz ähnlich dem Funktionsprinzip von Java, nur dass dort der Compiler explizit aufgerufen werden muss."
Gruß, Flups
Hi, also Perl ist sicher keine Alternative. Höchstens Python. Dürfte schneller sein, vor allem weil man die Sourcen vorcompilieren kann. Einen direkten Vergleich zu PHP kann ich aber nicht machen. Weiterer Vorteil ist noch das Python von Anfang an objektorinetiert war, PHP soweit ich weiß kann das erst seit PHP5. Aber wer will ein Projekt von einem solchen Ausmaß portieren?
Gruß Markus
Julian Waldner schrieb:
wikipede schrieb:
aus http://www.heise.de/newsticker/meldung/54666 vom 29.12.:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
Mal davon abgesehen, dass Skriptsprachen interpretiert und nicht kompiliert werden, ist das schon wahrscheinlich. PHP ist nicht besonders schnell. Kompilierte Programme sind das schon, dafür aber nicht plattformunabhängig (das sollte MediaWiki aber bitte bleiben), mal abgesehen von Java, das eine Hybridform darstellt, die sowohl relativ schnell als auch plattformunabhängig ist. Dafür ist es aber keine "freie" Software. Grrrr...
wird darüber nachgedacht mal zu einer anderen Sprache zu wechseln, die nicht erst interpretiert werden muss? Dadurch könnte man immerhin auf einen Schlag den Faktor 5 erreichen!
Vorteil: Geschwindigkeitsverbesserung (das wäre schon nicht schlecht) Nachteile: Probleme mit Plattformunabhängigkeit (also entweder Skript oder VM), Lizenz der Software (also doch eher nicht VM) und einer unglaublichen Mehrarbeit (da ohnehin Skriptsprache, warum dann nicht PHP? [Perl wäre evtl. eine Alternative, ich kenne die Perfomance-Unterschiede der beiden allerdings nicht genau]).
Julian Waldner (alias Serpens)
WikiDE-l mailing list WikiDE-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikide-l
On Tue, Jan 04, 2005 at 04:02:44PM +0100, Markus Burrer wrote:
Hi, also Perl ist sicher keine Alternative. Höchstens Python. Dürfte schneller sein, vor allem weil man die Sourcen vorcompilieren kann. Einen direkten Vergleich zu PHP kann ich aber nicht machen. Weiterer Vorteil ist noch das Python von Anfang an objektorinetiert war, PHP soweit ich weiß kann das erst seit PHP5. Aber wer will ein Projekt von einem solchen Ausmaß portieren?
Hallo,
ich habe sehr gute Erfahrung mit Python+Quixote+SCGI gemacht. Mehrere Workerprozesse arbeiten die ankommenden Requests ab. Es muss also weder Script-Code noch vorkompilierter Bytecode geladen werden.
Außerdem werden keine neuen Prozesse gestartet, was die Serverlast ebenfalls gering hält.
Python finde ich außerdem gut, weil der Quelltext leicht lesbar ist.
Gruß, Thomas
On Tue, 04 Jan 2005 15:44:20 +0100, Julian Waldner wrote:
wikipede schrieb:
aus http://www.heise.de/newsticker/meldung/54666 vom 29.12.:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
Mal davon abgesehen, dass Skriptsprachen interpretiert und nicht kompiliert werden, ist das schon wahrscheinlich. PHP ist nicht besonders schnell.
Stimmt so nicht, bei MediaWiki wird AFAIK das ganze in Bytecode umkompiliert.
Kompilierte Programme sind das schon, dafür aber nicht plattformunabhängig (das sollte MediaWiki aber bitte bleiben), mal abgesehen von Java, das eine Hybridform darstellt, die sowohl relativ schnell als auch plattformunabhängig ist. Dafür ist es aber keine "freie" Software. Grrrr...
- Java ist nicht nur relativ schnell, sondern schnell. - Java ist keine Software, sondern eine Spezifikation. Was Du meinst sind die JVM und der Kompiler von SUN/IBM. Es gibt aber auch andere Anbieter solcher Software, wie z.B. Blackdown. Ausserdem sehe ich hier nicht wirklich das Problem.
wird darüber nachgedacht mal zu einer anderen Sprache zu wechseln, die nicht erst interpretiert werden muss? Dadurch könnte man immerhin auf einen Schlag den Faktor 5 erreichen!
Vorteil: Geschwindigkeitsverbesserung (das wäre schon nicht schlecht) Nachteile: Probleme mit Plattformunabhängigkeit (also entweder Skript oder VM), Lizenz der Software (also doch eher nicht VM) und einer unglaublichen Mehrarbeit (da ohnehin Skriptsprache, warum dann nicht PHP? [Perl wäre evtl. eine Alternative, ich kenne die Perfomance-Unterschiede der beiden allerdings nicht genau]).
Fuer mich ein wichtiger Grund waeren die immer wieder aufpoppenden Sicherheitsloecher bei PHP. Java haette da vom Grundkonzept her schon eine sicherere Basis.
Allerdings sehe ich nicht die Moeglichkeit, die Sprache in der das ganze System erstellt wurde, zu wechseln. Schliesslich wuerde das ja dazu fuehren, dass man das komplette Entwicklerteam auswechseln wuerde, bzw. (da es ja ein offenes System ist) sich die beiden Entwicklerteams gegenseitig bekriegen.
Gruesse, Lothar
On Tue, Jan 04, 2005 at 10:55:35PM +0100, Lothar Kimmeringer wrote:
Fuer mich ein wichtiger Grund waeren die immer wieder aufpoppenden Sicherheitsloecher bei PHP. Java haette da vom Grundkonzept her schon eine sicherere Basis.
Ach bei WP kämpfen wir doch mehr mit menschlichen Fehlern als mit Programmierfehlern. Mediawiki ist eh schon gegen die meisten Sachen immun, die Server laufen schon länger nur noch ohne register_globals.
Mit Java kann (in 21 Tagen *g) auch Scheiße programmieren. x ciao, tom
Am Dienstag, den 04.01.2005, 23:30 +0100 schrieb Thomas R. Koll:
On Tue, Jan 04, 2005 at 10:55:35PM +0100, Lothar Kimmeringer wrote:
Fuer mich ein wichtiger Grund waeren die immer wieder aufpoppenden Sicherheitsloecher bei PHP. Java haette da vom Grundkonzept her schon eine sicherere Basis.
Ach bei WP kämpfen wir doch mehr mit menschlichen Fehlern als mit Programmierfehlern.
Hat sich schon jemand angeschaut, ob an der Befürchtung bezüglich SQL-Injection in http://groups.google.de/groups?selm=87fz3cxkcq.fsf%40deneb.enyo.de was dran ist?
Matthias
On Tue, Jan 04, 2005 at 11:49:21PM +0100, Matthias Richter wrote:
Hat sich schon jemand angeschaut, ob an der Befürchtung bezüglich SQL-Injection in http://groups.google.de/groups?selm=87fz3cxkcq.fsf%40deneb.enyo.de was dran ist?
In HISTORY Version 1.3.6, 2004-10-14 steht folgendes: * Fix SQL injection and cross site scripting bugs in SpecialMaintenance
Ist auch das einzige mal dass es erwähnt wird.
ciao, tom
Am Tue, 4 Jan 2005 23:30:58 +0100 schrieb Thomas R. Koll:
On Tue, Jan 04, 2005 at 10:55:35PM +0100, Lothar Kimmeringer wrote:
Fuer mich ein wichtiger Grund waeren die immer wieder aufpoppenden Sicherheitsloecher bei PHP. Java haette da vom Grundkonzept her schon eine sicherere Basis.
Ach bei WP kämpfen wir doch mehr mit menschlichen Fehlern als mit Programmierfehlern. Mediawiki ist eh schon gegen die meisten Sachen immun, die Server laufen schon länger nur noch ohne register_globals.
Naja, wenn WP wirklich ein Problem mit register_globals haette, waeren die Entwickler dem Spott der (computerisierten) Welt sicher gewesen ;-)
Mit Java kann (in 21 Tagen *g) auch Scheiße programmieren.
Real Programmers can program FORTRAN in all languages. s/Real Programmers/Consultants/ s/FORTRAN/shit/
Allerdings ist die Wahrscheinlichkeit bei Verwendung von VB am groessten (mag aber auch damit zusammenhaengen, dass die meissten Berater auf VB schwoeren).
Siehe z.B. bei http://thedailywtf.com/ShowPost.aspx?PostID=27203 Wie gesagt ist da aber keine Sprache davor gefeit: http://thedailywtf.com/ShowPost.aspx?PostID=27338 Allerdings hat es PHP dabei zu einer eigenen Website gebracht: http://www.thephpwtf.com/
Das soll jetzt aber kein Flamebait gegen die verschiedenen Programmiersprachen werden. Ich persoenlich bevorzuge halt Java bei der Entwicklung, da es plattformuebergreifend und trotzdem schnell ist (durch den Hotspot kein sonderlich grosser Unterschied zu C). Dass es auch fuer groessere Plattformen ein- setzbar ist, hat Ebay meiner Ansicht nach bewiesen, wobei ich aber nicht weiss, welche Hardware da konkret im Einsatz ist.
Gruesse, Lothar
wikipede wrote:
aus http://www.heise.de/newsticker/meldung/54666 vom 29.12.:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
wird darüber nachgedacht mal zu einer anderen Sprache zu wechseln, die nicht erst interpretiert werden muss? Dadurch könnte man immerhin auf einen Schlag den Faktor 5 erreichen!
Der Text ist missverständlich. Da schon seit (wann? Ewigkeiten?) ein Cache (Turck) im Einsatz ist, betrifft uns wenigstens dieser PHP-Terror nicht.
Ansonsten ist dein "auf einen Schlag Faktor 5" Unsinn, er ignoriert die Feinarbeit nach 4 Jahren PHP.
Niemand wird sich gegen einen Umstieg auf eine andere Lösung wehren, wenn jemand morgen vorbeikäme und eine funktionierende, schnelle, sichere, skalierende, tolle Lösung präsentierte, oder?
Grüße, Mathias (der diese Phantomdebatte für nutzlos hält und sich selbst für unwissend, konkrete Lösungsvorschläge anzubieten)
Mathias Schindler wrote:
wikipede wrote:
aus http://www.heise.de/newsticker/meldung/54666 vom 29.12.:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
wird darüber nachgedacht mal zu einer anderen Sprache zu wechseln, die nicht erst interpretiert werden muss? Dadurch könnte man immerhin auf einen Schlag den Faktor 5 erreichen!
Der Text ist missverständlich. Da schon seit (wann? Ewigkeiten?) ein Cache (Turck) im Einsatz ist, betrifft uns wenigstens dieser PHP-Terror nicht.
Ansonsten ist dein "auf einen Schlag Faktor 5" Unsinn, er ignoriert die Feinarbeit nach 4 Jahren PHP.
Feinarbeit an 17%. Das heißt das 83% der Serverlast hausgemacht sind.
Niemand wird sich gegen einen Umstieg auf eine andere Lösung wehren, wenn jemand morgen vorbeikäme und eine funktionierende, schnelle, sichere, skalierende, tolle Lösung präsentierte, oder?
Das wird sicherlich niemand tun. Die Frage ist doch wohl eher ob man bei MediaWiki 1.5 wieder bei PHP bleibt, oder einen Schwenk auf eine andere Sprache macht. Die Umstellung ist sicher aufwändig, aber genauso sicher wird sie noch aufwändiger, wenn man noch länger wartet. Vielleicht lohnt ja auch ein Blick auf andere Wikis, die man erweitern kann.
Grüße, Mathias (der diese Phantomdebatte für nutzlos hält und sich selbst für unwissend, konkrete Lösungsvorschläge anzubieten)
Konkrete Lösungsvorschläge kann ich zwar auch nicht machen, aber einfach den Kopf in den Sand zu stecken hilft wohl kaum weiter.
Wenn ich nicht irre gibt es doch bereits ein Wiki, dass in C, C++ oder C# geschrieben ist. Da müßte man nicht bei Null anfangen.
mijobe
WikiDE-l mailing list WikiDE-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikide-l
On Tue, Jan 04, 2005 at 04:01:06PM +0100, wikipede wrote:
wird sie noch aufwändiger, wenn man noch länger wartet. Vielleicht lohnt ja auch ein Blick auf andere Wikis, die man erweitern kann.
Du wirst dir schwer tun ein anderes zu finden. Falls du es nicht gemerkt hast, aber MediaWiki wird immer mehr zum Standard. Nicht nur dass damit die größten Wikis überhaupt damit laufen sondern diese auch noch auf einer gemeinsamen Serverfarm.
ciao, tom
Das wird sicherlich niemand tun. Die Frage ist doch wohl eher ob man bei MediaWiki 1.5 wieder bei PHP bleibt, oder einen Schwenk auf eine andere Sprache macht. Die Umstellung ist sicher aufwändig, aber genauso sicher wird sie noch aufwändiger, wenn man noch länger wartet. Vielleicht lohnt ja auch ein Blick auf andere Wikis, die man erweitern kann.
Die funktionieren nur deshalb so gut, weil sie kaum jemand benutzt. Ich bin mir ziemlich sicher, dass es derzeit keine Wiki-Software gibt, die so viel aushält wie Mediawiki.
In übrigen ist unser Hauptproblem derzeit nicht die Geschwindigkeit, sondern der Speicherplatz. Dummerweise gab es da mal eine Politik (die ich damals wohl besser gleich mit einer Rechnung hätte monieren sollen, die zeigt, wie lange diese Politik gut geht) das Plattenplatz billig ist. Ich gebe der Wikipedia höchstens noch 1-2 Jahre, bevor sie an ihrem Wachstum erstickt. Mit eingerechnet sind dabei sämtlich Unternehmungen, die das Problem versuchen in den Griff zu bekommen. Passiert in der Richtung nichts, haben wir noch 2-3 Monate.
Wenn ich nicht irre gibt es doch bereits ein Wiki, dass in C, C++ oder C# geschrieben ist. Da müßte man nicht bei Null anfangen.
D.h. noch lange nicht, dass es schneller läuft. Aber du kannst mir gerne mal ein paar Links schicken.
--Ivo Köthnig
Ivo Köthnig schrieb:
Wenn ich nicht irre gibt es doch bereits ein Wiki, dass in C, C++ oder C# geschrieben ist. Da müßte man nicht bei Null anfangen.
D.h. noch lange nicht, dass es schneller läuft. Aber du kannst mir gerne mal ein paar Links schicken.
CVS, Modul "waikiki". Läuft direkt mit MediaWiki-Syntax. Hab' ich mal vor einer Weile geschrieben. Ist nur halbfertig und wahrscheinlich voller Fehler, aber wer Zeit und Lust hat, darf sich gerne bedienen...
Magnus
Ivo Köthnig schrieb:
In übrigen ist unser Hauptproblem derzeit nicht die Geschwindigkeit, sondern der Speicherplatz. Dummerweise gab es da mal eine Politik (die ich damals wohl besser gleich mit einer Rechnung hätte monieren sollen, die zeigt, wie lange diese Politik gut geht) das Plattenplatz billig ist. Ich gebe der Wikipedia höchstens noch 1-2 Jahre, bevor sie an ihrem Wachstum erstickt. Mit eingerechnet sind dabei sämtlich Unternehmungen, die das Problem versuchen in den Griff zu bekommen. Passiert in der Richtung nichts, haben wir noch 2-3 Monate.
Könntest Du das etwas ausführen? Was ist genau problematisch an der Thematik Speicherplatz? Fehlt es nun an physischem Speicherplatz (wenn ja, weshalb?), will die Datenbank ab einer bestimmten Größe nicht mehr ... ? Irgendwie konnte ich das Deinem Text nicht so recht entnehmen.
Julian Waldner (alias Serpens)
Am Dienstag, 4. Januar 2005 17:46 schrieb Julian Waldner:
Ivo Köthnig schrieb:
In übrigen ist unser Hauptproblem derzeit nicht die Geschwindigkeit, sondern der Speicherplatz. Dummerweise gab es da mal eine Politik (die ich damals wohl besser gleich mit einer Rechnung hätte monieren sollen, die zeigt, wie lange diese Politik gut geht) das Plattenplatz billig ist. Ich gebe der Wikipedia höchstens noch 1-2 Jahre, bevor sie an ihrem Wachstum erstickt. Mit eingerechnet sind dabei sämtlich Unternehmungen, die das Problem versuchen in den Griff zu bekommen. Passiert in der Richtung nichts, haben wir noch 2-3 Monate.
Könntest Du das etwas ausführen? Was ist genau problematisch an der Thematik Speicherplatz? Fehlt es nun an physischem Speicherplatz (wenn ja, weshalb?), will die Datenbank ab einer bestimmten Größe nicht mehr ... ? Irgendwie konnte ich das Deinem Text nicht so recht entnehmen.
Brion und Tim berichteten in ihrem Vortrag auf dem 21C3 vom Problem des Plattenplatzes. Man ging immer davon aus, dass Plattenplatz billig ist. Wikipedia wächst jedoch exponentiell und hinzu kommt, dass am SCSI-Bus der Server kein Steckplatz für neue Platten mehr frei ist. Wikipedia wäre um ein Haar letztes Wochenende einfach wegen fehlendem Plattenplatz abgestürzt. Durch die Umstellung auf Mediawiki 1.4 wurde die Datenbank auf 15% des vorigen Umfangs komprimiert (vorher wurde aus Gründen der Einfachheit und Performance nichts komprimiert), aufgrund des exponentiellen Wachstums bedeutet das jedoch nur eine Verschnaufpause von nur einen halben Jahr, bevor wir wieder das gleiche Problem haben.
Ein neues Storage-Array kostet nicht gerade wenig Geld und momentan ist Wikimedia am überlegen wie das Problem sinnvoll langfristig gelöst werden kann (zusammen mit anderen wie Load-balancing) bevor man einfach Geld ausgibt und nach einem Jahr wieder vor dem gleichen Problem steht. Und das halbe Jahr Verschnaufpause durch MediaWiki 1.4 sollte da ausreichen.
Grüße, Daniel Arnold (Arnomane)
On Tue, Jan 04, 2005 at 06:34:01PM +0100, Daniel Arnold wrote:
Performance nichts komprimiert), aufgrund des exponentiellen Wachstums bedeutet das jedoch nur eine Verschnaufpause von nur einen halben Jahr, bevor wir wieder das gleiche Problem haben.
Mit dem exponentiellen Wachstum ist aber auch irgendwann Schluss. Natürlich, es gibt mehr als nur einen Wikipedia aber im schlimmsten Fall kriegen die Projekte alle einen eigenen Server.
ciao, tom
Am Dienstag 04 Januar 2005 21:30 schrieb Thomas R. Koll:
On Tue, Jan 04, 2005 at 06:34:01PM +0100, Daniel Arnold wrote:
Performance nichts komprimiert), aufgrund des exponentiellen Wachstums bedeutet das jedoch nur eine Verschnaufpause von nur einen halben Jahr, bevor wir wieder das gleiche Problem haben.
Mit dem exponentiellen Wachstum ist aber auch irgendwann Schluss. Natürlich, es gibt mehr als nur einen Wikipedia aber im schlimmsten Fall kriegen die Projekte alle einen eigenen Server.
Klar, die Frage ist nur: Wann? Die englische Wikipedia wächst nach wie vor exponentiell in der Zahl der Artikel. Die Deutsche wächst seit März nur linear, was aber von verschiedenen Leuten auf besondere Umstände zurückgeführt wird (wie z.B. die Vereinsgründung), die Resourcen bindet.
Die meisten Sprachen stehen wohl erst noch am Anfang ihres Wachstums, zumindest von der französischen und spanischen Wikipedia erwarte ich noch deutlich mehr.
Langfristig sicher wären wir, wenn unser Wachstum höchsten so viel Resourcen mehr verbraucht als das, was die IT-Branche an Neuerungen schafft. Momentan kann man da noch von Moores Law ausgehen, also alle 18 Monate Verdopplung von Rechnerzeit. Bei Speicherplatz sieht es ähnlich aus. Die Basis unseres Wachstums ist derzeit noch viel größer: Verdopplung des Speicherplatzbedarfs alle 16 Wochen. Es ist davon auszugehen, dass das Wachstum noch größer wäre, wenn die Hamster schneller laufen würden.
--Ivo Köthnig
On Wed, Jan 05, 2005 at 03:21:39AM +0100, Ivo Köthnig wrote:
Klar, die Frage ist nur: Wann? Die englische Wikipedia wächst nach wie vor exponentiell in der Zahl der Artikel. Die Deutsche wächst seit März nur linear, was aber von verschiedenen Leuten auf besondere Umstände zurückgeführt wird (wie z.B. die Vereinsgründung), die Resourcen bindet.
Vereinsgründung würd ich nicht sagen. 1. English als Zweitsprache bringt viele stubs aus aller Welt 2. Wir wachsen in der Qualität. Schon jetzt ist unser Durchschnittsartikel länger und der Anteil langer Artikel war bei uns bis November größer (en: hat da einen Sprung gemacht) 3. bei den Bearbeitungen pro Artikel liegen wir vorne, Bots machen aber 1 Bearbeitung pro Artikel aus wodurch wir knapp hinten liegen.
Langfristig sicher wären wir, wenn unser Wachstum höchsten so viel Resourcen mehr verbraucht als das, was die IT-Branche an Neuerungen schafft. Momentan kann man da noch von Moores Law ausgehen, also alle 18 Monate Verdopplung von Rechnerzeit. Bei Speicherplatz sieht es ähnlich aus. Die Basis unseres Wachstums ist derzeit noch viel größer: Verdopplung des Speicherplatzbedarfs alle 16 Wochen. Es ist davon auszugehen, dass das Wachstum noch größer wäre, wenn die Hamster schneller laufen würden.
Ich würd gar nicht mal Moores Law heranziehen weil wir ja die einfach Möglichkeit haben mehr Rechner zu kaufen. Heute werden eh neue Rechner bestellt was uns auch über 30 bringt.
ciao, tom -- == Weblinks == * http://shop.wikipedia.org - WikiReader Internet zu kaufen * http://de.wikipedia.org/wiki/Benutzer:TomK32 * http://www.hammererlehen.de - Urlaub in Berchtesgaden
On Wednesday 05 January 2005 10:22, Thomas R. Koll wrote:
Ich würd gar nicht mal Moores Law heranziehen weil wir ja die einfach Möglichkeit haben mehr Rechner zu kaufen. Heute werden eh neue Rechner bestellt was uns auch über 30 bringt.
Wir verfügen bereits über 40 (37+3 in Frankreich) Rechner, mit den neuen nähern wir uns der 50er Marke.
http://meta.wikimedia.org/wiki/Wikimedia_servers
Viele Grüße, Marco
P.S. die Verdopplung der Transistoren alle 18 Monate bedeutet m.W. nicht, dass sich auch die Rechenleistung alle 18 Monate verdoppelt.
On Wed, Jan 05, 2005 at 12:04:53PM +0100, Marco Krohn wrote:
On Wednesday 05 January 2005 10:22, Thomas R. Koll wrote:
Ich würd gar nicht mal Moores Law heranziehen weil wir ja die einfach Möglichkeit haben mehr Rechner zu kaufen. Heute werden eh neue Rechner bestellt was uns auch über 30 bringt.
Wir verfügen bereits über 40 (37+3 in Frankreich) Rechner, mit den neuen nähern wir uns der 50er Marke.
sag ich doch, über 30 ;-)
ciao, tom
Ich würd gar nicht mal Moores Law heranziehen weil wir ja die einfach Möglichkeit haben mehr Rechner zu kaufen. Heute werden eh neue Rechner bestellt was uns auch über 30 bringt.
Die Zahl der Rechner zu verdoppeln funktioniert aber nur einmal. Vielleicht zwei, drei, oder vier mal... Nur: Irgendwann ist nicht mehr genug Geld da, um dies zu tun. Man könnte höchstens hoffen, dass mit der Zahl der Nutzer auch die Zahl der Spenden exponentiell steigt...
--Ivo Köthnig
Am Mittwoch, 5. Januar 2005 10:22 schrieb Thomas R. Koll:
- Wir wachsen in der Qualität. Schon jetzt ist unser Durchschnittsartikel länger und der Anteil langer Artikel war bei uns bis November größer (en: hat da einen Sprung gemacht)
Nun braucht man aber im Deutschen etwas mehr Text als im Englischen, um das Gleiche zu sagen...
Magnus
Daniel Arnold wrote:
Durch die Umstellung auf Mediawiki 1.4 wurde die Datenbank auf 15% des vorigen Umfangs komprimiert (vorher wurde aus Gründen der Einfachheit und Performance nichts komprimiert), aufgrund des exponentiellen Wachstums bedeutet das jedoch nur eine Verschnaufpause von nur einen halben Jahr, bevor wir wieder das gleiche Problem haben.
Wird in der 1.4 eigentlich immer noch in der History von jeder Version der vollständige Artikel gespeichert?
Flups
Am Mittwoch, 5. Januar 2005 09:20 schrieb Florian Baumann:
Daniel Arnold wrote:
Durch die Umstellung auf Mediawiki 1.4 wurde die Datenbank auf 15% des vorigen Umfangs komprimiert (vorher wurde aus Gründen der Einfachheit und Performance nichts komprimiert), aufgrund des exponentiellen Wachstums bedeutet das jedoch nur eine Verschnaufpause von nur einen halben Jahr, bevor wir wieder das gleiche Problem haben.
Wird in der 1.4 eigentlich immer noch in der History von jeder Version der vollständige Artikel gespeichert?
Dieser Punkt wurde auch von Tim und Brion in ihrem Vortrag angesprochen. In 1.3 wurde in der Tat nicht der Diff, sondern stets immer der gesammte Text einer Version abgespeichert (Einfachheit). In 1.4 verfährt man prinzipiell immer noch genauso. Aber: in 1.4 werden 20 aufeinander folgende Versionen immer zusammen komprimiert, d.h. gleiche Textpasssagen werden eh sehr gut komprimiert. Der Unterschied ob ich jetzt 20 aufeinander folgende Diffs komprimiere oder die entsprechenden 20 kompletten Versionen ist gering (wurde ausprobiert, genauso wie bzip2). Diffs wiederum bedeuten einen Extraaschritt beim Erzeugen des Textes (Zusammenbasteln des Textes aus den einzelnen Diffs, was der Performance auch nicht so zuträglich ist, IMHO).
Das Problem bei Wikipedia ist vor allem, dass Diffs garnicht so viel bringen wie bei Software im Versionskontrollsystem CVS, da die Artikel mit der größten Versionsgeschichte meist aufgrund Editwars entstehen und bei einem Editwar gibt es häufig radikale Löschungen und Einfügungen großer Textpassagen, bis hin zum Extrem des kompletten Leerens und Wiederaufüllens eines Artikels. D.h. Diff ist zwar besser als alle Versionen unkomprimiert einzelnen zu speichern aber doch sehr suboptimal. Jemand aus dem Publikum hatte einen anderen Diff-Algorithmus namens X-Delta vorgeschlagen (und die Entwickler meinten dann, dass sie sich den Tipp mal angucken würden). Ich habe jedoch keine Ahnung was X-Delta genau ist.
Grüße, Daniel Arnold (Arnomane)
Hallo Daniel,
Das Problem bei Wikipedia ist vor allem, dass Diffs garnicht so viel bringen wie bei Software im Versionskontrollsystem CVS, da die Artikel mit der größten Versionsgeschichte meist aufgrund Editwars entstehen und bei einem Editwar gibt es häufig radikale Löschungen und Einfügungen großer Textpassagen, bis hin zum Extrem des kompletten Leerens und Wiederaufüllens eines Artikels.
Ich glaube nicht, dass die paar Editwars für das Speicherplatzwachstum verantwortlich sind. Sicher sind das tendenziell die Artikel mit der längsten Versionsgeschichte, aber bei der überwiegenden Mehrheit gibt es afaik keine Editwars.
Nur mal so zum nachdenken: Nimm eine bestehende Wikipedia, kategorisiere alle Artikel und die Datenbank ist hinterher doppelt so groß. Naja so ungefähr.
Flups
Am Dienstag, 4. Januar 2005 15:29 schrieb wikipede:
aus http://www.heise.de/newsticker/meldung/54666 vom 29.12.:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
wird darüber nachgedacht mal zu einer anderen Sprache zu wechseln, die nicht erst interpretiert werden muss? Dadurch könnte man immerhin auf einen Schlag den Faktor 5 erreichen!
Um mal der ganzen Vermuterei ein Ende zu machen:
Es gab auf dem 21C3 einen Vortrag von Brion Vibber und Tim Starling exakt zu diesem Thema ("Scaling Wikipedia beyond 1 Million", dürfte sich auch im Netz vom CCC als Video runterladen lassen).
Als damals MediaWiki angefangen wurde hat niemand an die extrem hohe heutige Auslastung und an Flaschenhälse in PHP gedacht. Wie sagte Brion so schön (so ziemlich genau O-Ton) : "We simply didn't know it better those days. Well, it's a wiki..." Das heißt heute würde man nicht mehr mit PHP anfangen, aber nun ist die Software einmal da, sie funktioniert und niemand hat Lust auf einen kompletten Neuanfang und neue Bugs.
MediaWiki 1.4 wurde explizit in Hinblick auf die Performance entwickelt. Außerdem wurden und werden rechenintensive Routinen in C/C++ und andere Kompilersprachen ausgelagert, außerdem wird ein PHP-Bytecodecache verwendet, damit nicht andauernd neukompiliert werden muss.
D.h. auch in Zukunft wird das Hauptprogramm in PHP geschrieben bleiben, aber die wirklich rechenintensiven Routinen werden als eine Art Plugin in andere schnellere Sprachen ausgelagert.
Wer sich aufgerufen fühlt was besseres zu schreiben sollte einfach auf irc.freenode.net in den Channel #mediawiki sich einklinken und dort mit den Enwticklern direkt seine Ideen/Code besprechen.
Grüße, Arnomane
Am Dienstag 04 Januar 2005 15:29 schrieb wikipede:
aus http://www.heise.de/newsticker/meldung/54666 vom 29.12.:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
Also zunächst mal ist es ja so, dass sich diese Prozentzahl nur auf die Seiten bezieht, die aus diversen Gründen nicht aus dem Cache geladen werden können, sondern neu (mittels PHP) erstellt werden müssen, zum Beispiel, weil eine Seite geändert wurde.
wird darüber nachgedacht mal zu einer anderen Sprache zu wechseln, die nicht erst interpretiert werden muss? Dadurch könnte man immerhin auf einen Schlag den Faktor 5 erreichen!
Insofern würde eine Optimierung an dieser Stelle also auch nicht um den Faktor 5 beschleunigen, zumal auch eine andere Programiersprache Zeit zum Kompilieren oder Ausführen benötigt. (im übrigen wird PHP tatsächlich kompiliert und nicht wie eine Skriptsprache ausgeführt, und zwar jedesmal wenn es aufgerufen wird. Zumindest hat Brion das auf dem 21C3 behauptet, oder ich hab es dort so verstanden.)
Kommen wir nun zu der Idee auf eine andere Sprache zu portieren:
1. PHP ist relativ weitverbreitet und die Chance Mediawiki bei ISPs laufen lassen zu können ist dadurch höher als bei jeder anderen Sprache.
2. Die Zeit, die zur Portierung benötigt wird ist mit Sicherheit länger als die Zeit, in der unser Wachstum diese Beschleunigung wieder auffrist. Insofern bringt das also im Moment: GARNICHTS. Es bindet nur Resourcen (in diesem Fall Developer) die sowieso schon viel zu knapp sind.
--Ivo Köthnig
Ivo Köthnig wrote:
im übrigen wird PHP tatsächlich kompiliert und nicht wie eine Skriptsprache ausgeführt, und zwar jedesmal wenn es aufgerufen wird.
So ist es. PHP3 war noch eine reine Skript-Sprache, ab PHP4/ZEND wird vorkompiliert.
Kommen wir nun zu der Idee auf eine andere Sprache zu portieren:
- PHP ist relativ weitverbreitet und die Chance Mediawiki bei ISPs laufen
lassen zu können ist dadurch höher als bei jeder anderen Sprache.
Und wofür ist das wichtig? Die Wikipedia läuft auf einer eigenen Serverfarm, auf irgendwelche vorkonfigurieren Webspace-Pakete von irgendwelchen ISPs sind wir nun wirklich nicht angewiesen.
Klar schränkt das die allgemeine Nutzbarkeit von MediaWiki ein. Das ist aber aufgrund ziemlich restriktiver Vorgaben bzw. installierter "Zusatzsoftware" (ImageMagick, TeX und was sonst noch benötigt wird) eh schon der Fall.
Dieses Argument ist nicht wirklich ein Gegenargument.
- Die Zeit, die zur Portierung benötigt wird ist mit Sicherheit länger als
die Zeit, in der unser Wachstum diese Beschleunigung wieder auffrist. Insofern bringt das also im Moment: GARNICHTS. Es bindet nur Resourcen (in diesem Fall Developer) die sowieso schon viel zu knapp sind.
Mag sein, mag nicht sein. Fakt ist, dass von den Developpern zum jetzigen Zeitpunkt keiner portieren will, und das aus gutem Grund! Alle Diskussionen in dieser Richtung sind deshalb müßig. Man weiß auch nicht, wie die PHP-Entwicklung weiter geht...
Flups
- PHP ist relativ weitverbreitet und die Chance Mediawiki bei ISPs laufen
lassen zu können ist dadurch höher als bei jeder anderen Sprache.
Und wofür ist das wichtig? Die Wikipedia läuft auf einer eigenen Serverfarm, auf irgendwelche vorkonfigurieren Webspace-Pakete von irgendwelchen ISPs sind wir nun wirklich nicht angewiesen.
Dafür dass sich mehr Leute mit der Software beschäftigen, was dann auch mehr Developer an Land spülen könnte?
Klar schränkt das die allgemeine Nutzbarkeit von MediaWiki ein. Das ist aber aufgrund ziemlich restriktiver Vorgaben bzw. installierter "Zusatzsoftware" (ImageMagick, TeX und was sonst noch benötigt wird) eh schon der Fall.
Das ist richtig und falsch. Die meisten Sachen gehören sind bei ISPs dann schon noch dabei. TeX vermutlich nicht mehr, aber ImageMagick durchaus. Außerdem kann man Mediawiki größtenteils so konfigurieren, dass man diese Dinge nicht braucht.
--Ivo Köthnig
Am Dienstag, 4. Januar 2005 17:15 schrieb Ivo Köthnig:
Klar schränkt das die allgemeine Nutzbarkeit von MediaWiki ein. Das ist aber aufgrund ziemlich restriktiver Vorgaben bzw. installierter "Zusatzsoftware" (ImageMagick, TeX und was sonst noch benötigt wird) eh schon der Fall.
Das ist richtig und falsch. Die meisten Sachen gehören sind bei ISPs dann schon noch dabei. TeX vermutlich nicht mehr, aber ImageMagick durchaus. Außerdem kann man Mediawiki größtenteils so konfigurieren, dass man diese Dinge nicht braucht.
Um das von Ivo zu konkretisieren: Die derzeitige Marschrichtung (wenn ich das richtig verstanden habe) ist folgende:
Bestimmte Funktionen optional als externes Plugin anbieten, damit sowohl einfache Installation für Installtion auf Rechnern dritter (die die MediaWiki-Software nutzen) ohne große Abhängigkeiten möglich ist, welche dann einfach die alten eingebauten Funktionen nutzen. Nur wer die schnellen neuen externen Routinen braucht wird diese zusätzlich installieren.
Ein Beispiel ist die Suchmaschine, die in Zukunft (MediaWiki 1.5 soweit ich weiß) sowohl intern als auch extern (damit ist nicht Google gemeint, sondern ein Programm auf dem selben Server) sein kann. Intern die alte Suchmaschine in PHP mit Schnittstellen zu SQL (der Datenbanksprache) und extern eine andere (bereits vorhandene) in C oder C++ (soweit ich weiß) welche wesentlich schneller ist und auch besser sein soll. Jemand der für sein kleinen Projekt keine fette Suchmaschine benötigt wird einfach die bisherigen in PHP nutzen, andere die sie benötigen die neue.
Grüße, Daniel Arnold (Arnomane)
Ivo Köthnig wrote:
Klar schränkt das die allgemeine Nutzbarkeit von MediaWiki ein. Das ist aber aufgrund ziemlich restriktiver Vorgaben bzw. installierter "Zusatzsoftware" (ImageMagick, TeX und was sonst noch benötigt wird) eh schon der Fall.
Das ist richtig und falsch. Die meisten Sachen gehören sind bei ISPs dann schon noch dabei. TeX vermutlich nicht mehr, aber ImageMagick durchaus.
MediaWiki ist so resourcenfressend, dass es bei "All inclusive"-Webhostern auch dann nicht läuft. Strato hab ich noch nicht ausprobiert, aber definitiv funzt es nicht bei 1&1 und domain*go.
Außerdem kann man Mediawiki größtenteils so konfigurieren, dass man diese Dinge nicht braucht.
Dann läuft es immer noch nicht, s. o.
Flups
On Wed, Jan 05, 2005 at 09:14:08AM +0100, Florian Baumann wrote:
Ivo Köthnig wrote:
Klar schränkt das die allgemeine Nutzbarkeit von MediaWiki ein. Das ist aber aufgrund ziemlich restriktiver Vorgaben bzw. installierter "Zusatzsoftware" (ImageMagick, TeX und was sonst noch benötigt wird) eh schon der Fall.
Das ist richtig und falsch. Die meisten Sachen gehören sind bei ISPs dann schon noch dabei. TeX vermutlich nicht mehr, aber ImageMagick durchaus.
MediaWiki ist so resourcenfressend, dass es bei "All inclusive"-Webhostern auch dann nicht läuft. Strato hab ich noch nicht ausprobiert, aber definitiv funzt es nicht bei 1&1 und domain*go.
URL? Mein Bonsaiwiki (noch 1.3) läuft ganz gut und factdex.com (nicht meins) welches ich schon auf 1.4 umgestellt habe auch, letzteres ist aber nur ein Mirror der read-only und miser-mode ist. Der Miser-mode hacht einiges aus wie mir vorkam.
ciao, tom
Thomas R. Koll wrote:
MediaWiki ist so resourcenfressend, dass es bei "All inclusive"-Webhostern auch dann nicht läuft. Strato hab ich noch nicht ausprobiert, aber definitiv funzt es nicht bei 1&1 und domain*go.
URL?
Ne URL von 'nem Wiki, das nicht existiert, weil die Software aus Performance-Gründen nicht läuft?
Ich hab meine Versuche, Mediawiki auf 1&1 (Pro-Tarfif) zum Laufen zu bringen, aufgegeben, mein Tarif stammte allerdings auch noch aus puretec-Zeiten.
Flups
wikipede schrieb:
aus http://www.heise.de/newsticker/meldung/54666 vom 29.12.:
PHP ist allerdings recht langsam und wendet bei MediaWiki laut Vibber rund 83 Prozent der Laufzeit für die Code-Kompilierung auf
Dieser eine Satz aus der Feder des Heise-Redakteurs hat bereits für endlose Diskussionen im Heise-Forum gesorgt, meistens mit dem Unterton, dass unsere Admins inkompetent sein müssen. Und warum? Weil dieser Redakteur bei Brions Vortrag nicht richtig zugehört hat. Ich würde ihn am liebsten dafür hauen. Das obige Problem betrifft die Wikipedia-Serverfarm nämlich gar nicht, weil wir einen Bytecode-Cache benutzen. Die 83 % kämen zusammen, wenn wir *keinen* Cache benutzen würden, wie das bei den Otto-Normal-MediaWikis meist der Fall ist.
Dass in der Software noch Optimierungspotenzial steckt, bleibt davon unberührt, klar. Nur dass diese Zahl von 83 % auf Wikipedia bezogen wurde, ärgert mich.
Alwin Meschede