Datenbank cachen

Wenn du ein Shared Hosting Paket hast und der Hoster exteren Datenbankserver benutzt (also nicht "localhost"), dann kannst du nicht wirklich etwas tun. Dort kommt es relativ häufig vor, dass Leitungen und DB-Server chronisch überlastet sind. Ein DB-Server auf dem Unmgengen verschiedener DBs mit sehr unterschiedlichen Zugriffsmustern laufen, lässt sich auch denkbar schlecht optimieren.

Bei großen Webanwendungen werden auch dedizierte DB-Server verwendet, da ist der Fall aber ganz anders gelagert. Dort kann man mit Memcache nochmal deutlich Speed gewinnen, wozu aber nochmal mehrere dedizierte Maschinen ins Netz gestellt werden, die nichts anderes machen.

--
Webseiter

Naja, ich dachte da eine eine "Quick and Dirty Lösung" mittels einer lokal gecahcten Mem oder File gecachten DB.

In C# habe ich mal etwas ähnliches mit einer Kommunikationsschicht gemacht, in der die Datenbanken eingetragen wurde und durch die Schicht in einem extra Thread synchronisiert wurden. Dort waren es SQL Lite als FS-DB und eine einfache MySQLDB, die quasi nur für den externen Zugriff verwendet wurde.

Bei PHP bin ich jetzt nicht so ganz firm, wie einfach und überhaupt möglich es ist, so etwas auf einem "einfachen" Webspace umzusetzen.

Wenn ein Hoster nicht in der Lage ist halbwegs flinke DB Server zu unterhalten, würde ich von den Web-Frontends auch nicht zuviel verlangen ;)

Drupal bietet von Haus aus diverse Caching-Strategien mit, allerdings cachet Drupal in der DB ;-)

Da sollte man lieber ein wenig Zeit in Recherchen und ein paar Euronen in Hosting investieren. Das rechnet sich mehr, als über irgendwelche Hacks nachzudenken.

Die letztendliche Schnittstelle, auf die PHP Skripte zugreifen sind die DB-Funktionalitäten der entsprechenden PHP Erweiterungen. Wenn dann müsstest du hier ansetzen und da kommst du natürlich nicht dran.

--
Webseiter

Ja, das weiss ich auch, aber das bringt mich der Beantwortung der Frage, ob und wie man es Softwareseitig machen könnte keinen Deut näher!

Dass ein Hostingwechsel der bessere Weg ist, weiss ich auch, aber das war NICHT die Frage!

PS.
Wenn ich in einem Forum eine Frage habe, dann würde ich den Thread gerne um diese Frage drehen lassen. Nur zu häufig lese ich abschweifende, zwar wohlgemeinte Ratschläge, die zwar mit dem Problem aber nur entfernt mit der Frage an sich zu tun haben.

Es soll ja auch Leute geben, die irh Auto tunen, anstatt sich einen Porsche zu kaufen.

Vielleicht gehts ja manchmal auch nur um die Sache an sich, seis Interesse oder whatever.

Mich interessiert bspw mittlerweile generell, ob und wie ein Datenbankcaching realisiert werden kann und nicht, wo man unterschreiben muss, um den Hoster zu wechseln.

Kein Grund laut zu werden. ;-)

Das Problem in Foren wie diesem ist eben, dass man als Leser nunmal nicht wissen kann, welchen Background der Schreiber hat. Schau dich um und du wirst feststellen, dass die meisten Fragen schon vöölig in die falsche Richtung gehen.

Fangen wir es also mal anders an:
Hast du eine spezielle Situation (Welche genau?), die dich zu der Analyse gebracht hat, dass du DB-Caching brauchst? Weöche technischen Möglichkeiten hast du serverseitig und welche Skills hast du?

Punkt ist ganz einfach, dass die Antwort auf deine Frage nicht zwingend dein Problem lösen muss. Nur kennen wir dein Problem nicht und ich persönlich habe wenig Bock über Möglichkeiten zu fachsimpeln, die dich am Ende eh nicht weiterbringen.

