Drupal fast database access

Daraus lässt sich aber nicht wirklich etwas praxisrelevantes ableiten, schon gar nichts allgemeingültiges. Es sind einfach nur die sehr speziellen Erfahrungen des Autors und die sagen mitnichten etwas über grundsätzliches Performance-Verhalten einer Drupal-Site in Abhängigkeit davon, ob der Webserver auch die DB enthält oder nicht, aus.

Da spielen zu viele Variablen rein, von denen hier nicht eine einzige recherchiert wurde. Mglw. war bei seinem vormaligen Hoster auch allgemein alles überlastet. Ein Benchmark taugt nur etwas, wenn er nachvollziehbar / reproduzierbar ist.

Um auch nur ansatzweise ne grundsätzliche Aussage treffen zu können, müsste man beide Szenarios unter Laborbedingungen nachstellen. Neben Hardware, Systemen, Konfiguration, Anbindungen, etc. spielt dann auch das Zugriffsverhalten und die Programmierung der dabei aktiven Module eine Rolle. Manche Leute kümmern sich bei ihren Datenbankabfragen nicht im geringsten um Performance und Skalierbarbeit...

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -Alan Kay

Ob nun 23 x schneller, darüber lässt sich sicher streiten und hängt von vielem ab - richtig. Aber bestreiten wird doch niemand, dass lokaler Zugriff in 99% der Fälle performanter sein muss als Remote-Zugriffe. Das einmal auszusprechen halte ich durchaus für richtig und wichtig, vor allem, wenn man sich einen Hoster sucht. Da sind es vor allem die großen Hosting Companies, die die SQL-Server separiert halten. Und das ist sich weniger performant.

Es hängt einfach vom Einzelfall ab. Ich kann keinem sagen "In 99% der Fälle (rein fiktive und nicht empirische Zahl) ist eine lokale DB schneller. Irgendwo ist eben die Grenze der Maschine, egal ob beim Shard Hosting, wo alle Kunden zum Load beitragen, oder ob es sich um dedizierte Server und ne Seite mit reichlich Zugriffen handelt. Beim Shared Hosting ist es für den Kunden eben nur noch weniger einsehbar, weil er die zur Beurteilung notwendigen Daten bestenfalls indirekt erheben kann,

In größeren Szenarien ist der erste Schritt vor dem Einsetzen mehrerer Webserver und Load Balancer die Abtrennung der Datenbank auf einen eigenen Server. Das ist der erste Schritt die Last des Gesamtsystems zu verteilen und dadurch auch reell Performene zu gewinnen und die Grenze nach oben zu schieben, ab der das System aussteigt; sei es weil zu viele Prozesse gleichzeitig laufen, sei es weil Hauptspeicher knapp wird, sei es weil die Datenträger zum Bottleneck werden, usw. usf.

Auf einem Einzelsystem an seinen Grenzen ist eine Datenbankabfrage lokal mitnichten per se schneller als auf einem externen Server.

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -Alan Kay

Bitte nicht schlagen wegen OT, aber ich womit hat dieser Mensch wohl dieses Diagramm erstellt? Sieht jedenfalls super aus.

Zum Thema: Macht es soviel aus, wenn z.b. beide Server in einem Rechenzentrum stehne? Ich dachte immern, Last zu verteilen wäre performanter als ein System zu überlasten?
---
www.party-riebel.de

Also sicher, je nachdem. Ich will doch nicht behaupten, dass Google die Suchanfragen besser auf einem Rechner laufen lassen soll... Also ja, in Ordnung, depende.

Kommt drauf an wo im Einzelfall der Bottleneck liegt. Viele einfache DB-Abfragen, die große Datenmengen bewegen würde man vermutlich nicht durch die Auslagerung auf einen zweiten Rechner irgendwo im Rechenzentrum mit einem 100 MBit/s Netzwerk beschleunigen. In solchen Fällen hilft es zunächst einmal den Entwicklern ein paar gezielte und gut dosierte Schläge auf den Hinterkopf zu verpassen...

"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." -Alan Kay