Wikipedia Diskussion:Sorge dich nicht um die Server

Vorschaufunktion

Hallo, kleine Anregung: vielleicht mögt ihr doch noch auf die Nutzung der Vorschaufunktion hinweisen. Wenn jemand nach jedem zweiten Wort zwischenspeichert ist das für die Versionsgeschichte ziemlich unübersichtlich und macht die Suche nach dem passenden Difflink ziemlich mühsam. Gruß, --95.208.226.221 12:55, 20. Jun. 2010 (CEST)

Vielleicht sollten wir auch mal wieder auf die Nutzung von Spezial:Anmelden hinweisen ;) Einen schönen Montag wünscht --20% 00:46, 21. Jun. 2010 (CEST)

bzw. auf Hilfe:Benutzerkonto entsperren lassen (noch rot) Soll ich das mal für dich bläuen? --91.64.58.117 01:22, 21. Jun. 2010 (CEST)

Ich bin ohne Sorge, dass ihr zu zweit jedenfalls die Optimierung der Hilfeseiten hinkriegen werdet. ;-) Einen guten Start in die angefangene Woche! --95.208.226.221 02:18, 21. Jun. 2010 (CEST)

Welche jetzt? --91.64.58.117 02:20, 21. Jun. 2010 (CEST)

1 user ?

klar, dass meine Edits mengenmäßig keine Rolle spielen, aber was ist, wenn 100, 10000, 1000000 Edits dieser Art vorgenommen werden? Das ist ja eher die interessante Frage. Was passiert (nicht), wenn ich 10.000 User nicht daran hindere, je 10 kleine, an sich nicht zielführende Edits zu machen ? - Andreas König 19:37, 7. Jan. 2012 (CET)

Nunja, global gibt es wohl ein bisschen über eine Milliarde Edits. Da machen ein paar hunderttausend auch nichts aus. Und selbst wenn es so wäre: Dann wäre es erst einmal das Problem der Serveradmins, die die Technik entsprechend anpassen (oder im äußersten Notfall die Richtlinie „Sorge dich nicht um die Server“ außer Kraft setzen) müssten.
Für eine gewisse Editsparsamkeit gibt es andere gute Gründe (etwa: Versionsgeschichte übersichtlich halten). --Tobias D B 19:58, 7. Jan. 2012 (CET)

Gute Seite

Oft genug werden einem Bearbeitungen mit dem Argument untersagt, sie würden nur unnötig den Server belasten. Diese Seite setzt der Regulierungswut ein Ende. -- Elendsredder (Diskussion) 23:21, 29. Mär. 2012 (CEST)

Unwahrheit

Es dürfte auf de:WP keine zweite Seite geben, auf der (von seiten der Betreiber?) so dreist gelogen wird. Die Server stehen regelmäßig vor dem Kollaps und kollabieren auch immer wieder. Anders sind die vielen Gateway-Timeouts nicht zu erklären. Insbesondere Änderungen an Vorlagen und Botläufe sind eine Belastung. Auf der Festplatte von Servern abgelegte kompilierte Seiten müssen unnötig oft eingelesen werden, weil es keine ausreichende Versorgung mit schneller Hardware (schneller und genügend Arbeitsspeicher, genug CPU-Power, schnelle Platten) gibt. Die Einführung von Lua kann hier ebenfalls eine Rolle spielen. Ich bin daher dafür, die unwahre Tatsachenbehauptung "Es sind Mechanismen in der Software MediaWiki eingebaut, die eine zu exzessive Nutzung von Ressourcen automatisch verhindern. Die Serverlast spielt keine Rolle." zu entfernen und den Abschnitt durch differenzierte, wahrheitsgemäße Angaben zu ersetzen. ÅñŧóñŜûŝî (Ð) 14:02, 5. Nov. 2013 (CET)

Jetzt mal ganz ruhig und langsam ein- und ausatmen. Ich habe die Seite vor über drei Jahren angelegt, da war Lua noch kein Thema. Wir können gerne etwas ähnliches wie diesen Absatz hinzufügen. Hast du einen Textvorschlag?
Andererseits sollte das nicht zu blindem Aktionismus führen: Performanceprobleme treten ständig auf und ihr Grund ist nicht notwendigerweise in bestimmten Vorlagen oder Bots zu suchen. Änderungsforderungen wegen vermeintlicher Performanceprobleme sollten mit Daten untermauert werden. Oder wie es Brion Vibber in der englischen Version dieser Seite sagt: "Optimize through science, not superstition" --Tobias D B 18:19, 5. Nov. 2013 (CET)

