Penulis bahan, terjemahan yang kami terbitkan hari ini, mengatakan bahwa ia, pada pertengahan September 2019, akhirnya menyelesaikan proyek yang telah ia kerjakan selama setahun. Tujuan dari proyek ini adalah untuk mengurangi ukuran manifes yang diperlukan untuk menginisialisasi pipa JavaScript asinkron Wikipedia. Yaitu, ukuran manifes adalah 36 Kb. Itu harus masuk dalam kurang dari 28 Kb, yang sesuai dengan dua fragmen 14 kilobyte dari urutan paket Internet.
Hasil dari proyek ini adalah penghematan lalu lintas harian sebesar 4,3 terabyte.
Pada awalnya, ukuran manifes melebihi 36 Kb, dan setelah optimasi, ukurannya menjadi lebih kecil dari 28 KbGrafik menunjukkan penurunan bertahap dalam ukuran manifes. Kita berbicara tentang data terkompresi (yaitu, itu adalah beban bersih di jaringan, yang membuat transfer data ini dari server ke browser).
Proses optimasi
Manifes inisialisasi diwakili oleh data yang tidak mudah dioptimalkan. Sebagian besar kodenya bukanlah sesuatu seperti logika fungsional yang dapat dioptimalkan dengan cara tradisional. Sebaliknya, hampir seluruh manifes diwakili oleh data murni. Data ini secara otomatis dihasilkan oleh sistem pengiriman konten
ResourceLoader . Mereka adalah kumpulan dari kumpulan modul. Wikipedia menggunakan sistem ResourceLoader untuk bekerja dengan JavaScript, CSS, dan sumber daya teks.
Registri mencakup metadata untuk semua fungsi front-end yang digunakan di Wikipedia. Manifes mencantumkan nama bundel, versi mereka saat ini, dependensinya pada bundel serupa dijelaskan di sini.
Saya mulai dengan mencari kode yang tidak pernah digunakan dalam praktik (
T202154 ). Ini termasuk menemukan potongan kode yang tidak lengkap atau terlupakan terkait dengan fitur lawas. Kode yang tidak digunakan segera dihapus untuk memastikan kompatibilitas dengan browser yang tidak lagi lulus pengujian kami, yang memastikan dimasukkannya mereka dalam grup browser modern (
Kelas A ). Saya juga menyiapkan
dokumen tentang kinerja pemuatan halaman. Dokumen ini berfungsi sebagai referensi, yang memungkinkan pengembang untuk memahami dampak perubahan berbagai jenis pada berbagai tahap proses pemuatan halaman.
Kurangi jumlah modul
Langkah selanjutnya adalah berkolaborasi dengan tim teknik Wikimedia Foundation dan Wikimedia Deutschland. Kami perlu mencari tahu fitur apa dari sistem yang menggunakan banyak modul. Misalnya, setelah memahami ini, akan mungkin untuk menggabungkan bundel yang sebelumnya tersebar dari mana fungsi tertentu dibangun. Bundel seperti itu, bahkan dalam keadaan tersebar, selalu dimuat bersama. Ini akan mengarah pada fakta bahwa akan ada lebih sedikit titik akhir dalam sistem yang metadata-nya harus disimpan dalam registri yang dibentuk oleh ResourceLoader.
Berikut adalah beberapa hal menarik tentang penerapan pendekatan optimasi ini:
- Ekstensi WikiEditor sekarang memiliki 11 modul lebih sedikit dari sebelumnya. 31 modul lainnya telah dihapus dari UploadWizard.
- Saat mengoptimalkan program ContentTranslation, 24 modul digabungkan.
- Proyek MobileFrontend menggabungkan 25 modul.
- 20 modul dihapus dari RevisionSlider dan TwoColConflict.
Juga sangat penting bahwa klien Wikidata untuk Wikipedia telah dioptimalkan. Bagian dari pekerjaan itu sendiri adalah proyek epik (
T203696 ). Awalnya, 248 modul individu bertanggung jawab untuk mengimplementasikan fitur ini. Setelah kami berhasil menyingkirkan lebih dari 200 modul, hanya ada 42 modul.
Diagram di atas menunjukkan perbaikan kecil yang dibuat untuk proyek selama setahun. Mereka semua membawa kami lebih dekat ke tujuan. Saya terutama ingin mencatat dua tetes besar dalam ukuran manifes. Satu kejatuhan seperti itu terjadi pada minggu pertama Agustus. Saat itulah versi Wikidata yang lebih baik digunakan. Penurunan ukuran kedua dapat diamati di bagian paling akhir grafik. Itu terjadi pada pertengahan September. Sekarang saya ingin memberi tahu Anda tentang dia.
Kurangi ukuran metadata
Peningkatan manifesto yang terjadi pada pertengahan September dimungkinkan oleh dua perubahan global yang ditujukan untuk organisasi data yang lebih cerdas.
Peningkatan pertama adalah bahwa, sebelumnya, metadata skema ekstensi
EventLogging adalah bagian dari manifes utama. Mekanisme ini di-refactored, sehingga skema metadata sekarang dimasukkan dalam bundel JS klien EventLogging. Akibatnya, kontribusi ke ukuran manifes yang dibuat sebelumnya oleh EventLogging telah berkurang lebih dari 90%. Ini berarti bahwa jalur kritis sekarang mengandung data 2 KB lebih sedikit! Ini, di samping itu, berarti memperluas kemampuan EventLogging tidak lagi menyebabkan peningkatan ukuran manifes. Saat merakit bundel seperti itu, fitur baru ResourceLoader,
Package Files, digunakan . Fitur ini diperkenalkan pada Februari 2019, salah satu alasan yang menarik di dalamnya adalah kenyataan bahwa itu dapat membantu mengurangi jumlah modul dalam registri. File Paket sangat menyederhanakan proses menggabungkan data yang dihasilkan dan kode JavaScript dalam satu modul.
Peningkatan kedua terjadi ketika kami mengurangi ukuran rata-rata setiap entri registri (
T229245 ). Manifes berisi dua entri untuk setiap modul. Ini adalah nama modul dan pengenal (ID) versinya. Pengenal versi sebelumnya membutuhkan 7 byte data. Setelah memikirkan
paradoks ulang tahun dalam konteks ResourceLoader, kami memutuskan bahwa spektrum probabilitas untuk ID versi dapat dengan aman dikurangi dari 78 miliar menjadi "hanya" 60 juta. Rincian tentang ini dapat ditemukan di
komentar kode. Tetapi, untuk meringkas peningkatan ini, kita dapat mengatakan bahwa ini memungkinkan kita untuk menyimpan 2 byte dalam deskripsi masing-masing dari 1.100 modul yang masih ada dalam registri. Akibatnya, ukuran manifes berkurang sebanyak 2-3 Kb.
Di bawah ini adalah bagian diagram yang diperbesar yang menunjukkan beberapa hari terakhir operasi (indikator-indikator ini diambil dari sistem pemantauan sintetis, data tidak terkompresi digunakan di sini).
Mewujudkan ukuran pada tahap akhir proyekPerubahan itu ditangkap oleh sistem pemantauan ResourceLoader. Tangkapan layar memperlihatkan panel
ukuran manifes Startup yang terletak di instance publik Grafana. Di sini Anda dapat melihat bahwa ukuran aliran data terkompresi menurun sebesar 2,8 Kb.
Penerapan sistem, yang berlangsung pada pertengahan September, mengarah pada pencapaian tujuan awal, yaitu untuk mengkompres manifes ke ukuran tidak melebihi 28 Kb. Implementasi proyek skala besar ini mengarah pada fakta bahwa manifes inisialisasi berkurang sebesar 9 Kb (kita berbicara tentang data terkompresi). Setahun yang lalu, ukuran ini adalah 36,2 Kb, dan setelah penyelesaian proyek itu sudah 27,2 Kb.
Sekitar 363.000 tampilan halaman dihasilkan setiap menit di Wikipedia dan proyek terkait. Dalam satu jam - 21 juta dan 800 ribu. Harian - 523 juta (
ini adalah statistik pada tampilan halaman). Versi sistem itu, yang digunakan pada pertengahan September, menghasilkan penghematan sekitar 1,4 terabyte traffic per hari. Dan jika Anda membandingkan hari ini dengan tahun lalu, ternyata lalu lintas 4,3 terabyte kini disimpan setiap hari.
Apa selanjutnya
Kami berhasil mencocokkan manifes inisialisasi Wikipedia 28 Kb. Ini adalah ukuran yang dipilih karena fakta bahwa itu adalah ukuran terkecil yang merupakan kelipatan dari 14 Kb. Data ukuran ini dapat ditempatkan dalam fragmen
urutan paket Internet yang dikirimkan ke browser.
Sekarang kita menghadapi tugas baru: jangan menyerah posisi. Pada tahun lalu, saya mengamati dengan dekat
manifesto itu . Saya melakukan ini untuk memastikan keberhasilan kami dan untuk menemukan masalah potensial yang menarik kami kembali. Pada akhirnya, saya mengotomatiskan proses ini menggunakan
dasbor Grafana publik.
Jika Anda percaya panel ini, maka kami masih memiliki banyak peluang untuk meningkatkan pengemasan kode, dan untuk memecahkan masalah yang bahkan lebih kuat dari sekarang, memfasilitasi pembuatan bundel. Saya berharap perbaikan mendatang ini akan bermanfaat bagi kami, tetapi untuk saat ini kami sedang mengerjakan kemampuan sistem baru, sambil berusaha untuk memenuhi persyaratan untuk tingkat kinerja proyek.
Pembaca yang budiman! Apakah Anda pernah ikut serta dalam optimalisasi proyek Internet besar?
