Siapapun pasti tahu kalo internetan lebih cepat tentu saja lebih nyaman bagi user. Hal ini lah yang menjadi issue penting yg harus dicapai FACEBOOK di akhir 2008 hingga pertengahan 2009: “The site twice as fast”. Para engineer-engineer facebook berjuang keras menuangkan inovasi-inovasi yang patut diimplementasikan untuk mewujudkan cita-cita ini.

Mungkin Anda berpikir, bagaimana cara facebook meload suatu halaman-nya semisal NewsFeed begitu cepat? Sementara dalam NewsFeed itu sendiri sangat banyak jenis data yang harus dimuat. Sebagai programmer, Kalo kita berpikir secara konvensional, butuh query atau paling kasarnya inner join tabel kesana sini agar kita bisa mendapatkan data Profile Name disudut kiri atas, Event di kolom kanan, Friends di kolom kiri, Status Update ditengah-tengah, dan yg lainnya yg akan kita muat bersamaan dalam satu halaman web. So, what are the secret weapons they use?? one of those called “BigPipe”.

Oiya, sebelum lanjut, tuh gambar utama rada-rada kontra dengan isi postingan kalee ini … Hehehehe…

BigPipe merupakan suatu “rancangan ulang” yg sangat fundamental dalam sistem “web’s page-serving” facebook. Ide utamanya adalah memilah-milah tiap-tiap halaman facebook tersebut menjadi bagian-bagian kecil yang disebut “pagelets”. Bagian-bagian yg dipilah ini akan digabungkan kembali menjadi satu halaman utuh melalui eksekusi beberapa operasi dalam WebBrowser Client. Konsep ini diadaptasi dari konsep PIPELINING yg diterapkan pada kebanyakan microprocessor saat ini: “multiple instructions are pipelined through different execution units of the processor to achieve the best performance”. BigPipe tidak membutuhkan perubahan khusus disana-sini, semisal harus menggunakan browser terbaru, atau para teknisi harus merombak lagi sistem dalam server mereka. Hal ini dikarenakan BigPipe sepenuhnya diimplementasikan menggunakan PHP dan Javascript.
minum dulu…

 

Motivasi

Untuk memahami apa itu BigPipe, kita flashback sejenak pada sistem penyajian suatu halaman web konvensional, suatu konsep yang tidak banyak berubah sejak adanya World Wide Web. Seperti kita ketahui, konten-konten website saat ini memang lebih dinamis dan interaktif dibandingkan satu dekade yang lalu, namun perubahan mendalam konten-konten tersebut tidak dibarengi dengan perubahan konsep PageLoader yang diharuskan lebih cepat dalam memuat suatu halaman. Dalam konsep tradisional, LifeCycle si user melakukan request ke WebServer kira-kira demikian:

1. Browser client mengirimkan HTTP request ke WebServer
2. WebServer membaca request, menelaah request, menyediakan data yg dibutuhkan, kemudian memformulasikan front-end (baik itu dalam format HTML, JSP, ASP, dll) yg kemudian dikirimkan balik ke Browser client melalui apa yang disebut HTTP Response (via internet).
3. Browser client menerima dan membaca response dari WebServer, membuat kerangka struktur DOM(Document Object Model) yang merepresentasikan dokumen HTML, kemudian mendownload CSS dan JavaScript yg direfer oleh HTML tersebut.
4. CSS selesai didownload, implementasikan pada struktur DOM tadi.
5. Javascript selesai didownload, impelementasikan pada struktur DOM kemudian eksekusi fungsi-fungsi didalamnya.

Konsep tradisional tersebut sangat tidak efisien untuk tipe website saat ini, karena banyak operasi dalam sistem dieksekusi secara sekuensial. Artinya proses berikutnya baru bisa dieksekusi, setelah proses yg satu selesai.

Saat Web Server memformulasikan data yg dibutuhkan dalam memuat suatu halaman(baca: Generation Time), Apa yang dilakukan browser Anda??? MENUNGGU, bukan? Browser client tak berbuat apa-apa selain menunggu. Membuang waktu menunggu si WebServer melakukan tugas life-cyclenya. Saat WebServer selesai dengan tugasnya, tiba-tiba si browser dihadang sederetan data (HTML, CSS, Javascript, dll) yang harus segera dimuat(baca: Rendering Time), sedangkan si WebServer tak bisa berbuat apa-apa dengan apa yg terjadi pada browser. Persoalan yg dihadapi browser ini lah yg disebut “Bottleneck”. Bayangkan lubang botol yang kecil, sementara banyak sesuatu yg harus dikeluarkan atau pun dimasukkan.