Ich finde den erzürnten Ton auch nicht korrekt und kann insbesondere „die vielen Gateway-Timeouts“ nicht nachvollziehen, etwas Wahres ist an Antonsusis Einwand aber dran. Ganz konkret zählen die Parserfunktionen #expr und #ifexpr nicht zu den „aufwändigen Parserfunktionen“ (für mich unverständlich). Das führt dazu, dass die Bearbeitung von Listenartikeln regelmäßig zur unerträglichen Qual wird – bis hin zur völligen Einstellung der Funktion –, obwohl keines der gesetzten Parserlimits auch nur angekratzt wird. Jede Vorschau, jedes Speichern, ja sogar jeder Aufruf des Listenartikels durch einen angemeldeten Benutzer (unangemeldete bekommen die Seiten aus dem Cache) dauert in extremen Fällen bis zu 5 Minuten. Und das ist nur ein Beispiel. Allerdings ist es selbst in solchen extremen Fällen so, dass sich das nie auf „die Server“ als ganzes auswirkt. Die Infrastruktur erlaubt es einfach gar nicht mehr, dass ein paar schlechte Vorlagen, Lua-Module oder riesige Listenartikel „die Server“ in die Knie zwingen. So gesehen ist ein generelles „sorge dich nicht“ erst einmal korrekt. Allerdings ist es auch richtig, dass man sich beim Basteln an Vorlagen und Lua-Modulen Sorgen um alle Artikel machen muss, in denen die Vorlage oder das Modul verwendet wird. Aber das wäre „sorge dich um die betroffenen Artikel“. --TMg 19:30, 5. Nov. 2013 (CET)

1. Ein großer Schwachpunkt ist der Parser. Er stellt m.E. das softwareseitige "Tempolimit". Eine geänderte Seite oder Vorlage bewikt neues Oarsen und neue Kompilierung, sobald ein "action=submit" (also auch bei Vorschau) gesendet wurde. Bei den vielen Edits und demzufolge auch Vorschauen ist es also durchaus sinnvoll, dem Parser so wenig Arbeit wie möglich zu machen. Während das tief in der Nacht (z.B. mit Vorlagenänderungen) relativ gut geht (es gibt vermutlich auch Parser irgendwo in Europa), kann das tagsüber recht kritisch werden.
2. Der Cache mit den fertigen Seiten dürfte wohl nicht komplett in einem Arbeitsspeicher zu finden sein. Es kommt also auch zu Plattenzugriffen, welche das hardwareseitige Tempolimit darstellen. Inwieweit das im Verhältnis zum Softwarelimit steht, weis ich allerdings nicht. Diesen Teil der Performance kann man als User vermutlich nicht beeinflussen.

Bleibt die Frage, wie wir das konkret in Text umsetzen. ÅñŧóñŜûŝî (Ð) 20:27, 5. Nov. 2013 (CET)

• Eine blinde und pauschale Schuldzuweisung an Lua, weil irgendeine Seite nicht mitspielt, ist haltlos.
• Es ist im Einzelfall auf Beta durch systematischen Vergleich auf oder mit einer Testkopie und Testvorlagen in verschiedenen Varianten die Ursache zu analysieren.
• Erfahrungsgemäß senkt der Ersatz komplizierter Vorlagenprogrammierung durch Lua den Ressourcenbedarf auf ein Drittel.
• Hier hatte ich kürzlich eine solche Detailanalyse für eine Seite gemacht, bei der klassische Vorlagenprogrammierung (#expr) zum Versagen führte. Lua senkte die Last etwas; ging aber sogar noch einfacher.
• Aus welcher datenunterlegten Analyse stammt die Feststellung, Ein großer Schwachpunkt ist der Parser.?

Bedächtig und mit Performance-Überlegungen vorzugehen und zunächst auch das Verhalten ihrer Werke nach dem gründlichem Funktionstest auf Beta zu prüfen, ist Sache einer Handvoll Programmierer. Im umseitigen Text hat das nichts verloren.

VG --PerfektesChaos 20:34, 5. Nov. 2013 (CET)

Ja, der Parser ist Mist, deswegen wird er ja abgelöst. Ansonsten weiß ich nicht, worauf du hinaus willst, Antonsusi. Hast du irgendwelche Zahlen für deine Beobachtungen? Selbst wenn der Parser am Tag etwas länger braucht, ist das immer noch kein Grund, sich „um die Server zu sorgen“. Die halten das aus. So funktionieren Computer und Server im Speziellen nun einmal. Sind sie belastet, nehmen sie sich für die einzelnen Aufgaben sogar absichtlich mehr Zeit, damit alle bedient werden. --TMg 20:45, 5. Nov. 2013 (CET)