PHP -> JavaScript: AJAX-Response packen
peter nack
- programmiertechnik
0 Sven Rautenberg0 Nick0 peter nack0 hotti0 unknown
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.
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
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ß
Hallo,
wie so oft nach dem Posten ooOO
Denke mit gzhandler das gefunden zu haben, wonach ich suche.
MfG
Peter N.
Hallo,
dennoch einen Dank an euch beiden ;-)
MfG
Peter N.
PS: Nein, von den Daten kann ich nichts einsparen.
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
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
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
{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%20sendenGenau!
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.