Cache compressed output

[expressjs]

Cache compressed output

[dougwilson]

Ideally, if performance is important, you should not be doing compression with Node.js at all, especially since these compression requests are using your available thread pool in Node.js.

Using Varnish would provide exactly what you're looking for.

If you insist on using Node.js to do compression (which I don't recommend if you are about performance), I'm pretty certain there are modules on npm that do compression with caching.

[dougwilson]

Otherwise PRs are welcome to implement this feature and then we can discuss the implementation in the PR :)

[rodrigouroz]

Honestly I don't get it how you tell me not to do compression on node in a repository about doing compression in node :-)

That confused me a little.

I ended up putting my middleware before compression and I'm using node-cache to store the compressed output (so I'm not compressing it again each time I return it from the cache).

If you think it's a valid use case for this module (to use node-cache I mean since the output is always the same with the same input) then let me know and I'll do a PR.

[dougwilson]

Honestly I don't get it how you tell me not to do compression on node in a repository about doing compression in node :-)

Well, this repo is here for non-production and small sites, because people want it, so we provide it, but it doesn't mean it's a good idea :) We are probably the best one that exists, but that still doesn't solve the fundamental issue of doing this in Node.js in the first place :)

If you think it's a valid use case for this module (to use node-cache I mean since the output is always the same with the same input) then let me know and I'll do a PR.

I'm glad you got something working! I would rather go towards "separation of concerns", where this module does compression and... that's it. BUT if you feel like the solution you're doing is working well, I would 100% be interested in adding an example of using compression + node-cache to the README :)

[ORESoftware]

hey guys, caching might be a good idea, but maybe it's better to gzip all your components before the server starts up?

[rodrigouroz]

In my case that's not possible. I'm talking about an API that returns objects as json. For the amount of time I cache the response from the database I'm caching the compressed output instead of the response from the database, so each time I respond with the cached version I don't need to compress it again.

[ORESoftware]

It's 2015, networks are faster and have more bandwidth - I would read the latest information about whether it's really worth compressing JSON responses. I have approximately 3 hours total experience with GZIP and no computer science degree but I would venture to guess it's not worth it to compress JSON responses. You have to compress it on the server and then decompress on the client, that's a lot of computational effort and slows things down.

Furthermore, you are going to have a hell of a lot of extra logic to deal with caching on the server.

Not to toot my own horn but I think it makes a lot more sense to only compress text assets before the server starts up, then you don't have to worry about runtime caching logic which could get pretty nasty and you don't have to lose CPU cycles to runtime compression.

[rodrigouroz]

That's a fair and valid point. I'm just doing things the way my client wanted me to do it but I guess it will all come down to having a proper test with and without the compression. This is an API that's going to live in Heroku and accessed mostly from the same country so perhaps you have a point.

[ORESoftware]

Like I said, I really have no idea what I am talking about, that is just a guess from the brief experience I have with this stuff. If you find good benefits from compressing JSON responses, please let me know, it's just my guess that, especially for small JSON responses, it's not worth it. If you have large JSON responses that are cacheable, then it might be worth it.

[ORESoftware]

furthermore, if you are using a cluster of servers / the NPM cluster module, caching makes even less sense. Because the cache on one server won't be the same as the others. You'd have to then use Redis, or whatever, which would introduce lag that you are trying to avoid in the first place. AFAICT, statelessness on servers still rules the day when it comes to using more than one server. I hope that makes sense.

[ORESoftware]

You all might find this very interesting:

http://www.quora.com/If-you-use-the-highest-compression-rating-with-gzip-does-it-take-longer-to-gunzip