--
Webseiter

Wenn du MySQL nutzt solltest du den QueryCache anschalten. Wenn der Server allerdings immer über ein Netz gehen muss, da er nicht lokal ist und das dann langsam ist, bringt die das natrülich herzlich wenig.

Ansonsten ließ mal das:
http://drupal.org/node/97347

Drupal selbst kann auch schon eine Menge cachen. Guck einfach mal unter "Leistung"
Ansonsten installiert dir ein Modul, das lokal alles in Dateien speichert. Oder halt MemCache, falls das Möglich ist, das speichert im Lokalem Speicher zwischen.

---

Viele Grüße,

Kars-T

Zunächst einmal ist es höfflich, einen Frager nicht schon vorab zu entmündigen und auf die Frage einzugehen...
Das hilft meistens weiter, als allgemeine Ratschläge oder ein Verweis auf die FAQ oder Google ;) aber das nur am Rande.

Gross zu analysieren gibt es nichts. Denn wie beschrieben: Ist die Verbindung des Webservers zum Datenbankserver zu langsam, leidet darunter die Gesamtperformance. Abhilfe würde imho ein Webserverlokales Caching bringen.

Serverseitig hätte ich theoretisch quasi alle Möglichkeiten, aber das ist langweilig, denn der Problemserver hat diese Möglichkeit nicht. Ausserdem wäre damit einer allgemeinen Lösung nicht geholfen. Man gehe also davon aus, dass Serverseitig die Möglichkeit besteht PHP Seiten aufzuspieln (0815-Hosting).

Im Bereich PHP bin ich wie gesagt derzeit nicht sehr firm. Meine Schwerpunkte der letzten Jahre lagen auf C# nebst MySQL/Oracls DBMS. Und dort habe ich etwas ähnliches wie gesagt umgesetzt. Da SQLite als FS-DB schon bestand war das keine Riesensache.

Ich kanns auch nochmal sagen:

Problem:
1) 0815-Space
2) langsame DB Verbindung
3) Möglichkeit gesucht die Performance zu steigern (und da gäbe es imho softwaretechnisch nur DB-Caching)

Diesmal alles kapiert?

Rein arhcitektonisch könnte ich mirs so vorstellen, dass es eine virtuelle DB-Schnittstelle gibt, die (bspw anhand Messungen) entscheidet, ob die MySQL oder die FS-DB genutzt werden soll. Drupal würde dann direkt auf die virtuelle Schnittstelle zugreifen, welche wiederum das DB-Handling steuert.

Ähnliches habe ich bei einigen Projekten schon gesehen. Dort wurden die Seiten statisch gecacht, was die DB wiederum immens entlastet, da nicht für jede Seite zig DB-Abfragen (Übersetzungen) gemacht werden müssen.

Hm? Welcher C# Programmierer kommt denn nicht mit PHP zurecht, insbesondere wene ein Schwerpunkt der letzten Jahre MySQL war? Und was hat SQLite damit zu tun?

Wie Alexander schon schrieb Kein Grund laut zu werden

vg
--
md - DrupalCenter

mdwp* :: Drupal Services

Zum einen sind DB's die nicht auf localhost liegen nicht zwangsläufig langsam.

Zum zweiten frage ich mich, wieso die DB auf einem externen Server rennt. Wenn die Performance des Webservers zu schwach ist, dann wird der auch das Caching nicht verkraften.

