Scripts und Daten
Inhalte wie Artikel oder Foreneinträge werden in einer Datenbank gelagert und werden von PHP-Scripts verarbeitet. Das ist eine weit verbreitete Methode um mit großen Mengen von Daten umzugehen. Auch ich nutze diese Art der Informationsverarbeitung für Labuschin Webdesign.
Momentaner Zustand von Labuschin Webdesign
Momentan greifen meine PHP-Scripts von einem Server auf eine MySQL-Datenbank eines anderen Server zu. Diese besteht mittlerweile aus 39 Tabellen mit 144.00 Datensätzen welche zusammen 9 MB ergeben. Da können Zugriffe auf ca. 15 Tabellen pro Seitenaufruf schon einmal länger dauern. Zumal es sich aktuell um einen externen Zugriff handelt. Irgendwann gibt das Script auf, wenn es nach einer bestimmten Zeit keine Antwort erhält.
Grund für all das: Umzug auf anderen Server
Schuld an dem ganzen Dilemma ist eine noch immer andauernde KK-Antrags-Verweigerung seitens STRATO. Dort leigt im Moment noch die Domain labuschin.com. Von diesem Server möchte ich aber aus verschiedenen Gründen runter. Darum habe ich auch meine Datenbank schonmal auf den Server meinen netten Arbeitskollegen Kristof Dreier gelagert.
Ich bitte euch daher darum, längere Ladezeiten und eventuell auftretende Fehler zu entschuldigen. Ich hoffe das wird sich noch im April 2006 regeln. Denn das neue Design Delighted soll ja seinem Namen gerecht werden.
@Jeriko; Logischerweise ist eine Query über alle Tabellen oder was auch immer innert 2 Sekunden gemacht. Aber das Problem hier bei Martin ist dass die PHP-Scripts auf einem ganz anderen Server laufen als die Datenbank, d.h. dass die Querys und die Daten immer über das Internet verschickt werden müssen, und da ist es logisch dasses ab und zu Unterbrüche, usw. gibt.
Jeriko, die 39 Tabellen enstanden aus meiner Statistik-Sucht :) Du willst gar nicht wissen, was alles pro Klick mitgeloggt wird *fg* Nein, nicht ganz so schlimm.
neben den normalen Datentabellen für Artikel, Kommentare usw. werden auch Browser, OS, Referer, RSS und Artikelstatistiken gepeichert. Diese werden von Cronjobs regelmäßig aktualisiert und in seperaten Tabellen für eine ausführliche Auwertung...
Meine Administration befindet sich glücklicherweise schon auf dem neuen Server, da diese nicht unbedingt eine Domain benötigt. Bei ihr werden extrem viele Berechnungen durchgeführt und es werden lockermal 20000 Datensätze durchforstet.
Chris, ist mir ja klar. Wollte damit ja auch nur andeuten dass es letztlich egal ist, ob die Tabelle nun 9 oder 90MB groß ist (okay, das ist ein bisschen hoch gegriffen, sagen wir mal 30 MB *g*), es kommt letztlich (und in dieser Situation ganz besonders) auf die Anzahl der Queries an. Beispiel WordPress: Normale Eingangsseite braucht durchschnittlich 10 Queries, einzelne Plugins verbratzen aber auch schonmal weit über 100 Queries (z.B. Get Recent Comments). Bei SOLCHEN Zahlen ist es klar, dass es zu Problemen kommen kann.
Ich attestier aber Martin mal genug Ahnung, so dass er seine Queries vernünftig optimiert hat. Wie gesagt, noch ist mir die Fehlerseite nicht untergekommen. Ist die eigentlich toll? Muss man die mal gesehen haben? :)
Die Fehlerseite ist fast wie meine 404 Seite. (siehe hier http://labuschin.com/gdgdgd/ ). Und ich hab pro Seitenaufruf ca. 15 Queries.
Jeriko
21.04.2006
39 Tabellen für ein Blog? Wow... da hat wohl jemand die drei goldenen Regeln der Datenbankstruktur konsequent beachtet :-)
Allerdings sollte das nicht ins Gewicht fallen. Wichtiger bei externem Zugriff wäre wohl die Anzahl der SQL Queries, die pro Aufruf einer Seite abgesetzt werden (ich schreib da im Moment selber was über problematische WordPress Plugins). Ein normaler Webserver hat mit einer Datenbank a 9 MB auf 39 Tabellen eigentlich keine Probleme, sowas ist normalerweise in spätestens 2 Sekunden komplett durchforstet.
Da passt es ja auch ins Bild dass mir die Fehlerseite bisher noch nicht untergekommen ist.