Wikipedia Diskussion:Server

message: Wir haben die 6.000 USD erreicht um einen neuen Server zu kaufen! Vielen Dank an alle Spender!. Mehr Infos unter Wikipedia:Spenden. :-) Fantasy 10:29, 11. Okt 2003 (CEST)
thread_title: Spendenaktion hat Summe für neuen Server erreicht! :-)

message: Mir ist aufgefallen, dass die Wikipedia-Server oft offline sind (wenn meistens auch nur kurz) und sonst oft sehr langsam sind. In den letzten Tagen wars wieder besonders schlimm. Liegt das an einer Überlastung der Server oder hat das andere Ursachen? --MrBurns 18:39, 20. Dez. 2007 (CET)
thread_title: Serverprobleme

message: Virus oder gehackt? - www.wikipedia.de öffnet nun bei mir eine Seie von domainname.at, einem Anbieter zur Domainregistrierung. Hab ich ein Problem auf meinem Rechner oder Wikipedia eins auf seinem? -- ohu, 03.11.2003
kein Virus. Irgendwer hat vermutlich vergessen, die Registrierung für wikipedia.de zu erneuern. Nachforschungen laufen bereits. --elian 02:02, 3. Nov 2003 (CET)
thread_title: Die Frage wurde auf einer anderen Seite nochmal gestellt

message: Die Domain ist seit 13. November 2003 wieder unter unserer Kontrolle. Es wird allerdings noch (voraussichtlich) bis zum 14. November dauern, bis die Übernahme abgeschlossen und die Domain damit wieder uneingeschränkt nutzbar ist. -- Akl 19:21, 13. Nov 2003 (CET)
thread_title:  Erfolgsmeldung 

message: Ich frage mich, was mit den Servern passieren wird, die zur Zeit unter Fedora Core 2 laufen, denn die Unterstützung davon wird demnächst ja offiziell aufgegeben, und dann an das Fedora Legacy Projekt übergeben.
Rechnet ihr damit, dass das Legacy Projekt sinnvoll laufen wird, bzw. wurden da schon entsprechende Überlegungen und Beobachtungen zu gemacht? Oder gibt es deswegen eventuell Gespräche mit Red Hat oder anderen? --Liquidat 13:01, 30. Mai 2005 (CEST)
replies: text: Tatsächlich sind die Aufzeichnungen auf einem veralteten Stand, alle Apachen laufen auf FC3, einige andere auf FC4. Vgl. hier. So weit --Mdangers 22:09, 30. Jun 2006 (CEST)
thread_title:  Fedora Core 2? 

message: Wo finde ich etwas über die Benutzungsbedingungen von Toolservern? 
Kann man z.B. auf einem Toolserver ein kommerzielles Übersetzungs-Programm laufen lassen, um Wikipedianern einen Dienst anzubieten? (ausschließlich WP-Artikel würden übersetzt) Der Hersteller könnte eine spezielle Endbenutzerlizenz für diesen Zweck erteilen, stellt das Programm allerdings nicht im Quelltext bereit und nicht unter eine freie Lizenz. Eventuell wäre die Ansteuerung frei, aber die eigentlichen Routinen sind die des normalen kommerziellen Programms. Ginge sowas?
(Ich möche nicht wissen, ob das sinnvoll ist, sondern nur ob es prinzipiell zulässig ist oder gegen die Grundidee verstößt.) --212.23.103.45 03:00, 5. Feb. 2008 (CET)
thread_title:  Bedingungen für Toolserver-Nutzung 

message: Als Vorsitzender des ersten Hamstervereins Zürich (Schweiz), möchte ich anmerken, dass es äusserst grausam ist, aus purem Geiz einen derart bemitleidenswerten Hamster als Notstromaggregat zu missbrauchen! Ich möchte Wikipedia auffordern, baldmöglichst eine Webcam einzurichten, über welche wir den Gesundheits- und Gemütszustand dieses garantiert nicht freiwilligen Mitarbeiters überprüfen können. –– IP 18. März 2008
: Voilà: hamster.webcams.wikimedia.org. Beschwerden ggf. bitte direkt an tierschutzbeauftragter@wikimedia.de. --Kurt Jansson 21:32, 18. Mär. 2008 (CET)
thread_title:  Tierquälerei 

message: Finden auch virtuelle Server Anwendung oder sind alle voll-physikalisch? --Itu (Diskussion) 01:17, 3. Jan. 2014 (CET)
thread_title:  Gibts auch virtuelle Server? 

message: Hi allerseits,
wird als webserver nicht inzwischen nginx verwendet? Zumindest sagt das mein firebug bei de. und en. (nur www.wikipedia.org zeigt noch apache an). greetz vanGore 17:33, 18. Apr. 2014 (CEST)
thread_title:  nginx? 

