Opened by styx-cc at 2020-04-19 01:22
User since
2006-05-20
533 Artikel
BenutzerIn
2006-05-20
533 Artikel
BenutzerIn
Hey,
vielen Dank erstmal für die Unterstützung, deine Lösung werde ich auch gleich mal ausprobieren und "Benchmarken".
Das Ding ist, dass GZIP vergleichsweise langsam rechnet und die de/komprimierung viel CPU und Zeit in Anspruch nimmt, was bei häufigem Datenaustausch nicht der beste Kompromiss ist - vorausgesetzt man kann mit Clients rechnen, die mit einer Breitbandanbindung daherkommen.
Wenn ich den verlinkten Benchmark zugrundelege (die dort verwendete CPU kommt mit der meinigen ganz gut überein) und eine Anbindung von ein mal 20 und ein mal 50/mbit:
Interessant! Damit habe ich cniht gerechnet, Es verschiebt sich aufgrund der Bandbreite leicht zugunsten von LZO und LZ4 aber GZIP schneidet besser ab, oder hab ich mich verrechnet? Das einzige was unschön ist, ist dass er bei ~50MB ca. 1 Sekunde am Server komprimiert, da wäre LZ4 wesentlich angenehmer, sonst friert die Anwendung ein oder man lässt sich was einfallen.
Ja, ich habe mich auch gewundert, der Output von Perl und JS scheint nicht kompatibel zu sein und beim suchen im Netz finde ich auch nur sehr spärlich Information zu meinem Anliegen, ich hätte gedacht, das dass üblich wäre, weil mir die Vorteile auf der Hand zu liegen scheinen (wenig RAM und CPU für die Einsparung von viel Bandbreite = glückliche Volumenratebenutzer und viel Zeitersparnis).
Ich habe auch MINILZO-JS und
Compress::LZO ausprobiert, aber da bekomme ich beim besten Willen nicht hin, der JS-Funktion lzo1x.decompress(state); die Parameter so mitzugeben, dass er sich nicht aufhängt oder überhaupt etwas tut. Strings in Buffer konvertiert und vice versa, mit split rumhantiert, etc.
Lieben Gruß
vielen Dank erstmal für die Unterstützung, deine Lösung werde ich auch gleich mal ausprobieren und "Benchmarken".
Das Ding ist, dass GZIP vergleichsweise langsam rechnet und die de/komprimierung viel CPU und Zeit in Anspruch nimmt, was bei häufigem Datenaustausch nicht der beste Kompromiss ist - vorausgesetzt man kann mit Clients rechnen, die mit einer Breitbandanbindung daherkommen.
Wenn ich den verlinkten Benchmark zugrundelege (die dort verwendete CPU kommt mit der meinigen ganz gut überein) und eine Anbindung von ein mal 20 und ein mal 50/mbit:
Code: (dl
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
MB de/compress 20mbit 50mbit Gesamt
Filesize445 0s 178s 71s 249s
GZIP 120 11.6s 48s 19s 67s
LZO 161 3.1s 64s 25s 89s
LZ4 159 1.7s 63s 25s 88s
MB de/compress 20mbit 50mbit Gesamt
Filesize 49.44 0s 19.8s 7.9s 27.s
GZIP 13.33 1.3s 5.4s 2.1s 8.8
LZO 17.88 0.35s 7.1s 2.8s 10.2
LZ4 17.66 0.19s 7s 2.8s 10.1
MB de/compress 20mbit 50mbit Gesamt
Filesize 5.5 0s 2.2s 0.88s 3.08s
GZIP 1.48 0.145s 0.6s 0.24s 0.985s
LZO 1.99 0.04s 0.78s 0.31s 1.09s
LZ4 1.96 0.021s 0.78s 0.31s 1.09s
Interessant! Damit habe ich cniht gerechnet, Es verschiebt sich aufgrund der Bandbreite leicht zugunsten von LZO und LZ4 aber GZIP schneidet besser ab, oder hab ich mich verrechnet? Das einzige was unschön ist, ist dass er bei ~50MB ca. 1 Sekunde am Server komprimiert, da wäre LZ4 wesentlich angenehmer, sonst friert die Anwendung ein oder man lässt sich was einfallen.
Ja, ich habe mich auch gewundert, der Output von Perl und JS scheint nicht kompatibel zu sein und beim suchen im Netz finde ich auch nur sehr spärlich Information zu meinem Anliegen, ich hätte gedacht, das dass üblich wäre, weil mir die Vorteile auf der Hand zu liegen scheinen (wenig RAM und CPU für die Einsparung von viel Bandbreite = glückliche Volumenratebenutzer und viel Zeitersparnis).
Ich habe auch MINILZO-JS und
Compress::LZO ausprobiert, aber da bekomme ich beim besten Willen nicht hin, der JS-Funktion lzo1x.decompress(state); die Parameter so mitzugeben, dass er sich nicht aufhängt oder überhaupt etwas tut. Strings in Buffer konvertiert und vice versa, mit split rumhantiert, etc.Lieben Gruß
Pörl.