Zum dritten: Ist aus irgendwelchen Gründen eine spezielle Variante des DB-Zugriffs seitens Frontend nötig bietet Drupal eine DB-Abstraction-Layer (http://api.drupal.org/api/group/database). Da kann man ganz fix eine spezielle Methode implementieren, wenn man denn nun wirklich zuviel Zeit hat ;)

Zum Vierten: Es ist unsinnig einen Thread um eine Frage drehen zu lassen lassen, wenn man nicht auf der Beantwortung der Frage besteht, sondern gerne eine vernünftige Lösung hätte.

Zum Fünften: Als theoretische Frage halte ich das gar nicht mal für so unsinnig. Ohne den Spieltrieb würde es so manche gute Software nicht geben.

Zum Sechsten: Ich kann mir da sogar einen praktischen Einsazt zu denken. Da MySQL nicht in der Lage ist Blobs (Text) und damit das Cache-Table im RAM zu verarbeiten, wäre das ein nettes Interface zum speziellen Handling des Cache-Tables.

Schau Dir mal http://drupal.org/project/memcache und http://api.drupal.org/api/group/database an.
... und nicht aufgeben. Das wird ein harter Weg.

Im erwähnten Fall des 08/15 Hostings sieht es in der Praxis meist anders aus. Da muss man sich nur mal diverse Seiten anschauen, die bei Strato auf Sun-Webservern laufen. Die Maschinen dienen allesamt als reine Webserver, ein Pool dedizierter MySQL-Server übernimmt den DB-Load. Ich weiß nicht welche Sun Server dort aktuell noch werkeln, aber die ganzen Niagaras & Co. sind mit ihren vielen Kernen auch prädestiniert für Web und tendenziell eher übel für DBs geeignet.

Im Gegenteil ist bei großen Setups die physische Abtrennung des DB-Servers geradezu Pflicht. Schrub ich aber auch, ebenso wie dass dies aber ein ganz anderes Use-Case ist, in dem man eine Anzahl Server nutzt um EINE Anwendung zu hosten und nicht hunderte und tausende von Anwendungen.

Die Thematik, wie man bei MySQL BLOBs technisch in den diversen Tabellenformaten umgesetzt hat, ist eine an vielen Stellen im Netz sehr leidenschaftlich diskutierte. Man muss aber nicht lange drüber nachdenken, um eine Idee davon zu bekommen, dass BLOBs prima geeignet wären jeden DB Server in die Knie zu zwingen. Manchmal muss man eben doch das System vor dem Übereifer der Coder schützen ;)

Kann er nicht benutzen, da 08/15 Shared Hosting. Cache Router scheint übrigens die flexiblere legitime Nachfolge anzutreten. Habe es aktuell mit Memcache-Backend in einer D5 Installation laufen.

--
Webseiter

@Passer,

Wenn man Ueberlegungen zu moeglichen Cachingstrategien anstellen moechte muss man auch etwas ueber die Nutzung der Drupalinstallation wissen.
Ist es eine Site auf der sich mehr nicht eingeloggte Besucher bewegen oder ist es eher anders herum? Allein aus der Antwort auf diese Frage ergibt sich eine Moeglichkeit, mit der man den DB Server entlastet weil man ihn weniger benutzt. Diese Technik setzt aber ausreichend Leistung des Webservers vorraus.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Wie geht das? Der Cache für Gäste ist per default in der DB.

vg
--
md - DrupalCenter

mdwp* :: Drupal Services

Fuer Gaeste nicht in der DB sondern im Dateisystem mit Boost.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Ich schrieb "per default", sprich Drupal Core.
Wer soll wissen, dass du http://drupal.org/project/boost meinst.

vg
--
md - DrupalCenter

mdwp* :: Drupal Services

Die Syntax ist zwar ähnlich, die Architektur, die Anwendung und die Möglichkeiten jedoch komplett anders.

Solltest Du eigentlich wissen, anstatt so etwas unqualifiziertes zu behaupten!

@narres:Zum dritten:
Zeit (und vor allem Lust) ein FS-basierendes DB-Management System zu schreiben hab ich nicht, deshalb auch nochmal der Verweis an md, dass ich deshalb auf SQLlite als Filebasierende DB dachte; natürlich müssen dazu natürlich entsprechende PHP-Bibs vorhanden sein, die wiederum nicht als binaries vorliegen sollten.

