Forum

Is Hiawatha (10.0) able to serve ONLY 'static' (not on-the-fly) compressed GZip (or even better BZip

Sascha Kühl
17 December 2015, 18:58
Hello Hugo,


i want to serve static (not on-the-fly) gzip / bzip2 compressed (html / css, and so on) files with Hiawatha (10.0) ... but it looks like that in release 10.0 of Hiawatha, this is impossible !

The uncompressed file in the directory seems to be on-the-fly gzip compressed, because there's no gzip compressed static file ... ! -- But in the case there's a gzip compressed file it seems that Hawatha gzip compressed the uncompressed file instead serve the already compressed file.

I've compressed the uncompressed static file with gzip and the '-9n' options so this file is a few bits smaller then the file that is compressed via gzip by Hiawatha on-the-fly -- that's seems to be the evidence that Hiawatha doesn't serve already compressed files.

By the way, is there any possibility to serve even bzip2 compressed static files ?!
I know with compression i'm saving a lot of data -- and because every bit i'm saving, effects my SEO ranking, it's very important to me.

Long story short: I want to serve ONLY already gzip (or even better bzip2) compressed files -- i don't want hiawatha to compress that file over and over again, for that reason that i does this job once before on my own.

Sorry for my poor english; i only speak german by native.


Kindly regards, Sascha Kühl.
Rene
26 December 2015, 22:18
Hallo Sascha,

laut Source

https://github.com/hsleisink/hiawatha/blob/master/src/libfs.c#L376

erstellt er ein gezipptes Dublikat der Originaldatei. Die Frage ist nur wohin.
Rene
26 December 2015, 22:20
more Info:

"GZip support has been implemented. Hiawatha uses the work directory to store gzipped versions of requested file. So, GZipping is not done over and over again for every file."

From https://www.hiawatha-webserver.org/weblog/104
Sascha Kühl
27 December 2015, 22:13
Hallo Rene,

derzeit liefert nginx meine statische Webseite aus; die zuvor von mir einmalig via gzip komprimierten Dateien liegen übrigens im RAM ... und Umleitungen erfolgen (von HTTP zu HTTPS resp. anderer Domains / URL) per (nginx-)Return-301-Anweisung!
Leider müsste ich bei Hiawatha scheinbar (teilweise) RegExp für derartige Umleitungen nutzen - dass ist CPU- und zeitintensiv.
Die Konfiguration von nginx empfinde ich zudem als logischer, konsequenter, beständiger ...!

Hab's mit Hiawatha aufgegeben, für mich zählt jeder eingesparter Bit und jede vermiedende 1000stel Sekunde.
Relevante Angriffe werden (u. a.) mittels iptables(-Regeln) abgewehrt.
Ich hatte gehofft in Hiawatha einen noch schnelleren Webserver zu finden ... in Bezug auf meine Webseite sehe ich allerdings keinen Performance-Gewinn, denn man muss natürlich auch bedenken dass ich in nginx keine RegExp benötige, etc.!

Trotzdem danke für Deine Antwort; Hugo sagt wohl nix dazu - naja, auch gut.

Für mein Empfinden ist die Perfomance meiner Seite relativ gut ... aber sieh' selbst: Guide zu GNU grep und RegExp (BRE, ERE, PCRE) [www.grepmaster.eu] !


Ciao, Sascha.
Rene
2 January 2016, 18:14
Hallo Sascha,

das Encoding in Hiawatha ist transparent, in der URL ist von der gezippten Datei nichts zu sehen. Wenn hiawatha erkennt, dass der Client zip kann dann haut er die gezippte Datei raus.

In Sachen Performance sind gatling und gwan unschlagbar.
This topic has been closed.