HI, Might this be helpful https://github.com/NYTimes/gziphandler
Google strategy is right if you assume there are way more clients accepting gzip than those not accepting it. Doing so, in fact, they remove a whole lot of cpu resources. I believe the assumption is correct even though i have not checked. Regarding your questions "What is the best ?", i d say it s highly dependent of the context you are operating. For 3, looks likes this may be helpful https://github.com/mh-cbon/watchnproduce but memory usage will take a hit in this strategy. On Tuesday, January 10, 2017 at 7:30:41 PM UTC+1, Anmol Sethi wrote: > > Hello, I'm trying to write a http handler to serve gzipped files but if > the client does not accept the gzip content-encoding, it falls back to > identity. > > I see three ways to do this. > > First is dynamic gzipping. If a client supports it and a file is > gzippable, I gzip the file on the fly and then serve it. Interestingly, I > noticed that google does the opposite. They have the gzipped versions of > the files stored, but when a client does not accept the gzip > content-encoding, the server decompresses the gzipped file on the fly and > serves that. This first method is attractive because it is simple to > implement but it can be CPU intensive. > > Second is static gzipping on the file system, e.g. storing .gz files next > to regular files. Another variation on this might be to have a second root > folder, one which contains the gzipped files. This is attractive because > you can gzip files at the highest compression level to save the most on > bandwidth but it requires some setup. > > Third is a combination of the first two, gzipping files as they are > requested and storing them in an in memory cache and serving subsequent > requests to clients that accept the gzip content-encoding from there. This > combines the simplicity of the first option with the performance benefits > of the second option but it is significantly more complex to write the code. > > Which do you think is the best option? > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