Dengan memparalelkan kerja WebServer’s Generation Time dan ClientBrowser’s Rendering Time, kita tidak hanya mengurangi latensi yg terjadi antara WebServer dan Browser tetapi juga memuat apa yg bisa ditampilkan kehadapan USER sedini mungkin. Dampaknya, secara signifikan mengurangi latensi yang dirasakan User. User tak bosan menunggu dengan halaman putih alias kosong.

Pada kasus facebook, yang kaya akan pelbagai jenis konten yg dimuat dalam satu halaman butuh suatu rancangan baru bagaimana memuat suatu halaman dengan lebih efisien. Halaman Utama (Home) facebook saja memiliki data yang berbeda-beda: friend list, new feeds, ads, and so on. Jika kita implementasikan kasus ini pada konsep tradisional, akan memakan waktu lama dalam memformulasikan data-data tersebut, query kesana-sini sebelum akhirnya bermuara dalam bentuk final document yg dimuat pada browser client. Belum lagi bila si controller gagal mengenerate data (Bagi yg tahu konsep MVC, pasti paham hal ini), bisa-bisa stuck ditengah-tengah yang (mungkin) pada akhirnya kita memanfaatkan try-catch . Artinya, sukses tidaknya suatu query, bertanggung jawab pada proses selanjutnya. Tapi itu tadi, point utama: “The browser is idle and wasting its cycles doing nothing… “.

 

How BigPipe works

Fokus utama BigPipe adalah memparalelkan kerja WebServer’s Generation Time dan ClientBrowser’s Rendering Time. Langkah pertama BigPipe akan memecah-mecah halaman menjadi bagian-bagian kecil yg dinamakan Pagelets. Dalam hal ini BigPipe memanfaatkan fitur tag HTML ‘<div>’. Konsep ini diadaptasi dari konsep Pipelining Microprocessor yg membagi-bagi tugas menjadi bagian-bagian kecil atau Stages (seperti “instruction fetch”, “instruction decode”, “execution”, “register write back” etc.), BigPipe melakukan hal ini dengan proses berikut:

1. Request Parsing: WebServer membaca dan memvalidasi kelayakan atau keabsahan suatu HTTP Request (parse and sanity check)
2. Data Fetching: WebServer mengambil data dari Storage Tier
3. Markup Generation: Web Server merumuskan HTML sebagai response yg akan dikirimkan ke Web Browser (client)
4. Network Transport: Response yang telah diformulasikan dalam bentuk HTML tadi, dikirimkan ke Web Browser Client.
5. CSS Downloading: Web Browser mengunduh CSS yg didefinisikan pada HTML response tadi.
6. DOM tree construction and CSS styling: Browser menyusun kerangka DOM tree yaitu berupa HTML dan memolesnya dengan CSS.
7. JavaScript Downloading: Web Browser mengunduh JavaScript yg didefinisikan pada HTML page.
8. JavaScript execution: Web Browser mengeksekusi JavaScript

Tiga langkah pertama yang tertera di atas dieksekusi oleh WebServer, selebihnya dijalankan Web Browser. Tiap pagelet seharusnya melewati tahapan diatas secara sekuensial, namun dengan BigPipe tiap pagelet bisa dijalankan secara paralel.

 

Pagelets

 
Pada gambar diatas kita bisa melihat bagaimana halaman Home Facebook dibagi-bagi menjadi beberapa pagelet: “composer pagelet”, “navigation pagelet”, “news feed pagelet”, “request box pagelet”, “ads pagelet”, “friend suggestion box” and “connection box”, dan lain sebagainya. Masing-masing pagelet berkerja secara terpisah (independent – paralel). Berhasil tidak nya suatu pagelet dimuat tidak akan mengganggu kinerja pagelet yang lain. Jadi, saat Pagelet Navigasi telah berhasil dimuat pada web-browser client, bisa saja pagelet “News Feed” sedang dalam proses pemuatan.

