Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The win here wasn't about scale, though. A tiny fraction of wikipedia users are logged in.

The win here was about individual page load time. And page load time is just as important, if not more so, for something new trying to vigorously grow as it is for the big sites.

(Disclaimer: HHVM alum.)



Yeah, this. We helped my boss' brother out with his wordpress ecommerce site.

His machine could easily handle the traffic thrown at it, but the page load time was slow. 2 seconds at best, with all machines involved being almost 100% idle. With various common tweaks such as caching, we got it down to about 800ms. We eventually replaced it with our own solution and got it to 50ms.

Scale never entered the picture because from our testing, we had the machinery in place to handle enough traffic to be wildly profitable. The user experience at 2 second page load times was vastly different from the user experience at 50ms though.


Could you describe what your own solution was?


It wasn't anything special. We used Java because it's what we knew, with a mix of spring and some home grown framework stuff that we've developed over the last 10 years.

MySQL over Postgres because that's what we had experience with at the time. Redis as both a cache and ephemeral store.


The win is _also_ about scale. The server CPU usage went down significantly - see http://bit.ly/1vqp1ki

So, more request can be served with a smaller number of servers.


Just curious, why did you use bit.ly there?



... just because I have that saved to use on IRC or anywhere else (like twitter) where a very long url would be inconvenient.

(I should've put a disclaimer there: I am one of the WMF engineers involved in the project).


Fyi, if you add a + to the end of any bitly URL, you'll see stats about the link. (Logged in users can set it to private but most times they don't)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: