peter nack: PHP -> JavaScript: AJAX-Response packen

Hallo,

mittels JavaScript stelle ich eine Anfrage an eine PHP-Datei.
Diese liefert JSON zurueck.
Je nach Anfrage koennen dabei schon mal ein paar hundert KB entstehen.

Welche Moeglichkeiten gibt es um die Response-Groesze zu minimieren?
Natuerlich so dass man das auf der Seite des Clients das ganze wieder zufriedenstellend "decrypten" kann.

Vielen Dank
Peter N.

  1. Moin!

    mittels JavaScript stelle ich eine Anfrage an eine PHP-Datei.
    Diese liefert JSON zurueck.
    Je nach Anfrage koennen dabei schon mal ein paar hundert KB entstehen.

    Mit Ajax den Server nach "weiteren Seitenteilen" zu fragen erlaubt doch gerade, dass man sich solche großen Datenmengen ersparen kann, weil man bei noch mehr Bedarf einfach noch weitere Daten nachlädt.

    Aber abgesehen davon unterstützt jeder aktuelle Browser Content-Encoding, üblicherweise mit gzip. Und der Server bietet dafür in der Regel auch schon ein passendes Modul an. Muss man nur noch prüfen, ob das auch genutzt wird.

    Die Startseite unseres Forums (unregistrierte Ansicht) hat dadurch etwas über 60 KB. Entpackt wären das 979 KB.

    - Sven Rautenberg

  2. hi,
    antwort 1: gzip-kompression durch den webserver + evtl. clientseitiges caching
    antwort 2: ich denke nicht, der anwender 100kb daten auf einmal benötigt..
    kannst du die nicht aufteilen und nur dann übertragen, wenn sie gebraucht werden?

    gruß

  3. Hallo,

    wie so oft nach dem Posten ooOO

    Denke mit gzhandler das gefunden zu haben, wonach ich suche.

    MfG
    Peter N.

    1. Hallo,

      dennoch einen Dank an euch beiden ;-)

      MfG
      Peter N.

      PS: Nein, von den Daten kann ich nichts einsparen.

  4. moin,

    Welche Moeglichkeiten gibt es um die Response-Groesze zu minimieren?

    Kommt darauf an, wie die Response aussieht. So wie ich die aufbaue, braucht die keine eckigen Klammern, Zeilenumbruchzeichen oder Leerzeichen zum Strukturieren, mit einer einfachen Serialisierung fallen zumindest diese Zeichen weg.

    http://rolfrost.de/cgi-bin/alib.cgi

    Weitere Möglichkeiten beschreibe ich in einem kleinen Handbuch, was auf meiner Seite bestellt werden kann

    http://rolfrost.de/binfile.html

    Viele Grüße,
    Horst

    1. Kommt darauf an, wie die Response aussieht. So wie ich die aufbaue, braucht die keine eckigen Klammern, Zeilenumbruchzeichen oder Leerzeichen zum Strukturieren, mit einer einfachen Serialisierung fallen zumindest diese Zeichen weg.

      {name:"Weßmöller",vname:"Änne",ort:"Nürnberg",senden:"Daten senden"}
      name=We%C3%9Fm%C3%B6ller&vname=%C3%84nne&ort=N%C3%BCrnberg&senden=Daten%20senden

      1. Kommt darauf an, wie die Response aussieht. So wie ich die aufbaue, braucht die keine eckigen Klammern, Zeilenumbruchzeichen oder Leerzeichen zum Strukturieren, mit einer einfachen Serialisierung fallen zumindest diese Zeichen weg.

        {name:"Weßmöller",vname:"Änne",ort:"Nürnberg",senden:"Daten senden"}
        name=We%C3%9Fm%C3%B6ller&vname=%C3%84nne&ort=N%C3%BCrnberg&senden=Daten%20senden

        Genau! Und jetzt stell Dir mal vor, es gäbe im DOM so Funktionen wie unpack() und read(), also Funktionen, die mit Rohdaten (bytes) umgehen können. Da würden die Zeichen "=" und "&" sowie das URI-Escape (percent encoding) auch noch entfallen (der € hätte wieder 3 byte statt 9). Zudem muss ein binary String nicht erst in den RAM gelesen und gesplittet werden.... JSON und XML sind eben doch nicht alles ;-)

        Hotti

        --
        Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
        1. {name:"Weßmöller",vname:"Änne",ort:"Nürnberg",senden:"Daten senden"}
          name=We%C3%9Fm%C3%B6ller&vname=%C3%84nne&ort=N%C3%BCrnberg&senden=Daten%20senden

          Genau!

          Genau was? Du hast doch behauptet, dein Format ist das Non plus ultra.
          In deinem eigenen Beispiel ist der JSON-String kürzer.
          Wenn du dann weiterdenkst und auch beliebige Strukturen so serialisieren willst, wird es noch schlimmer.
          {a:{one:1,two:2,three:3},b:[1,2,3]}
          a%5Bone%5D=1&a%5Btwo%5D=2&a%5Bthree%5D=3&b%5B%5D=1&b%5B%5D=2&b%5B%5D=3

          Und jetzt stell Dir mal vor, es gäbe im DOM so Funktionen wie unpack() und read(), also Funktionen, die mit Rohdaten (bytes) umgehen können.

          DOM setzt aber auf einem lesbaren strukturierten Textformat auf.
          Ich wüsste auch nicht, wozu ich diese unbedingt brauche. Die meisten Streams streamen ja ihre Daten auch nicht Binär, sondern textuell.

          Da würden die Zeichen "=" und "&" sowie das URI-Escape (percent encoding) auch noch entfallen

          Die hast du doch erst ins Spiel gebracht.

          Zudem muss ein binary String nicht erst in den RAM gelesen

          Nein? Wie willst du dann auf diesen zugreifen?

          und gesplittet werden....

          Ja, das ist richtig.

          JSON und XML sind eben doch nicht alles ;-)

          Sagt ja auch niemand, beide haben aber ihre Berechtigung.
          JSON ist z.B .das ideale Format um (belibig) strukturierte Daten nach Javascript zu übertragen.
          XML ein sehr allgemeingültiges, weit verbreitetes, textuelles (also lesbares) Format um (belibig) strukturierte Daten zu speichern. Mit definierten Schnittstellen zum Zugriff/Manipulation/Transformation.

          1. Hallo unknown,

            die Diskussion ist sinnfrei.
            Daher bin ich auch nicht darauf eingestiegen.

            MfG
            Peter