Memcache kann ich leider vergessen, da es wharscheinlich bei einem 0815 WS nicht aktiviert ist :(

@quiptime
Es wird eine Mischung aus allem sein. Bei einem FS Caching sollte das allerdings relativ egal sein.

@Boost-Modul:
Das werd ich auf alle Fälle mal ausprobieren. Evt findet sich da die ein und andere Möglichkeit das Modul abzuändern, dass die DB-Abfragen minimiert werden.

Inzwischen wäre ich fast neugierig darauf, ob es nicht irgendwie Möglich ist, die Locale-Engine ins FS auszulagern, da diese einen immensen DB-Load verursacht.

MfG
Passer

Pennst du eigentlich mit der Buchhalterin deines Hosters, oder woher der Wunsch sich die Arbeit zu machen in einem Gebiet, in dem man technisch nicht versiert ist, zu arbeiten, anstatt die Rahmenbedingungen zu verbessern?

Erinnert mich an die ganzen Fraggles mit ihren alten 70 PS Polos, die sie dann tiefer legen und dicke Ofenrohre drunterschanallen, damit der Wagen im Stand wenigstens schneller aussieht...

Wenn du dererlei Bastelarbeit als interessantes Hobby ansiehst, ist das legitim. Wenn du mit der Website aber was erreichen möchtest, naja....

Und basteln kannst du ja auch wenn der Hoster flott ist ;)

--
Webseiter

@Passer,

Du redest irgendwie durcheinander und ich habe den Eindruck das das von dem Du redest keinen Bezug auf eine konkrete Drupalinstallation hat.

Wenn Du Drupal ohne DB willst dann teste mal "Drupal Light".

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Das kann man, je nach Art der Site auch anders haben. Wenn es keinen zwingenden Grund gibt ein deutsches (oder anderes nicht englisches) Drupal-'Backend' anzubieten, habe ich das Locale-Modul grundsätzlich deaktiviert. Man kann auch, wenn nur wenige Dinge übersetzt sein müssen, dieses Modul http://drupal.org/project/stringoverrides nutzen.

Wie gesagt, hängt vom Typ der Site und den Benutzern ab.

vg
--
md - DrupalCenter

mdwp* :: Drupal Services

An sich sollte ich auf so ein dümmlichen Beitrag gar nicht eingehen. Mach ich auch nicht weiter.

Mich erinnert Dein Kommentar an die neueren Betriebssysteme, die mit der steigenden Gesamtleistungsfähigkeit der Computer auch zunehmend fleissiger mit den Ressourcen rumarsen. Imho ist es sinnvoll, nach Optimierungsmöglichkeiten Ausschau zu halten, anstatt einfach das "Totschlagargument", man solle sich einen schnelleren Hoster suchen zu bringen...
In dem Sektor der Datenbankperformance ist bei Drupal durchaus noch Potential vorhanden, besonders, wenn ich mir (die auf meiner Suche nach Performanceoptimierung gefundenen) Vergleiche der Version 4,5,6,7 angucke. Wenn ich da Aussagen wie "800 DB Zugriffe" lese, traue ich mich gar nicht, das mit Dev Modulen gegenzuprüfen ;)

@quiptime
"Drupal Light" Das sagt mir jetzt nichts

Es handelt sich übrigens um eine Drupal 5.X Installation (siehe auch die Tags im Initialbeitrag)

Und waurm meinst Du, rede ich durcheinander? Weil sich einige Kommentare weniger der Hilfestellung, als einer allgemeinen Belehrung (aka Klugscheisserei) befleissigen?

@md

Das "String Overrides" sieht durchaus interessant aus, da es sich aber um eine "komplett Deutsche" Seite handelt, also eine ca 7000 Zeichenketten umfassende Übersetzung benutzt eignet es sich nur bedingt, da es auch die DB benutzt.

