4 ms·
I realize we're nitpicking, but I don't really get it: Why isn't it predictable (in the sense that any execution time for an HTTP request ever is)? You run http
by nir 17y ago
I realize we're nitpicking, but I don't really get it: Why isn't it predictable (in the sense that any execution time for an HTTP request ever is)? You run http_load for x seconds and see how many requests got served, then make change y and do it again. Obviously there are other variables but it's possible to get a fair idea.
- rythie 17y agoBecause as you described you have to try it to find out how much it will save you, by which point you could probably just roll it out already. Say you have 10 servers now and you expect business to grow by 10x in next year, so you put 6 months of dev. time into implementing caching. Then you get 10x the traffic in a month and you get V.C. investment as a result. You then have a problem, people are getting a bad experience and the development won't be done for another 5 months. Your CEO buys a rack full of servers, but you can't do anything with them because you don't have a scalable system. Alternatively you could find out after 6 months that you can't make that 10x performance jump after all. Twitter had this problem a while back, essentially their DB server got overloaded but it was already a 8 CPU, 64GB machine and despite having lots of money they couldn't quickly solve the problem, because you couldn't really get a bigger system. Facebook knows how to scale, they want to cut costs where they can to become (more) profitable.