5 ms·
Sloppy thinking. Sloppy measurements. If you have almost 1000 reqs/sec initially, that's 1ms per request. By bringing this down by the amazing 400% (!!) percen
by disconnect 19y ago
Sloppy thinking. Sloppy measurements.
If you have almost 1000 reqs/sec initially, that's 1ms per request. By bringing this down by the amazing 400% (!!) percent you've shaved off 3/4th of a milisecond per request. Congratulations - you have no idea what you've been measuring. Just the way in which the request is logged can make a 5ms difference. Insignificant and completely uninteresting.
Back when 3d game programming was cool, people would get a rotating cube and show off their 1200 fps frame rate. Of course they would get upset that by adding a texture to the cube the framerate dropped by 400 frames to 800 fps. "Textures are slow!", they'd say. Yeah, right...
- igrigorik 19y agoFair enough, but this is / was a controlled experiment. The codebase did not change, the method through which the cached content was served did. Hence the textured cube argument is not the best analogy here, I think. :) Having said that, I agree -- there is a lot of other variables out there, and they should not be swept under the rug.
- disconnect 19y agoThe point of the textured cube analogy was that if you don't consider the context of the benchmark, the numbers aren't useful. The kid doesn't realize that if texturing a cube brings a framerate down from 1200 to 800 fps, is as significant as going down from 62 fps down to 60. Even though that is only a 2 fps difference. A 400% performance gain is a constant performance improvement. I don't think a system like nginx + memcached have linear performance benefits in the first place.