CPU, GPU, Memori, dan arsitektur multiproses
Dalam seri blog yang terdiri dari 4 bagian ini, kita akan mempelajari browser Chrome mulai dari arsitektur tingkat tinggi hingga spesifikasi dari pipeline rendering. Jika Anda pernah bertanya-tanya bagaimana browser mengubah kode Anda menjadi situs web yang berfungsi, atau Anda tidak yakin mengapa teknik tertentu disarankan untuk kinerja peningkatan, rangkaian ini tepat untuk Anda.
Sebagai bagian 1 dari seri ini, kita akan melihat terminologi komputasi inti dan fitur arsitektur multiproses.
Inti dari komputer ini adalah CPU dan GPU
Untuk memahami lingkungan di mana {i>browser<i} berjalan, kita perlu memahami beberapa suku cadang komputer dan apa yang mereka lakukan.
CPU
Pertama adalah Pentral Proase Unit - atau CPU. CPU dapat dianggap sebagai otak komputer. Inti CPU, yang digambarkan di sini sebagai pekerja kantor, dapat menangani banyak tugas berbeda satu per satu begitu masuk. Gemini dapat menangani semuanya mulai dari matematika hingga seni sambil mengetahui cara membalasnya melakukan panggilan ke pelanggan. Dulu, sebagian besar CPU hanya menggunakan satu {i>chip<i}. {i>Core<i} ibarat CPU lain yang ada di dalam {i>chip<i} yang sama. Dalam hardware modern, Anda sering kali mendapatkan lebih dari satu inti, sehingga memberikan daya komputasi yang lebih besar ponsel dan laptop Anda.
GPU
Graphics Prosesi Unit - atau GPU adalah bagian lain dari komputer. Tidak seperti CPU, GPU bagus dalam menangani tugas-tugas sederhana tetapi di beberapa core di saat yang sama. Sebagai nama pertama kali dikembangkan untuk menangani grafik. Inilah sebabnya mengapa dalam konteks grafis "menggunakan GPU" atau "didukung GPU" terkait dengan rendering cepat dan interaksi yang lancar. Dalam beberapa tahun terakhir, dengan komputasi yang dipercepat oleh GPU, semakin banyak pula GPU saja.
Saat Anda memulai aplikasi di komputer atau ponsel, CPU dan GPU adalah yang menjalankan aplikasi. Biasanya, aplikasi berjalan pada CPU dan GPU menggunakan mekanisme yang disediakan oleh Sistem Operasi.
Menjalankan program pada Proses dan Thread
Konsep lain yang perlu dipahami sebelum masuk ke dalam arsitektur {i>browser<i} adalah {i>Process<i} dan {i>Thread<i}. Proses dapat digambarkan sebagai program yang mengeksekusi aplikasi. Thread yang ada di dalam proses dan mengeksekusi setiap bagian dari program prosesnya.
Saat Anda memulai aplikasi, sebuah proses akan dibuat. Program mungkin membuat thread untuk membantu dapat melakukan pekerjaan, tapi itu opsional. Sistem Operasi memberi proses "slab" memori untuk bekerja dengan dan semua status aplikasi disimpan di ruang memori pribadi tersebut. Saat Anda menutup aplikasi, proses juga hilang dan Sistem Operasi mengosongkan memori.
Sebuah proses dapat meminta Sistem Operasi untuk memulai proses lain untuk menjalankan tugas yang berbeda. Jika terjadi, bagian memori yang berbeda dialokasikan untuk proses baru. Jika dua proses perlu berbicara, mereka dapat melakukannya dengan menggunakan Interinterisasi Peduli Komunikasi (IPC). Banyak aplikasi dirancang untuk bekerja seperti ini sehingga jika proses pekerja tidak responsif, proses tersebut bisa dimulai ulang tanpa menghentikan proses lain yang menjalankan bagian aplikasi yang berbeda.
Arsitektur browser
Jadi bagaimana sebuah {i>browser<i} web dibuat menggunakan proses dan utas? Yah, itu bisa menjadi satu proses dengan banyak utas yang berbeda atau banyak proses yang berbeda dengan beberapa utas yang berkomunikasi melalui IPC.
Hal penting yang perlu diperhatikan di sini adalah bahwa arsitektur yang berbeda ini merupakan detail implementasi. Tidak ada spesifikasi standar tentang bagaimana seseorang dapat membangun {i>browser<i} web. Pendekatan satu browser mungkin benar-benar berbeda dari yang lain.
Untuk seri blog ini, kami menggunakan arsitektur terbaru Chrome, yang dijelaskan dalam Gambar 8.
Di bagian atas adalah proses browser yang berkoordinasi dengan proses lain yang menangani berbagai bagian-bagian dari aplikasi. Untuk proses perender, beberapa proses dibuat dan ditugaskan ke setiap tab. Hingga baru-baru ini, Chrome memberikan proses pada setiap tab jika memungkinkan; sekarang model ini mencoba memberi prosesnya sendiri untuk setiap situs, termasuk iframe (lihat Isolasi Situs).
Proses mana yang mengontrol hal apa?
Tabel berikut menjelaskan setiap proses Chrome dan hal-hal yang dikontrolnya:
| Proses dan Yang dikontrol | |
|---|---|
| Browser |
Mengontrol "chrome" bagian dari aplikasi termasuk kolom URL, bookmark, back dan
tombol maju. Juga menangani bagian tak terlihat dan istimewa dari browser web seperti permintaan jaringan dan akses file. |
| Perender | Mengontrol apa pun di dalam tab tempat situs ditampilkan. |
| {i>Plugin<i} | Mengontrol plugin yang digunakan oleh situs web, misalnya, flash. |
| GPU | Menangani tugas GPU secara terpisah dari proses lainnya. Data ini dibagi menjadi proses yang berbeda karena GPU menangani permintaan dari beberapa aplikasi dan menggambarnya di platform yang sama. |
Bahkan ada lebih banyak proses seperti proses Ekstensi dan proses utilitas. Jika Anda ingin melihat berapa banyak proses yang sedang berjalan di Chrome Anda, klik ikon menu opsi di sudut kanan atas, pilih Alat Lainnya, lalu pilih {i>Task Manager<i}. Ini akan membuka jendela dengan daftar proses yang sedang berjalan dan berapa banyak CPU/Memori yang mereka gunakan.
Manfaat arsitektur multiproses di Chrome
Sebelumnya, saya menyebutkan bahwa Chrome menggunakan beberapa proses perender. Dalam kasus yang paling sederhana, Anda bisa bayangkan setiap tab memiliki proses {i>render<i} sendiri. Misalnya Anda membuka 3 tab dan setiap tab dijalankan oleh proses perender independen.
Jika satu tab menjadi tidak responsif, maka Anda dapat menutup tab yang tidak responsif dan melanjutkan dengan tetap tab lain. Jika semua tab berjalan pada satu proses, saat satu tab menjadi tidak responsif, semua tab tidak merespons. Sayang sekali.
Manfaat lain dari memisahkan pekerjaan {i>browser<i} menjadi beberapa proses adalah keamanan dan penggunaan sandbox{i> <i}yang sederhana. Karena sistem operasi menyediakan cara untuk membatasi proses izin akses, browser dapat menjalankan {i>sandbox<i} proses tertentu dari fitur tertentu. Misalnya, {i>browser<i} Chrome membatasi akses file arbitrer untuk proses yang menangani input pengguna arbitrer seperti proses perender.
Karena proses memiliki ruang memori sendiri, mereka sering kali berisi salinan infrastruktur Anda (seperti V8 yang merupakan mesin JavaScript Chrome). Ini berarti lebih banyak penggunaan memori sebagai mereka tidak dapat dibagikan seperti jika mereka adalah {i>thread<i} di dalam proses yang sama. Untuk menghemat memori, Chrome membatasi jumlah proses yang dapat dijalankan. Batasnya bervariasi, bergantung pada seberapa banyak memori dan daya CPU yang dimiliki perangkat Anda, tetapi saat Chrome mencapai batasnya, {i>router<i} mulai menjalankan beberapa tab dari situs yang sama dalam satu proses.
Menghemat lebih banyak memori - Layanan di Chrome
Pendekatan yang sama diterapkan pada proses browser. Chrome sedang mengalami perubahan arsitektur untuk menjalankan setiap bagian program {i>browser<i} sebagai layanan yang memungkinkan untuk membaginya menjadi beberapa proses atau digabungkan menjadi satu.
Ide umumnya adalah saat berjalan di perangkat keras yang kuat, Chrome mungkin membagi setiap layanan menjadi proses yang berbeda memberikan stabilitas lebih, tetapi jika berada di perangkat dengan batasan sumber daya, Chrome mengonsolidasikan layanan ke dalam satu proses yang menghemat jejak memori. Pendekatan serupa terkait penggabungan proses untuk penggunaan memori yang lebih sedikit telah digunakan pada platform seperti Android sebelum perubahan ini.
Proses perender per frame - Isolasi Situs
Isolasi Situs baru-baru ini merupakan memperkenalkan fitur di Chrome yang menjalankan proses perender terpisah untuk setiap iframe lintas situs. Kita telah membahas tentang satu proses perender per model tab yang memungkinkan iframe untuk dijalankan dalam proses perender tunggal dengan berbagi ruang memori di antara situs yang berbeda. Menjalankan a.com dan b.com dalam proses perender yang sama mungkin tampak tidak masalah. Kebijakan Asal yang Sama adalah model keamanan inti dari web; memastikan satu situs tidak dapat mengakses data dari situs lain tanpa persetujuan. Kebijakan ini merupakan tujuan utama serangan keamanan. Isolasi proses adalah cara paling efektif untuk memisahkan situs. Dengan Meltdown dan Spectre, semakin jelas bahwa kita perlu memisahkan situs menggunakan proses. Dengan Isolasi Situs yang diaktifkan di desktop secara default sejak Chrome 67, setiap iframe lintas situs dalam tab akan mendapatkan proses perender yang terpisah.
Mengaktifkan Isolasi Situs telah menjadi upaya engineering selama beberapa tahun. Isolasi Situs tidaklah sesederhana menetapkan proses perender yang berbeda; pada dasarnya cara iframe berkomunikasi lainnya. Membuka devtools di halaman dengan iframe yang berjalan di proses yang berbeda membuat devtools harus menerapkan pekerjaan di balik layar agar terlihat mulus. Bahkan menjalankan Ctrl+F sederhana untuk menemukan kata di laman berarti mencari di berbagai proses perender yang berbeda. Anda dapat mengetahui alasannya insinyur browser berbicara tentang rilis Isolasi Situs sebagai sebuah tonggak sejarah utama!
Penutup
Dalam postingan ini, kita telah membahas tampilan tingkat tinggi dari arsitektur browser dan membahas manfaat arsitektur multiproses. Kita juga telah membahas Layanan dan Isolasi Situs di Chrome yang sangat terkait dengan arsitektur multiproses. Di postingan berikutnya, kita akan mulai membahas apa yang yang terjadi di antara proses dan utas ini untuk menampilkan sebuah {i>website<i}.
Apakah Anda menyukai postingan ini? Jika Anda memiliki pertanyaan atau saran untuk postingan mendatang, kami ingin saya mendengar kabar dari Anda di @kosamari di Twitter.