Werd heute evt. mal versuchen, inwieweit es einen Schub bringt, wenn man dieÜbersetzung komplett ins FS ausgelagert wird (in C# hätt ich dann quasi nur die Datei geladen, doch in PHP ists glaub ich nicht wirklich schlau eine Ähnliche Verfahrensweise per include zu machen. C# Programme laufen ja idR lokal in wenig Instanzen, bei PHP kann sollte man ja ruhig von 100 Instanzen ausgehen müssen und ob das die ServerCPU (0815) mitmacht ;)

@Passer: So wirklich ist es mir nicht klar wieso Du nicht einfach mal in http://api.drupal.org/api/group/database schaust.
Dann machst Du ein cd include in Deinem Drupal-Folder und schaust mal in die database.inc, database.mysqli.inc, database.mysql.inc und database.pgsql.inc.
Dann schnappst Du Dir einfach das richtige Interface database.XXXX.inc mit welchem Du normal auf Deine DB zugreifst und machst ein wenig Wrapper für Deine speziellen Experimente drumherum.
Ein wenig

An der ein oder anderen Stelle wirst Du noch etwas Nachbessern müssen, vom Prinzip her funktioniert das aber so.

Im Grunde spielt sich alles an SELECT ab der _db_query($query) ab. Ich schätze das mal insgesamt auf ein paar Zeilen Code.

/* Zugegeben: So eine 0815-CPU (http://www.tomshardware.com/de/moderne-klassik-fuenf-boards-mit-815-chip...) möchte ich auch nicht mehr haben */

Dafür, dass du es nicht machst, machst du es aber recht ausführlich.

Mich erinnert wiederum dein Kommentar an viele unseelige Diskussionen der letzten 30 Jahre. Als die ersten Hochsprachen aufkamen hieß es, sie seien zu langsam und echte Kontrolle über Ressourcenverbrauch und Performance habe man nur mit Assembler. Als die ersten objektorientierten Sprachen kamen, wurden diese auch runtergemacht. Java traute man auch nichts zu und Skriptsprachen gehen ja per se nicht.

Alle Kritiker wurden eines besseren belehrt, auch Bill Gates, laut dem ja ein Rechner nie mehr als 640 KB RAM brauchen würde.

Nun kann ich mir als Entwickler die Frage stellen, wann ich mit Drupal glücklicher bin. Wenn ich seine Eingeweide derart modifiziert habe, dass auch beim lahmsten Hoster noch halbwegs Performance raushole, oder wenn ich die gewünschten Features der Website möglichst zackig umgesetzt bekomme.

Ich kann meinen Urlaub in Spanien auch zu Fuß antreten. Dann ist er nur leider zu Ende noch ehe ich am Ziel angekommen bin.

Ein System hat nunmal bestimmte Anforderungen. Wenn ein Hoster diese nicht erfüllen kann, muss ich upgraden oder wechseln. Ich pflege meine Dienstleistungen da zu beziehen, wo sie zu meiner Zufriedenheit ausfällt und halte nicht minderwertigen Diensten die Stange und suche den Fehler bei mir.

Ich nehme an du surfst gerade auch nicht mit MS DOS 3.3 - weil es so schön ressourcenschonend ist.

--
Webseiter

Naja solange wie Passer für diesen Thread schon Zeit verbraucht hat, hätte er sich locker schon einen billigen schnellen Hosten kaufen können.
--------------
Blog www.freeblogger.org: Deutscher IRC-Channel: irc.freenode.net #drupal.de ... Jabber-me: dwehner@im.calug.deXING

1) Ich habe wie geschrieben keine Zeit und vor allem keine Lust mal eben so eine FS-DB zu implementieren. Deshalb auch die Frage, ob es soetwas ind er Art schon gibt und es sind ja auch schon einige tolle Ideen und Module diesbezüglich aufgetaucht.

@dereine
Habe Ich behauptet, es handle sich um meinen Hoster? (Nachträgliche Erläuterung:Es war die Frage eines Bekannten, ob sich da was machen liesse und ich hatte gesagt, dass ich mich deshalb mal umhöre und n bissel rumprobiere. Aus seinem Problem ist dann Interesse an Performanceoptimierung geworden.)