Dalam BigPipe, life-cycle nya menjadi seperti ini: Browser mengirim HTTP Request ke WebServer. Setelah memeriksa ke-absahan request, WebServer langsung mengirimkan balasan ke Browser dalam bentuk kerangka HTML “yang belum tertutup”. Didalamnya masih diikutkan tag <head> dan bagian awal tag <body> . Dalam tag <head> disisipkan library BigPipe’s JavaScript, berupa pagelet(yg diceritakan tadi) yang akan merespon data yg kemudian akan datang dari WebServer. Dan kemudian dalam tag <body>, disusun kerangka berupa tag-tag <div> yang digunakan sebagai penampung hasil eksekusi pagelets. Contoh:

 

<div>
<div id=”left_column”>

<div id=”pagelet_navigation”></div>
</div>
<div id=”middle_column”>

<div id=”pagelet_composer”></div>
<div id=”pagelet_stream”></div>
</div>
<div id=”right_column”>
<div id=”pagelet_pymk”></div>
<div id=”pagelet_ads”></div>

<div id=”pagelet_connect”></div>
</div>
</div>


 
Tahap di atas bisa kita sebut tahap “Penyusunan Kerangka”. Begitu semua pagelet terbentuk, Browser Client akan mengeksekusi method-method yg didefinisikan dalam Javascript, semisal method big_pipe.onPageletArrive() dibawah ini:

 

big_pipe.onPageletArrive({id: “pagelet_composer”, content=, css=[..], js=[..], …})

 
Yang terjadi saat method “onPageletArrive” dieksekusi adalah browser mulai mendowload semua css yg didefinisikan dalam method, kemudian menempatkannya sesuai definisi pagelets yg ada dalam method (dalam hal ini: “pagelet_composer” ). Multiple CSS’ pagelets dapat didownload secara paralel dan ditampilkan segera ditampilkan sesaat CSS selesai didownload. Kemudian, dimethod itu juga didefinisikan javascript. Dalam BigPipe, eksekusi JS lebih rendah prioritasnya dari pada CSS. Jadi inner JS dalam suatu pagelet tidak akan dieksekusi sebelum CSS pagelet tersebut selesai didownload. Sama halnya dengan CSS dalam tiap pagelet, sesaat setelah JS suatu pagelet selesai didownload, JS boleh dieksekusi tanpa harus menunggu pagelet yg lain yg masih sibuk mendownload JS nya masing-masing.

HASIL AKHIR nya, tiap pagelets dapat bekerja secara paralel tanpa harus menunggu proses lain selesai berkerja. Di pandangan USER seolah-olah halaman HOME-nya dimuat secara bertahap, padahal tidak. Untuk merasakan perbedaannya, silakan buka halaman utama facebook Anda dengan membandingkan link berikut: Traditional Model dan BigPipe. Perbedaannya akan tampak lebih signifikan jika Anda menggunakan Browser versi jadul, kecepatan internet Anda lemot, dan kemampuan Caching browser Anda tidak bersahabat.

 

At Facebook, we encourage thinking outside the box. We are constantly innovating on new technologies to make our site faster ~ Changhao Jiang

 
Changhao Jiang is a Research Scientist at Facebook who enjoys making the site faster in innovative ways.

taken from FB Engineering Note

***

“Apa sebenarnya EJB??? EJB merupakan suatu teknik pengembangan aplikasi berbasis komponen (Component-based development). Dalam EJB, kita memilah-milah program blblbala…. $#@$#@!##…. $%%#$%@#@…. blablablblablabla….”

“ADUHHHH…. ENTE NGOMONG APAAN SEH!!!????”

 

 

 
Tapi itulah, karena alasan “FOR THE BETTER FUTURE” ane harus bertanggung jawab juga ama masa depan ane…
*cielele-bahasaku-itulah..

 
Inti cerita sebenarnya biar nanti saya ga kerepotan lagi masalah konfigurasi-konfigurasi seperti yang baru saya alami saat BAKING CAKE pertama kedua ketiga kalinya by using CakePHP. Bukan berarti saya hanya akan membahas CakePhp aja… yg lainnya juga kok… Kayak JAVA ama Design Pattern.. pokoknya koding-kodingan lah…

 
OK lah mamen… sering-sering mampir ya… !!! Oiya, lapak ane yang ini dikunjungi juga ya… http://hatasipasingot.wordpress.com/