The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
There's no single reason, but a whole lot of reasons:
ReplyDeleteHeavy usage of caching (APC and memcached), which drastically cuts processing time.
Slide 12 compares load time with APC (~130 ms) versus without it - 4050 ms. That's 30x faster!
Usage of HipHop, which converts PHP into C++ code (which is then compiled into much more efficient machine code than actual PHP).
Facebook uses PHP and MySQL, but that's not the only thing they use. For example, they use Erlang for their chat, Hadoop clusters for some of their storage. If you go visit their careers page, you'll see they are hiring developers with experience in C++, Java, Python, and others.
Facebook has data distributed across many, many servers. In June 2010, FB had 60,000 servers. (think that's too much? Google had half a million... 5 years ago)
Facebook sends as little traffic as possible: they use static CDNs to deliver static content. Gzip to compress data. Cookies, Javascript, HTML - everything is cut back to reduce the number of bytes sent over the network. They use a technology they call "BigPipe", which sends partial content rather than the whole page.
to mention a few...
Ultimate reason: http://memcached.org/
ReplyDeleteThey claim 98% of everything you see on Facebook is from their massive memcache server cluster.
Check out http://facebook.com/techtalks.
ReplyDeleteThey have some great videos describing many of their various optimizations. For instance, there's a talk on memcached (which helps speed up common key gets) and their front-end optimizations (doing lazy loading of Javascript, etc).
The amazing part is how large everything is at facebook. With millions of users and thousands of servers, even a seemingly small optimization can end up saving them millions of dollars or gigabytes of memory.
More info at http://highscalability.com/blog/category/facebook
ReplyDeleteBy
ReplyDeleteCaching
Having many servers
Having many smart people working on making it fast.
This article talks about the inner workings of Facebook: http://royal.pingdom.com/2010/06/18/the-software-behind-facebook/
ReplyDeleteFacebook was not only using MySql - it started out using Cassandra, and is migrating over to HBase. Applications like FB need a highly scalable Database.
ReplyDeleteWatch this presentation of Aditya Agarwal, Director of Engineering at Facebook, this presentation talks about Facebook’s architecture and its major components (LAMP (PHP, MySQL), Memcache, Thrift, Scribe).
ReplyDeleteThey have a compiled version of php, in fact.
ReplyDeleteMy guess would have to be: insane amounts of crazy hardware, brutally efficient code, and a database structure optimized with caching, denormalization, clustering...