Aus Deinem Kommentar schliesse ich, dass Du nicht kapiert hast, worum es mir geht, bzw zu faul ode runaufmerksam warst Dir mehr als den ersten Satz hier durchzulesen, aber entschlossen genug, mal eben Deinen unqualifizierten Senf dazuzugeben (Frei nach dem Motto: Egal ob ich etwas sinnvolles beizutragen habe: Irgendetwas habe ich beizutragen, auch wenns nicht zum Thema gehört).
Trollen hilft niemandem!

PS.
Und auf diese Kleinkinderkommentare bzgl des Hostings gehe ich jetzt gar nicht mehr weiter ein, denn das war nie Thema dieses Threads. Trollt woanders.

Mit Verlaub: Hast Du schonmal auf http://www.php.net/manual/de/refs.database.php geschaut? Ich tippe "Nein".

Brauchst Du ja auch gar nicht. Ist ja alles da.

Sind ja hier schon etliche genannt worden.

"dereine" bleibt hier :)

Aha:
http://www.php.net/manual/de/book.sqlite.php ist Bestandteil von PHP.
Was hindert Dich eigentlich daran loszulegen?
Mach ein wenig Wrapper um die db_-Funktionen und das war es?

@narres:
"Hast Du schonmal auf http://www.php.net/manual/de/refs.database.php geschaut? Ich tippe "Nein"."
Inwiweit würde mich der Link weiterbringen?
Ich scheine da betriebsblind zu sein.

Entweder hab ich mich da verlesen, oder da steht, dass SQL Lite nicht zwingend an ist (ich denke mal nur wenn man den Provider ganz lieb bittet ;)

------------
Aber das schrieb ich ja schon.

PS.
Und das Trollkommentar galt allgemein diesen einzeiligen Besserwissereien ohne Inhalt.

PPS.
Dass hier schon einige sinnvolle Module genannt wurden hab ich, wie geschrieben ja schon bemerkt.

Fazit:
1) SqlLite fällt nach wie vor weg
2) Ein Übersichtslink der von PHP unterstützten Datenbanken
3) Kein wirklicher Fortschritt in Richtung FS-basierende Datenbank, die nicht von kompilierten PHP-Binaries abhängt ;)

=>schade

MfG
Passer

... so einer der sich mit der ganzen "drupalcenter-prominenz" ;)anlegt.

-RB-

Ich finds halt nur doof, wenn ich auf eine gar nicht so abwegige Frage quasi "verarscht" werde ;)

Ja, sieht so aus. Mit dl() kannst Du Bibliotheken nachladen.

Dein:

ist faktisch falsch, denn "1)" fällt nicht weg. Aus "2)" kannst Du Dir auch was anderes aussuchen.
Die "3)" ist in soweit richtig, als dass Du da keine Plug&Play-Lösung in Drupal erwarten kannst. Zu Recht, da wir uns hier auf einer ganz anderen Ebene der Kommunikationsschicht befinden.
Das würde sich dann in Deiner "virtuelle DB-Schnittstelle" abspielen. Das hat dann allerdings alles nur noch sehr wenig mit Drupal zu tun, sondern mehr mit "wie schreibe ich PHP-Extension?". Wie man das dann in Drupal wiederum in die DB-Abstraction-Layer integriert ist hier ja bereits skizziert.
Willst Du das Ganze Drupal-integriert lösen, sind Ansätze wie http://drupal.org/project/boost ja auch schon erwähnt.
Möglichkeiten sind hier genug genannt. Welche für Dein Szenario passt. das musst Du dann schon selber entscheiden.

Mein Fazit:

Ich werde dass dumme Gefühl nicht los, dass der einzige, der sich hier wirklich abqualifiziert Du selber bist.

Daher neige ich als ernsthafte Lösung mittlerweile auch zu Drupal-Light: Mach Dir in Microsoft FrontPage eine Formatvorlage. Nenne die Drupal und simuliere die DB-Zugriffe mit FTP-Upload. Das ganze ist dann sogar eine echte Frontend-/Backend-Lösung.
Beschränkte Rahmenbedingungen erfordern halt beschränkte Lösungen.

