4 ms·

> This will be a good point of reference for future debates concerning the value of selecting high-performance platforms for web-applications. Keep in mind, W

> This will be a good point of reference for future debates concerning the value of selecting high-performance platforms for web-applications. Keep in mind, Wikipedia is at scale that most web applications will never, ever get to. It's important to think about performance and scale, but it's not the only important trade off engineers should concern themselves with.

bad_user 12y ago
On the other hand I find that the problems where performance is relevant are the problems that are technically interesting and rewarding to solve. It's also not necessarily about scale, as in number of users that one needs to serve. There are lots and lots of problems where performance is very relevant, from startups that can't afford to scale horizontally, to projects in an industrial setting that have to be rock solid, to participating in real-time bidding on RTB platforms, to games in which frames being dropped are a disaster, to the platforms on top of which we build stuff. Quite the contrary, I believe that too many software developers are focusing on building front-ends to a database, but this isn't necessarily because these problems are solving real needs.
kmavm 12y ago
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.)
- _joe 12y ago
  The win is _also_ about scale. The server CPU usage went down significantly - see http://bit.ly/1vqp1ki http://bit.ly/1vqp1ki So, more request can be served with a smaller number of servers.
  - schrodinger 12y ago
    Just curious, why did you use bit.ly there?
    - forgotpasswd3x 12y ago
      I'm curious too. The un-shortened URL is https://ganglia.wikimedia.org/latest/graph.php?r=year&z=xlarge&c=Application+servers+eqiad&m=cpu_report&s=by+name&mc=2&g=cpu_report https://ganglia.wikimedia.org/latest/graph.php?r=year&z=xlar...
    - _joe 12y ago
      ... 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).
    - metaprinter 12y ago
      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)
- sbov 12y ago
  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.
  - lonnyk 12y ago
    Could you describe what your own solution was?
    - sbov 12y ago
      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.
arenaninja 12y ago
> Keep in mind, Wikipedia is at scale that most web applications will never, ever get to. As I read the article I thought exactly this. Scaling is a nice problem to have. I keep playing around with Nginx, elasticsearch, and other tech that's supposed to help PHP's performance problem, but from personal experience, missing database indexes for complex joins have been the issue every time. I'm unlikely to get to use the tech I play with unless I switch jobs. But back to the point, this is a great writeup, and I think a big step forward for both PHP and HHVM
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
davidgerard 12y ago
The win here is because the thing it speeds up is hugely CPU-bound. This will also make tiny MediaWiki installs just as much faster.

bad_user 12y ago

On the other hand I find that the problems where performance is relevant are the problems that are technically interesting and rewarding to solve. It's also not necessarily about scale, as in number of users that one needs to serve. There are lots and lots of problems where performance is very relevant, from startups that can't afford to scale horizontally, to projects in an industrial setting that have to be rock solid, to participating in real-time bidding on RTB platforms, to games in which frames being dropped are a disaster, to the platforms on top of which we build stuff. Quite the contrary, I believe that too many software developers are focusing on building front-ends to a database, but this isn't necessarily because these problems are solving real needs.

kmavm 12y ago

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.)

_joe 12y ago
The win is _also_ about scale. The server CPU usage went down significantly - see http://bit.ly/1vqp1ki http://bit.ly/1vqp1ki So, more request can be served with a smaller number of servers.
- schrodinger 12y ago
  Just curious, why did you use bit.ly there?
  - forgotpasswd3x 12y ago
    I'm curious too. The un-shortened URL is https://ganglia.wikimedia.org/latest/graph.php?r=year&z=xlarge&c=Application+servers+eqiad&m=cpu_report&s=by+name&mc=2&g=cpu_report https://ganglia.wikimedia.org/latest/graph.php?r=year&z=xlar...
  - _joe 12y ago
    ... 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).
  - metaprinter 12y ago
    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)
sbov 12y ago
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.
- lonnyk 12y ago
  Could you describe what your own solution was?
  - sbov 12y ago
    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.

arenaninja 12y ago

> Keep in mind, Wikipedia is at scale that most web applications will never, ever get to. As I read the article I thought exactly this. Scaling is a nice problem to have. I keep playing around with Nginx, elasticsearch, and other tech that's supposed to help PHP's performance problem, but from personal experience, missing database indexes for complex joins have been the issue every time. I'm unlikely to get to use the tech I play with unless I switch jobs. But back to the point, this is a great writeup, and I think a big step forward for both PHP and HHVM

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

davidgerard 12y ago

The win here is because the thing it speeds up is hugely CPU-bound. This will also make tiny MediaWiki installs just as much faster.