message: Hallo 
http://wikitech.wikimedia.org/view/Server_admin_log ist nicht mehr aktuell. Ist wohl leider nicht mehr erreichbar. DANKE :) Flomeixner (Diskussion) 02:28, 19. Mär. 2018 (CET)
thread_title:  Link-Leiche 

message: Zuweilen wird erörtert, welche ökologischen Kosten der Betrieb der Wiki-Server verursacht; namentlich CO2.
* Vorangeschickt sei, dass der Aufwand zum Schreiben einer Seitenversion an geistiger Energie und Nerven in keinem Verhältnis zur technischen Weiterverarbeitung steht.
* Die WMF sei bemüht, durch Einsatz grünen Stroms und Nutzung der Abwärme ihrer Rechenzentren den klimarelevanten Fußabdruck zu minimieren.
* Verraten sei vorneweg, dass der Energie-Aufwand zum Abrufen und Lesen und Verwalten einer Wiki-Seite pauschal eine Milliarde höher liegen düfte als die Abspeicherung einer Version.
Welche energierelevanten Teilprozesse gibt es?
* Speicherung der Textvariante auf Datenträgern
** Speichermedien sind heutzutage extrem preiswert und leistungsfähig.
** Blobs können komprimiert werden; insbesondere die lateinisch oder in einer anderen gleichmäßigen Schrift verfassten Wiki-Texte reduzieren dabei den Hardware-Platzbedarf deutlich.
** Die Wiki-Texte stehen in keinem Verhältnis zum Platzbedarf von Videos, oder selbst hochaufgelöster Bilder.
** Wie genau in der Datenbank die Binärdateien mit den Texten gespeichert werden, ist eine Privatangelegenheit der Datenbank-Software und wird nicht in der Wiki-Software selbst programmiert.
** Theoretisch ist es möglich, nicht jede Textversion komplett eigenständig abzuspeichern, sondern sie könnte bei nur kleinen Änderungen gegenüber der vorangegangenen Version nur „inkrementell“ die Veränderung nach einer speziellen Syntax zu hinterlegen. Vielleicht jede zehnte Version solle dann aber wieder vollständiger Text sein, oder eine Version mit so vielen einzelnen Veränderungen, dass der Aufwand für die vielen einzelnen Änderungen zu groß wird.
** Soll dann der Text einer Version abgerufen werden, die nur inkrementell vorliegt, muss die letzte vollständige Version abgefragt werden und danach darauf alle seither erfolgten inkrementellen Veränderungen angewendet werden. Wenn das Abrufen älterer Versionen ein häufiger Anwendungsfall sein sollte, ist das nicht sehr effizient.
** Generell ist das Speichern von Textversionen nicht dramatisch; die Versionen von Multimedia-Dokumenten sehr viel anspruchsvoller für die Hardware, namentlich auf Commons mit zig Millionen Bildern.
* Umwandlung von Wikitext in HTML
** Dies wird zuweilen auch als „rendern“ bezeichnet.
** Hier liegen von einer bis einem Dutzend CPU-Sekunden wesentliche Ursachen für Rechnerleistung bei der Vorschau jedes Seitenentwurfs und nach dem Abspeichern; sowie zur Anzeige älterer Seitenversionen.
** Mit der Abspeicherung wird der Kern des Inhalts (sofern keine Besonderheiten dagegensprechen, die im ANR und bei Diskussionen eigentlich nicht auftreten können) im Cache hinterlegt. Zukünftige Anfragen nach diesem aktuellen Seiteninhalt werden nicht aus der eigentlichen Wiki-Datenbank bedient, sondern aus der Cache-Datenbank. Es werden so lange Cache-Versionen hinterlegt, bis ihr Speicher zu 99 % gefüllt wurde. Danach werden nach einer Heuristik Seiten gelöscht, von denen erwartet wird, dass sie so bald nicht wieder nachgefragt werden würden. Trivialerweise wären das die für die längste Zeit nicht abgefragten Seiten; es könnte aber auch die Häufigkeit berücksichtigt werden, oder große aufwändige Seiten stärker als kleine Seiten zunächst behalten waren.
** Vorlageneinbindungen gleicher Parameterwerte, die nicht vom Kontext abhängen, werden mit ihrem konstant ausgewerteten Ergebnis ebenfalls im Cache hinterlegt und dann jeweils dieses fertige Ergebnis zur Ersetzung genutzt.
** Zurzeit liegt die Haltbarkeit von Seiten im Cache bei drei Wochen.
** Gleichzeitig werden alle „Wörter“ dem Suchbaum der Suchfunktion hinzugefügt, sofern sie bisher noch nicht enthalten waren. Hin und wieder wird der Suchbaum auch komplett neu generiert, oder Teile davon. Mit dieser Seitenversion nicht mehr auftretende Wörter aus dem Baum zu löschen ist meist schwierig; eher werden Fehltreffer aus den ersten Ergebnissen nachträglich wieder ausgefiltert.
* Lese-Anfrage
** Bei jeder Lese-Anfrage wird ein individuelles HTML-Dokument als Antwort generiert.
** Dabei werden neben allen inhaltlichen Details auch die mitgelieferten Cookies berücksichtigt. Angemeldete Benutzerkonten erhalten per se eine individuelle Antwort, aber auch anonyme („IP“) teilen über Cookies mit, dass sie bestimmte Banner bereits gelesen hätten, Sprachoptionen der ULS hätten usw.
** Sogar für IP kann es eine neue Nachricht auf der Benutzer-Diskussionsseite geben; dies muss auch für jede IP bei jeder Anfrage nach einem Seiteninhalt geprüft werden.
** Aus zwei im Cache hinterlegten Bauteilen wird die HTML-Antwort generiert und ggf. modifiziert:
*** Der Portal-Rahmen, mobil oder Desktop (Vector), in der entsprechenden Sprache, modifiziert gemäß Cookies usw.
*** der darin eingebettetw Inhaltsbereich der eigentlichen Seite, für nahezu alle Abfragen gleich.
** Wurde eine Seite angefordert, deren Inhalt nicht im Cache vorliegt, wird ein frisches Rendern des Wikitextes erforderlich, die resultierende HTML-Version des Inhaltsblocks im Cache hinterlegt, und im Gegenzug ältere längere Zeit nicht angeforderte Seiten aus dem Cache gelöscht, um Platz zu schaffen.
** Unabhängig vom Text des HTML-Dokuments sind die eingebundenen Bilder oder ggf. andere Mediendateien zu zählen. Bei einem gut illustrierten Artikel können die Bilder umfangreicher sein als das HTML-Dokument. Allerdings werden die Mediendateien im Browser-Cache hinterlegt und müssen bei erneuter Darstellung des HTML-Dokuments nicht erneut abgerufen und übertragen werden.
** Spezialseiten generieren ihre Inhalte nicht aus dem Cache, sondern in der Sekunde frisch aus der Datenbank, und fügen das Produkt genauso in den Portal-Rahmen der Skin ein. Neben dem Namensraum der Spezialseiten gehören dazu auch alle anderen Auswertungen der Metadaten, wie Seiteninformationen oder Versionsgeschichte und Diffpages.
* Ändern von Vorlagen und Modulen
** Jede Veränderung einer eingebundenen Seite, namentlich Vorlagen und Module, erfordert neues Rendern sämtlicher einbindender Seiten.
** Jede einbindende Seite muss neu ausgewertet werden, weil zu vermuten ist, dass sich die Veränderung der eingebundenen Seite auch auswirkt.
** Dazu gehören auch Kategorisierungen, Verlinkungen als Wikilink oder URL. Deren Veränderung beeinflusst Auflistungen jeder Kategorie, der Wikilinks bzw. einbindenden Seiten sowie der fremden URL im Projekt.
** Jede Neuanlage oder Löschung einer Seite beeinflusst den Rest des Wikis in gleicher Weise; Rotlinks werden zu Blaulinks oder umgekehrt usw.
** Insbesondere tausendfach eingebundenen Seiten, erst recht bei Einbindungszahlen im fünf- und sechsstelligen Bereich, sind besonders gegen unsinnige Veränderungen zu schützen. Zum einen bewirkt das ggf. unerwünschte Darstellungen, die auch für Stunden nach einer Reparatur noch fehlerhaft erscheinen, weil die Warteschlange Tausender beeinträchtigter Seiten noch nicht abgearbeitet und aktualisiert im Cache abgelegt werden konnte; zum anderen kostet das bei mehreren CPU-Sekunden pro Neugenerierung und Zehntausenden betroffener Seiten mehrstündige CPU-Weißglut, Stromverbrauch und Kühlungsbedarf.
** Veränderungen an tausendfach eingebundene Seiten werden deshalb routinemäßig an Sichter- oder Admin-Rechte gebunden. Vor einer Veränderung ist diese möglichst umfassend (auf WP:BETA) auszutesten und dann im offenbar robust funktionierenden endgültigen Zustand in das produktive Wiki zu kopieren. In der Kindergartenzeit der Wikipedia hatte man noch an den echten Versionen der Vorlagen Effekte ausprobiert und die Wirkung auf die öffentlich präsentierten Artikel betrachtet; dies gilt seit einem Jahrzehnt als extrem unseriös und lässt auf das geistige Niveau von Kindergartenkindern rückschließen.
* API-Anfragen
** Wenn Buchstabe für Buchstabe ein Lemma in das Suchfeld eingetippt wird, bewirkt das jeweils eine Blitz-Kommunikation mit dem Wiki-Server. Es wird eine Auswahl in Frage kommender Seiten, die immer spezifischer wird, zur sofortigen Anzeige zurückgeliefert.
** Vielerlei Hintergrundfunktionen, Werkzeuge, Skripte rufen ebenfalls Daten ab, stellen diese aber nicht unmittelbar im angezeigten HTML-Dokument dar.
** Ressourcen wie CSS und JavaScript gehören auch in diesen Bereich. Sie werden aber im Cache des Endgeräts hinterlegt, bis sich ihr Code ändern würde. Allerdings wird durch eine kurze Nachfrage bei Darstellung jedes HTML-Dokuments nachgefragt, ob dieser hinterlegte Inhalt auch die aktuelle Version ist.
* Verwaltende Abrufe
** Sie entsprechen generell den Lese-Abrufen.
** Es wird ebenfalls ein HTML-Dokument generiert, jedoch ist der Inhalt wie bei einer API-Abfrage eine dynamische Auswertung der Datenbank. Dazu gehören Suchen nach Text im Seitenbestand, aber auch alle Kategorien, Spezialseiten, Versionsgeschichte, Beitragslisten und Diffpages. Hinzu kommen externe Werkzeuge, also außerhalb der Wiki-Domain selbst.
* Serverfarmen
** Die genaue Zahl der die Publikumsanfragen beantwortenden einzelnen Server wird von der WMF nicht klar kommuniziert. Sie liegt jedoch größenordnungsmäßig um den Faktor 1000 höher als die Zahl der Server, welche für die eigentlichen Inhalte der WMF-Wikis benötigt werden. Hinzu kommen verschiedenste Hilfs-Server für Management, Kommunikation, Koordination und Caching der Datenströme und Seitenversionen, Rendering sowie zusätzliche Werkzeuge (Cloud), ferner Logs sowie Statistiken und die Anmeldung registrierter Benutzerkonten.
** Es gibt auf einzelnen Kontinenten Tochter-Serverfarmen der eigentlichen Mutterversionen, wodurch der interkontinentale Netzwerkverkehr reduziert wird.
** In den USA gibt es zwei voneinander unabhängige Serverfarmen, von denen jede als Mutterversion eingesetzt werden kann und die gleichzeitig Publikumsverkehr abwickeln. In einem Katatrophenfall (Überschwemmung, Hurrikan) kann binnen Sekunden möglichst verlustfrei von einem zum Hunderte Kilometer entfernt liegenden Ausweichstandort umgeschaltet werden.
* Antworten, Netzwerk, Endkunde
** Der extrem überwiegende Energieverbrauch pro Seitenversion entsteht durch die wohl bei Millionen Abrufen pro Sekunde liegende Nachfrage des globalen Publikums, den Traffic durch die globalen Netzwerke sowie schließlich bei der Umwandlung des übermittelten HTML-Dokuments nebst Zubehör in eine optische Präsentation im Endgerät. Dazu müssen Skripte ausgeführt und CSS-Regeln auf das Dokument angewendet werden.
* Auf gar keinen Fall sollte versucht werden, im Wikitext einer Seite, insbesondere eines enzyklopädischen Artikels, durch abstruse Syntaxkonstruktionen Bytes für Leerzeichen, Zeilenumbrüche oder mittels kürzerer jedoch falscher Syntax einzusparen.
** Die nachfolgenden fehlerhaften Edits anderer Autoren, die dadurch aufs Glatteis geführt werden, und die dadurch entstehenden Seitenversionen und Diskussionsabschnitte und Werkstattanfragen stehen (unabhängig von vergeudeter Lebenszeit und Nerven) in keinem Verhältnis zur erreichten physischen Einsparung. Zumal letztendlich irgendjemand einen verständlichen korrekten Normalzustand wiederherstellen wird.
** Wenn es zur Straffung des Quelltextes kommen soll, dann nur über Einbindung geeigneter Vorlagen.
** Bei der Programmierung vielfach eingebundener Vorlagen und Module sind in der Tat unter aufrechterhaltener Robustheit und Wartungsfähigkeit Effizienzgesichtspunkte zu betrachten, schon allein um keine Vorlagenbeschränkungen auszulösen. Das hat dann aber auch zigtausendfache Wirkung.
--PerfektesChaos 17:28, 23. Mai 2022 (CEST)
thread_title:  Ökologische Aspekte