Ankündigung

Einklappen
Keine Ankündigung bisher.

Text-Datei als Datenbank

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    reVerB
    Dir ist aber klar, dass wir hier von einer simplen Homepage reden und diese eher auf einem Server liegt, der sich den ganzen Tag ausruhen kann? Man kann es aber auch mit der Performance-Optimierung übertreiben.
    Die Deutsche Rechtschreibung ist Freeware! Du darfst sie kostenlos nutzen, allerdings ist sie nicht Open Source, d.h. Du darfst sie nicht verändern oder in veränderter Form veröffentlichen.

    Kommentar


    • #17
      Zitat von reVerB Beitrag anzeigen
      Genau dafür gibt es eben auch strukturierte Formate, von denen ich 3 in meinem Beitrag angesprochen habe. Mit denen hat man das Problem mit den Delimitern nicht. Dafür gibt es die Dekodierer/Parser und kodierer.
      Das wovon du redest sind keine strukturierten Formate, sondern (in welcher Form auch immer) serialisierte Arrays. CSV ist ein strukturiertes Format und dort machen Delimiter sehr wohl immer wieder Probleme.

      Zitat von reVerB Beitrag anzeigen
      Es macht aber für den Server einen ordentlichen Unterschied. Es wäre nicht verkehrt, nicht immer alles nur aus dem Blickwinkel des Entwicklers selbst zu betrachten sondern sich auch mal Gedanken zu machen, was da eigentlich auf dem Server passiert. Im Vergleich zu den Dateioperationen und den Parsern für JSON treibt der Server beim Ausführen der SQLite3 (in C implementiert) Funktionen richtig Sport. Je geringer also der Datenbestand ist, um so weniger lohnt es sich, SQLite und noch weniger ein serverbasiertes RDBMS zu verwenden. Und so lange wir nicht pro Datei Millionen Datensätze liegen haben und in den Beständen nicht gesucht oder Relationen aufgelöst werden müssen, reicht die Dateivariante vollkommen aus und ud ist schonender für den Server und seinen Ressourcen. Gerade wenn man für ein sehr kleines Projekt auch einen entsprechend kleinen shared Hosting Webspace verwendet. Da geht es um jeden Takt, den man sparen kann.
      Völliger Quatsch. In High Performance Umgebungen wird sowieso alles nur gecached, ob der Befehl im Hintergrund ein paar Millisekunden länger (und das ist bei dem hier angesprochenen Ausmaß eh schon konservativ geschätzt) braucht ist vollkommen egal. Takte sparen? Und dann eine interpretierte Sprache wie PHP verwenden? Laufzeitabschätzung und Performancemessung macht auch überhaupt nur Sinn bei größeren Instanzen. Bei n <= 3 ist auch O(n^2) schneller als O(2^n). Bei Performance kommt es fast nie darauf an einzelne Takte zu sparen, weil es egal ist ob etwas 7ms dauert oder 11ms - das merken wir ja nicht mal. Relevant ist Performance wo etwas entweder 1 Sekunde dauert oder 10.

      Es ist auch entscheidend, wie viele Anfragen pro Zeitintervall ein Server verarbeiten kann. Nicht nur von der Rechenleistung her, sondern auch von der Netzwerkkapazität. Je schneller das Rechenwerk eine Anfrage beantworten kann, um so schneller ist wieder Kapazität auf dem Netzwerkinterface frei. Da spielt es keine Rolle, wie stark der Server ist. 10 GBit/s sind 10 GBit/s. Egal ob Pentium D oder Xeon 16-Kerner, 1 GB oder 128 GB RAM. Und je mehr Power die Maschine hat, umso mehr Kunden packt ein Shared Hoster auf die Maschine drauf. Und da man das Netzwerkinterface selbst aus PHP heraus nicht wirklich beeinflussen kann, muss man eben dafür sorgen, das PHP so schnell wie möglich antworten kann. Je schneller das Skript also durch ist, umso schneller kann der nächste nachrutschen und um so später muss man horizontal skallieren, wenn der Server am Ende is
      Auch die Rechnung geht nicht auf. Die Netzwerkbelastung ist vollkommen gleich, egal ob file-basiert oder Datenbankbasiert. Und die 10 GBit/s Leitung wirst du mit 1 KB Requests und 1 KB Responses wohl sowieso nicht auslasten, alle anderen Inhalte (CSS, Bilder, JS) fallen da mehr ins Gewicht.

      Kommentar


      • #18
        Vor allen anderen Dingen ist disk-I/O der Flaschenhals schlechthin. Grade im Web, wo viele gleichzeitige (konkurrierende) Zugriffe stattfinden, ist eine Datei die schlechteste aller Lösungen.
        Sobald erstmal die Zahl der Dateizugriffe ein gewisses Maß übersteigt, wird die Festplatte nicht mehr hinterherkommen mit dem Laden. Es entstehen Wartezeiten (I/O wait), Prozesse müssen auf die Daten warten, die CPU langweilt sich derweil und auch das Netzwerk hat nix zu tun... trotzdem fühlt sich alles wie zäher Kaugummi an, weil nix mehr voran geht. Also nicht wundern wenn die Webseite und auch der ganze Server (z.B. bei SSL Zugriff auf Konsole) nur mehr sehr träge reagiert.

        Bei Webseiten für den Privatgebrauch mag das noch akzeptabel sein, aber wenn die Ansprüche steigen, wird eine Dateibasierte Lösung immer scheitern.
        Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

        Kommentar

        Lädt...
        X