6 ms·
Great write up. This will be a good point of reference for future debates concerning the value of selecting high-performance platforms for web-applications. A
by bhauer 12y ago
Great write up. This will be a good point of reference for future debates concerning the value of selecting high-performance platforms for web-applications. A common refrain among advocates of slower platforms is that computational performance does not matter because applications are invariably busy waiting on external systems such as databases. While that may be true in some cases, database query performance is often only a small piece of an overall performance puzzle. Blaming external systems is a too-convenient umbrella to avoid profiling an application to discover where it's actually spending time. What to do once you've made external systems fast and your application is still squandering a hundred milliseconds in the database driver or ORM, fifty milliseconds in a low-performance request router, and another 250 milliseconds in a slow templater or JSON serializer?
Yes, three seconds for a page render is still uncomfortably slow, but it's substantially faster than the original implementation, and unsurprisingly frees up CPU for additional concurrent requests. It's a shame Wikimedia didn't have this platform available to them earlier.
Today web developers have many high-performance platform options that offer moderate to good developer efficiency. Those who use low-performance platforms may do their future selves a service by evaluating (comfortable) alternatives when embarking on new projects.
- tracker1 12y agoI've been very happy with node as a platform for 3+ years now... Though it tends to take the mindset of designing to scale instead of as a monolith... breaking workers up from services, and spreading the data out. I'd be more interested to see what, if any changes they have made to their other server components. Are they using NGINX vs Apache? What kinds of caching systems are they using? What is their database layout? Is their data sharded? These kinds of things I think are much more interesting, and at their scale at least as impactful.
- jonesnc 12y agoI would also like to hear more about their infrastructure. I do know they use Varnish as their cache server. https://wikitech.wikimedia.org/wiki/Varnish https://wikitech.wikimedia.org/wiki/Varnish
- kachnuv_ocasek 12y agoThere are some bits and pieces on https://wikitech.wikimedia.org/wiki/Main_Page https://wikitech.wikimedia.org/wiki/Main_Page
- tracker1 12y agoThanks for sharing... I'm kind of surprised they are using MariaDB over something like Cassandra.
- duskwuff 12y agoThey started with MySQL. Replacing that with MariaDB is a whole lot simpler (not to mention, less risky!) than replacing it with something completely different like Cassandra.
- rimantas 12y agoThey started with PostgreSQL iirc, only later migrated to MySQL.
- samspenc 12y agoMariaDB is MySQL compatible. Had they gone with Cassandra, they would have had to replace the PHP-based MediaWiki software with something else. So not only the database, the entire software stack would have to be replaced as well. Also, speaking from a few years' personal experience with HBase / Cassandra, the support for non-Java languages on these two NoSQL databases is small (though it is getting better.)
- tracker1 12y agoI worked on a project that used C* with node.js and it worked out very well... cluster of node servers, with minimal processing over a cluster of C* servers... very fast response times under some really big load. Though node.js tends to be very flexible in terms of wrapping a friendlier interface around a less friendly one.
- 12y ago
- balls187 12y ago> 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 agoOn 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 agoThe 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 agoThe 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 agoJust curious, why did you use bit.ly there?
- Apofis 12y agoFor our rather heavy Magento installation, we went from up to 6 sec loading times to about 600ms with HHVM without any fancy full page caching solutions. Thankfully Facebook decided to do something about it. It saved us.
- ademarre 12y agoIs the Magento codebase fully compatible with HHVM?
- jazzdan 12y agoThe HHVM team runs the tests of popular GitHub PHP repositories on HHVM, it's available here: http://hhvm.com/frameworks/ http://hhvm.com/frameworks/ According to that 99% of magento2 tests are passing.
- TazeTSchnitzel 12y agoSix seconds? What were you doing that was so time-consuming?
- davidgerard 12y agoWhich version of Magento? This is something I'm suspecting we could really do with. (We're running 1.14 Enterprise.)
- TazeTSchnitzel 12y agoWikipedia faces unique challenges, however, that many web applications do not face. Almost the entirety of the page rendered is user-generated content produced from hand-written wiki markup that must be parsed and rendered, and that uses complex nested templates. MediaWiki is basically a turing-complete applications platform. The wikipedia page for Barack Obama transcludes 199[0] unique templates, with 585 total non-unique invocations, and that's not counting the templates transcluded by those templates. Some of Wikipedia's templates are so complex that they had to be rewritten in Lua. I don't think Wikipedia is really a typical case. Most websites probably don't have the CPU burden Wikipedia faces. [0]https://en.wikipedia.org/w/index.php?title=Barack_Obama&action=edit https://en.wikipedia.org/w/index.php?title=Barack_Obama&acti...
- eru 12y ago> MediaWiki is basically a turing-complete applications platform. Perhaps MediaWiki should figure out how to use a weaker form of computation?
- ttflee 12y agoI am afraid that the way those mark-ups have been used is the way they have encouraged.
- TazeTSchnitzel 12y agoOh, the turing-completeness is new, it wasn't in the past. Using Lua was to improve template performance.
- davidgerard 12y agoActually, it's been around for years - it was accidental. ParserFunctions is a good example of a DSL accidentally achieving Turing-completeness, at which point people start doing awful, awful things in it because they can. So they went to Lua because a proper programming language is superior in every way to an accidental one.