Weniger betriebslind. Reine Unkenntnis, das wusste ich nicht.
Ist ja in C. Die Sourcen verfügbar.

Ich meine, dass das alles nicht zwingend in einer Extension realisiert werden muss, sofern es nicht zu Performancehungrig ist. Die Übersetzung auszulagern zumindest habe ich woanders schon gesehen.

Beschränkte Rahmenbedingungen erfordern raffinierte Lösungen; das ist meine Ansicht ;)

Und wegen Drupal Light: Ist das jetzt n Witz, der nicht lustig ist, oder gibt es das wirklich?
Und wenn ja, wo find ich darüber mehr? (Google spuckt mir dazu nur einen Theme aus)

MfG
Passer

Japp, das war ein Witz. Ist so was wie Sperma-Light: "Macht Schwanger und nicht dick".

"Beschränkte Lösungen" schliessen "raffinierte Lösungen" ja nicht aus. Nicht umsonst ist einer der Leitsprüche der Projektarbeit: "Die Kunst des Projektmanagement liegt in der Beschränkung".

Wenn ich das richtig sehe, dann hast Du jetzt alles was Du brauchst. Ob Du das dann als PHP-Extension oder wie auch immer (socket, syscall, ...) machst ist zum Testen ja auch relativ wurscht.

Das ist DER Aspekt welcher fuer mich die Hauptaussage Deines Thread darstellt.

Wenn also eine arschlahme DB das Problem ist und anwendbare Caching-Strategien nicht moeglich sind weil Shared Hosting oder unpraktikabel oder ...
dann koennte ma ja auch ueberlegen ob man auf die arschlahme DB voellig verzichtet.

Aus diesem Grund und dieser Ueberlegung heraus mein Tipp zu Drupal Light.

Hier noch etwas: Drupal, SQLite und Flatfile

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Drupal Light

Es gab unlaengst im DVC ein Dojo zu Drupal Light.

PS
Hoere ich mich an als das ich Witze machen wuerde?

=============== Tags ===============

Drupal Light, Drupal lite, Drupallite, Drupal ohne Datenbank DB, without Database, Flatfile, using Flatfiles, Flat files

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Wow, die Links sind nun echt brauchbar, danke, das stichwort FlatFile hatte ich gebraucht ;)

Ich wusste doch, dass ich sowas schonmal irgendwo gesehen hatte.

PS.
Kein wunder, das sich nichts finde, wenn das ganze "Drupal Lite" heisst (und nicht Light);)

Hier noch was auf die Schnelle zum Thema: Pro und Kontra oder Vor- und Nachteile von Flat files

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Hallo Leute,
ich muß zugeben, ich habe gerade weder Zeit noch Lust, den ganzen Thread zu lesen.
Es gab zwar schon einen kleinen Hinweis auf den Cacherouter, aber anscheined noch nicht auf die File-Cache-Möglichkeit, die sich damit einrichten lässt:
http://drupal.org/project/cacherouter

Weil die Entwicklung der Drupal 6-Version von Boost auf sich warten ließ (die ja jetzt endlich fertig ist) habe ich mich nach anderen DB-Beschleunigungs-Möglichkeiten umgeschaut und bin im Cacherouter auf die Möglichkeit des Filecaches gestoßen und habe diese schon bei ein paar Projekten eingesetzt. Ich denke, daß Filecaching auch bei angemeldeten Usern Sinn macht. Das habe ich allerdings noch nicht überprüft.
Die Installation verlangt eine kleine Anpassung der Settings.php und vor allem eine Schreib-Möglichkeit an sicherer Stelle für den Webserver. Dies könnte auch auf Günstig-Webspace gegeben sein, was man dann im Einzelfall mal testen könnte.

Viel Erfolg,
Carsten

--
paratio.com e.K.: Qualität-im-Internet.de