Betrieb und Last bei mehr als 1.000.000 Nodes
am 31.03.2010 - 07:22 Uhr in
Also mein Titel sagt es ja schon. Wobei die Zahl mit Absicht etwas übertrieben ist, da ich nicht weis wieviel Beiträge (Nodes) es geben wird. Auf jedenfall werden es sehr viele.
Ziel:
Ein System in dem sich ein User anmelden kann und kurze Textmessages (ähnlich wie bei Twitter) posten kann. Diese Messages sind für alle User einsehbar. Ausserdem sollen die Textmessages später durchsuchbar sein und sie sollen "Flags" erhalten. Um die Messages z.B. mit weiteren Optionen in der Datenbank zu markieren. Sprich: Message ist interessant für Zielgruppe x, Message wird verfolgt von 5 Personen (in einer weiteren Tabelle, ist vermerkt, welche Personen das sind), usw.
Frage:
Es geht nicht um die Umsetzung im allgemeinen, oder welche Module ich nun alles brauche. Es geht nur um den Ansatz. Sollte ich für diese Messages lieber ein eigenes Modul schreiben, um darauf den bestmöglichen Zugriff zu haben, was die Optimierung angeht, oder wirklich auf die internen Nodes zugreifen? Ab welcher Menge wird es mit den Nodes kompliziert, bzw. wird das System langsam. Gibt es irgendwelche Erfahrungen? Ich will nicht dass ich dann mehrere Tausend User habe und jeder von denen täglich 20 Messages schreibt und mir dann das System abschmiert....
Ich bin für alle Ansätze dankbar...
- Anmelden oder Registrieren um Kommentare zu schreiben
Auf eher allgemein Fragen
am 31.03.2010 - 11:41 Uhr
Auf eher allgemein Fragen wirst du schwerlich konkrete Antworten in Form von Zahlen bekommen.
Wenn du für Kernfeatures (Umsetzung deines 'Inhaltstyps' mit voraussichtlich sehr vielen Instanzen) an Drupal gewissermaßen vorbei entwickelst beraubst du dich aller Möglichkeiten die Drupal und die tausende von Modulen bieten. Wofür dann noch Drupal nutzen? Dann wärst du mit einem System wie Django (basierend auf Python) und Ruby on Rails (basierend auf Ruby) besser beraten, die dir volle Kontrolle über das Datenbankschema geben. Da stellt sich dann aber die Frage nach den vorhandenen Skills (Oder ob du derzeit nur evaluierst und Konzepte erstellst und für die Umsetzung jemanden anheuerst.) und inwiefern Rapid Prototyping eine Rolle im Entwicklungsprozess spielen soll. Für RB sind auch Django und RoR geeignet, aber in Drupal brauchst du für deine Anforderung ja nicht viel mehr als eine handvoll Module (CCK, Views, Voting API, Flag, Fivestar, o.ä.), kannst entsprechend mal schnell was aufbauen und darauf basierend deine Idee testen und weiterentwickeln.
Ab welcher Anzahl von Nodes das System langsam wird hängt davon ab was für ein System du hast, was du als "langsam" definierst und was bei Seitenzugriffen alles abgefragt, gefiltert und sortiert werden muss. Nicht zuletzt spielt auch die Art des Traffics (anonym / eingeloggt) und dessen max. Frequenz eine Rolle. Dabei ist "System" als komplette Einheit zu verstehen, bestehend aus Serverlandschaft mit Hardware- und Netzwerkkonfigurationen, Betriebssystemen mit spezifischer Konfiguration und allen installierten Diensten und deren Konfigurationen, mit allen womöglich zur Geschwindigkeitsoptimierung und Skalierung eingesetzten Maßnahmen.
Die Frage ob Drupal mit einer solchen Node-Anzahl klarkommt kann man klar mit ja beantworten. Es gibt da draußen Systeme mit Millionen von Nodes. Die laufen verständlicherweise aber nicht auf nem Shared Hosting Account für 10 Euro im Monat. Das schöne an Performance (Wie schnell erzeugt der Server die Seite, wird sie ausgeliefert und ist im Browser des users komplet engezeigt?) und Skalierbarkeit (Wie verhält sich die Performance bei steigender Zahl konkurrierender Zugriffe?) ist, das man beides testen und messen kann.
Zur Optimierung von Performance und Skalierbarkeit gibt es eine Vielzahl von möglichen Stellschrauben und Maßnahmen die deutlich darüber hinaus gehen, ein frisch heruntergeladenes Drupal auf seinen Webspace / seinen "normal" eingerichteten Root-Server aufzuspielen. Welche Maßnahmen im Einzelnen sinnvoll sind ergibt sich auf Basis von Einschätzungen / Erfahrungen zum Benutzerverhalten (Wie viele in welcher Zeit? Wieviele Zugriffe? Zugriffe worauf?) und der spezifischen Last die diese Anfragen in den Diensten erzeugen (Welche Ressourcen werden vom Webserver angefordert? Welche SQL-Abfragen sind während der Skriptausführung notwendig?). Das alles kann man messen, protokollieren, analysieren und optimieren.
Die Optimierung kann je nachdem alles mögliche beinhalten, von einfachen Änderungen von Konfigurationsparametern, über das Hinzufügen zusätzlicher Dienste, das Auslagern von Diensten auf eigenständige Hardware, Integration zusätzlicher Hardware, Optimierungen im Theming, Anpassungen in der Programmierung, usw. usf.
Derzeit kristallisiert sich als Startpunkt im Bereich erhöhter Anforderungen ein Software-Stack heraus, der aus Pressflow (einer API-kompatiblen Drupal-Version mit diversen Performance-Patches), Apache Webserver, MySQL Datenbankserver, Varnish Reverse-Proxy, Memcache und APC besteht, ggf. ergänzt durch Apache Solr basierend auf einem Tomcat-Server. Ausgehend davon hat man schonmal ein System an der Hand, das deutlich mehr Performance und Skalierbarkeit bei gleichen Hardwareressourcen bietet als eine Standardinstallation. Auf der Basis aufbauend sind dann viele Spielarten der vertikalen und horizontalen Skalierung möglich.
Gut, dass du mich daran erinnerst, ich muss beizeiten noch die Konfig eines solchen Kundenservers abschließen...
Hmm, wenn ich so eine
am 31.03.2010 - 12:00 Uhr
Hmm, wenn ich so eine Anforderung hätte, würd ich mal die Kombi nginX + Memcache + Drupal testen, siehe http://technosophos.com/content/53900-speedup-nignx-drupal-and-memcache-... Persönlich habe ich Apache + XCache (ist das beste Caching für Magento behaupt ich jetzt mal) auf meinem Rootserver laufen und habe bis jetzt keine Performanceprobleme, allerdings hatte ich bis jetzt auch nicht diese Anforderung.
andreas-emer schrieb Hmm,
am 31.03.2010 - 12:44 Uhr
Hmm, wenn ich so eine Anforderung hätte, würd ich mal die Kombi nginX + Memcache + Drupal testen, siehe http://technosophos.com/content/53900-speedup-nignx-drupal-and-memcache-... Persönlich habe ich Apache + XCache (ist das beste Caching für Magento behaupt ich jetzt mal) auf meinem Rootserver laufen und habe bis jetzt keine Performanceprobleme, allerdings hatte ich bis jetzt auch nicht diese Anforderung.
Magento dürfte eine andere Baustelle sein und gilt unter denen, die den Code kenne als ziemlich skalierungsunfreundlich ;)
Nginx ist sicher leichtgewichtiger als der Indianer, wenn ich aber eh einen Reverse Proxy vorschalte, kommen praktisch ausschließlich Requests bis zum Webserver durch, die es erfordern, dass der PHP Interpreter angeworfen wird. In einem solchen Szenario macht der kleinere Footprint von Nginx nicht mehr so viel aus. Im Zweifelsfall müsste man es gegeneinander testen, sowohl was Performance, als auch Skalierung und Ressourcenbedarf angeht.