Melihat Tumpukan Server WordPress Modern

Apakah Anda ingat ketika Anda dapat menjalankan situs web WordPress "cepat" hanya dengan server Apache dan PHP? Ya, itu adalah hari-hari! Hal-hal yang jauh lebih rumit saat itu.

Sekarang, semuanya harus dimuat secepat kilat! Pengunjung tidak memiliki harapan yang sama tentang waktu pemuatan seperti dulu. Situs web yang lambat dapat memiliki implikasi serius bagi Anda atau klien Anda.

Bacaan Lebih Lanjut tentang SmashingMag:

• Izin Dan Kepemilikan Sistem File WordPress yang Tepat
• Memindahkan Situs WordPress Tanpa Kerumitan
• Cara Mengembangkan WordPress Secara Lokal Dengan MAMP
• Metode Caching Do-It-Yourself Dengan WordPress

Akibatnya, tumpukan server WordPress harus berevolusi selama bertahun-tahun untuk memenuhi kebutuhan akan kecepatan ini. Sebagai bagian dari evolusi ini, beberapa roda gigi harus ditambahkan ke mesinnya. Beberapa gigi yang lebih tua harus berubah juga.

Hasilnya adalah tumpukan server WordPress terlihat sangat berbeda hari ini daripada beberapa tahun yang lalu. Untuk lebih memahaminya, kita akan menjelajahi tumpukan baru ini secara mendetail. Anda akan melihat bagaimana berbagai bagian cocok bersama untuk membuat situs web WordPress dengan cepat.

Ringkasan

Sebelum menyelam, mari kita perkecil dan lihat gambaran besarnya. Seperti apa tumpukan server WordPress baru ini? Nah, inilah jawabannya:

Diagram di atas memberikan gambaran yang baik tentang seperti apa tumpukan server WordPress modern. Pada tingkat tinggi, kita dapat membagi apa yang terjadi menjadi tiga bidang:

• siklus permintaan-tanggapan antara browser dan WordPress;
• WordPress (yang merupakan skrip yang dijalankan oleh runtime PHP);
• siklus hasil kueri antara WordPress dan database MySQL.

Peran tumpukan server WordPress modern adalah untuk mengoptimalkan ketiga area ini. Pengoptimalan inilah yang membuat semuanya dimuat lebih cepat. Dan bagian terbaiknya adalah ada beberapa cara untuk melakukannya. (Ya!)

Dalam kebanyakan kasus, pengoptimalan ini melibatkan pemasangan layanan baru di server Anda. Terkadang, layanan ini membutuhkan bantuan plugin untuk berinteraksi dengan WordPress. Juga akan ada saat-saat ketika Anda bisa lolos hanya dengan menginstal plugin. Anda akan melihat banyak opsi berbeda di seluruh artikel ini.

Siklus Permintaan-Respons

Semuanya dimulai dengan browser. Katakanlah Anda ingin melihat halaman beranda modern.wordpress-stack.org . Browser Anda akan mulai dengan mengirimkan permintaan HTTP ke server web yang menghostingnya. Di ujung lain, server web akan menerima permintaan Anda dan mengubahnya menjadi respons HTTP.

Respons pertama ini harus selalu berupa konten HTML halaman beranda modern.wordpress-stack.org (kecuali jika ada kesalahan). Namun, pekerjaan browser Anda belum selesai. Tidak, halaman beranda itu masih membutuhkan lebih banyak file, yang paling umum adalah file CSS, JavaScript, dan gambar.

Jadi, browser akan mengirimkan permintaan untuk file-file tersebut. Server web akan merespons dengan file yang diminta (sekali lagi, selama tidak ada kesalahan). Siklus ini akan berlanjut hingga browser memiliki informasi yang cukup untuk merender halaman beranda. Semakin cepat siklus ini terjadi, semakin cepat situs web akan muncul untuk memuat.

Sekarang, ini adalah penyederhanaan yang jelas, tetapi begitulah cara kerja sebagian besar situs web WordPress.

Mengoptimalkan Siklus Permintaan-Respon

Baiklah, ini membawa kita ke pertanyaan yang jelas, Bagaimana kita membuat server web melakukan siklus ini lebih cepat? Ini adalah pertanyaan yang bagus dan merupakan bagian dari alasan mengapa tumpukan server WordPress modern ada.

Tumpukan ada karena Anda tidak bisa hanya membuat server web lebih cepat. Server web juga merupakan operator. Itu dapat menerima permintaan dan hanya meneruskannya ke layanan lain.

Layanan lain ini sering menjadi penghambat siklus permintaan-tanggapan ini. Dengan WordPress, hambatan ini adalah PHP, itulah sebabnya mengoptimalkan siklus permintaan-tanggapan bermuara pada dua hal. Kami ingin server web untuk:

• menerima permintaan sesedikit mungkin,
• meneruskan permintaan sesedikit mungkin ke PHP.

Tumpukan server WordPress modern berfokus pada yang terakhir ini. Ia ingin meneruskan sesedikit mungkin permintaan ke PHP. Itu akan menjadi tujuan utama untuk mengoptimalkan tumpukan.

Kami fokus pada tujuan kedua karena tumpukan tidak bisa berbuat banyak tentang yang pertama; itu tidak memiliki dampak langsung padanya. Yang kedua ditangani baik oleh konfigurasi server web atau dengan teknik pengembangan modern.

Elemen Tumpukan Untuk Siklus Permintaan-Respons

Jadi, elemen tumpukan apa yang akan membantu kami mengurangi permintaan yang diteruskan ke PHP? Nah, dua elemen tumpukan secara khusus akan membantu kita mencapai tujuan itu: server web dan cache HTTP.

Server Web

Kami telah berbicara sedikit tentang server web. Ada tiga pemain besar di ruang server web:

• Apache
• Layanan Informasi Internet (IIS)
• nginx

Bersama-sama, ini membuat lebih dari 90% pangsa pasar server web di Internet. Kita akan fokus pada Apache dan nginx. Meskipun IIS dapat digunakan untuk menjalankan WordPress, ini tidak umum karena hanya tersedia untuk Windows, dan sebagian besar server WordPress menggunakan Linux.

Ini meninggalkan kita dengan Apache dan nginx. Untuk semua kehidupan WordPress, Apache telah menjadi server web yang direkomendasikan. Kami memiliki tumpukan LAMP (Linux, Apache, MySQL dan PHP), yang menjalankan WordPress di komputer dan server.

Namun di balik layar, segalanya berubah. Ada pemain baru di kota, dan namanya nginx. Automattic dan WordPress.com telah menggunakannya sejak 2008. Ini adalah server web yang menjalankan persentase terbesar dari situs web dengan lalu lintas tinggi (banyak yang menjalankan WordPress). Itu sebabnya banyak perusahaan hosting kelas atas dan agensi WordPress teratas menggunakannya sebagai server web mereka.

Bukannya Apache adalah server web yang buruk. Ada pakar Apache yang dapat membuatnya berjalan dengan baik di bawah banyak lalu lintas. Itu tidak bekerja dengan baik di luar kotak atau dengan konfigurasi WordPress standar.

Sementara itu, satu-satunya tujuan nginx adalah menangani banyak lalu lintas. Itu sebabnya Igor Sysoev memulai proyek ini ketika dia bekerja di Rambler.

Salah satu alasan mengapa nginx menangani lebih banyak lalu lintas dengan lebih baik adalah karena ia menggunakan FastCGI untuk berkomunikasi dengan PHP. Apa itu FastCGI? Ini adalah protokol yang memungkinkan PHP berjalan sebagai layanan yang terpisah dari server web.

Apache tidak melakukan ini secara default. Setiap kali server web menerima permintaan, ia perlu memulai proses runtime PHP — bahkan untuk gambar, JavaScript, dan CSS. Ini mengurangi jumlah permintaan yang dapat ditangani server dan seberapa cepat server dapat menanganinya.

Ini bertentangan dengan salah satu tujuan tumpukan server WordPress modern, yang telah kita lihat sebelumnya. Tumpukan perlu menjaga waktu siklus permintaan-tanggapan serendah mungkin. Memuat PHP untuk setiap permintaan, bahkan ketika tidak membutuhkannya, bertentangan dengan tujuan ini. Jadi, jika Anda menggunakan Apache, lihat FastCGI.

HTTP/2 adalah fitur server web penting lainnya yang harus Anda ketahui. Ini adalah versi HTTP berikutnya, protokol yang menggerakkan seluruh siklus permintaan-tanggapan kami.

Sebelum kedatangan HTTP/2, browser hanya dapat memiliki enam koneksi ke server web. Dan setiap koneksi hanya dapat menangani satu permintaan pada satu waktu. Jadi, dalam praktiknya, siklus permintaan-tanggapan dibatasi pada enam permintaan per siklus.

Itu masalah nyata. Sebagian besar situs web memiliki lusinan permintaan dalam siklusnya. Pengembang dan administrator sistem menemukan cara cerdas untuk mengatasi batasan ini.

Salah satu solusi yang lebih terkenal adalah praktik menggabungkan file CSS dan JavaScript. Dalam skenario yang ideal, ini akan menurunkan jumlah total permintaan untuk file CSS dan JavaScript menjadi dua: satu untuk JavaScript dan satu untuk CSS.

Ini tidak diperlukan dengan HTTP/2. HTTP/2 memungkinkan jumlah permintaan yang tidak terbatas per koneksi. Ini memungkinkan semua permintaan tambahan setelah respons HTML awal terjadi pada waktu yang sama.

Ini memiliki implikasi kinerja yang besar. Banyak pekerjaan mengoptimalkan tumpukan server berpusat pada siklus permintaan-tanggapan. Dengan mengurangi jumlah siklus menjadi hanya segelintir, HTTP/2 telah melakukan banyak pekerjaan bagi kami.

Tembolok HTTP

Bagian terpenting dari tumpukan server WordPress modern adalah cache HTTP. Di dunia WordPress, kami juga menyebut halaman ini sebagai caching. Tujuan dari cache HTTP adalah untuk men-cache respons terhadap permintaan. Apa artinya ini?

Nah, mari kita kembali ke contoh kita sebelumnya. Browser mengirimkan permintaan untuk halaman beranda modern.wordpress-stack.org , dan server web menerima permintaan itu dan meneruskannya ke PHP.

Masalah dengan skenario ini adalah server webnya bodoh. Itu akan selalu meneruskan semua permintaan yang diterimanya ke PHP — terlepas dari apakah sebagian besar permintaan akan menghasilkan respons yang sama.

Inilah yang terjadi ketika pengunjung tidak masuk. Untuk server web, mereka semua permintaan yang berbeda, tetapi tidak peduli. Ini akan meneruskan semuanya ke PHP, yang akan menghasilkan respons yang sama untuk semuanya.

Itu buruk! Seperti yang kita lihat sebelumnya, PHP adalah hambatan sebenarnya dari siklus permintaan-respons kami. Peramban Anda tidak dapat mengirim permintaan tindak lanjut hingga menerima respons beranda awal itu. Kami tidak dapat meminta server web meneruskan semuanya ke PHP secara default.

Di situlah cache HTTP masuk. Itu berada di antara server web dan PHP. Tugasnya adalah memeriksa setiap permintaan yang diterima server web dan mencari respons yang di-cache. Jika tidak ada, permintaan akan diteruskan ke PHP dan kemudian cache respons yang dihasilkan PHP.

Ini secara drastis mengurangi waktu siklus permintaan-tanggapan, membuat situs web memuat lebih cepat. Ini juga memungkinkan server web menangani lebih banyak permintaan simultan tanpa meledak.

Berbagai Rasa Cache HTTP

Pada titik ini, Anda harus bertanya-tanya, “Bagaimana saya bisa mendapatkan bayi ini di server saya ASAP?!” Kabar baiknya adalah menginstal cache HTTP di server WordPress cukup mudah. Ini adalah komponen dengan rentang pilihan terluas.

Instal Plugin Caching Halaman

Cara termudah adalah menginstal plugin cache halaman. Anda memiliki beberapa opsi untuk dipilih:

• Batcache
• Hyper Cache
• Pengaktif Cache
• WP Roket
• WP Super Cache
• Cache Total W3

Semua kecuali WP Rocket tersedia sebagai plugin gratis di direktori WordPress. Jadi, Anda dapat menginstal satu dan mengujinya segera. Dari keempat plugin tersebut, yang terbaik adalah WP Rocket. Meskipun ini adalah plugin berbayar, ia melakukan lebih dari sekadar membuat cache HTTP. Manfaat lain ini memperbesar pekerjaan yang dilakukan cache HTTP.

Bagaimana Cara Kerja Plugin Caching Halaman?

Semua plugin ini memanfaatkan drop-in yang disediakan WordPress untuk caching. Drop-in caching ini memungkinkan plugin membuat sistem cache HTTP di dalam WordPress. Drop-in caching membutuhkan dua hal untuk bekerja.

Pertama, file drop-in advanced-cache.php harus berada di folder wp-content . Itu file yang sebenarnya. Tapi tidak seperti kebanyakan drop-in WordPress, yang satu ini tidak masuk secara default. WordPress juga membutuhkan konstanta WP_CACHE menjadi true untuk memuat drop-in. Dalam kebanyakan kasus, Anda akan mengaturnya di wp-config.php .

Diagram di atas menunjukkan apa yang terjadi ketika Anda mengaktifkan drop-in dengan plugin caching. WordPress memuat drop-in di wp-settings.php selama proses pemuatannya. Ini cukup awal dalam proses bahwa WordPress belum melakukan sesuatu yang memakan waktu.

Plugin caching kemudian akan memeriksa apakah sudah men-cache respons terhadap permintaan. Jika sudah, itu akan mengembalikan respons yang di-cache itu. Jika belum, itu akan mengaktifkan buffering output PHP, dan WordPress akan terus memuat.

Sekarang, buffering keluaran adalah sistem yang menarik. Apa yang dilakukannya adalah menangkap semua output dari skrip PHP dalam variabel string hingga salah satu dari dua hal terjadi:

• Anda memberi tahu PHP untuk menghentikan buffering outputnya menggunakan salah satu fungsi bawaan,
• skrip PHP selesai dan perlu mengembalikan respons ke browser.

Plugin caching mengandalkan skenario terakhir. Ia ingin WordPress melakukan tugasnya dan kemudian men-cache seluruh output sebelum PHP mengirimkannya kembali ke browser. Anda dapat melihat prosesnya pada diagram di bawah ini.

Minta Server Web Melakukannya

Opsi selanjutnya adalah menambahkan cache HTTP di tingkat server web. Cara kerjanya adalah server web akan men-cache semua tanggapan terhadap permintaan yang diteruskan ke PHP. Solusi ini lebih baik daripada plugin caching karena tidak perlu menyentuh PHP sama sekali.

Diagram di atas memberikan gambaran tentang apa yang terjadi di server web. Server web menerima permintaan dan memeriksa dengan cache HTTP. Jika respons telah di-cache, cache HTTP akan mengirimkannya kembali.

Jika tidak, permintaan akan diteruskan ke modul PHP (biasanya FastCGI). Ini akan meneruskan permintaan ke WordPress sehingga dapat menghasilkan respons. Modul cache HTTP kemudian akan men-cache respons itu dalam perjalanan kembali.

Baik Apache dan nginx hadir dengan kemampuan untuk menambahkan sistem cache HTTP. Yang nginx sudah ada di dalamnya. Yang Apache adalah modul terpisah yang perlu Anda tambahkan ke instalasi Apache Anda.

Tidak banyak informasi tentang cara menggunakan modul Apache dengan PHP atau WordPress. Itu mungkin karena tidak populer dengan kerumunan Apache, atau mungkin karena memiliki beberapa masalah. Setidaknya ada satu masalah lama yang masih terbuka.

Sementara itu, sistem cache HTTP nginx kuat dan didokumentasikan dengan baik. Anda dapat menggunakannya sebagai cache HTTP normal atau sebagai cache mikro yang lebih kecil namun efektif. Itu hanya satu alasan lagi mengapa nginx adalah server web pilihan saat ini.

Tambahkan Pernis ke Tumpukan

Apa itu Varnish? Ini adalah server cache HTTP khusus (atau, sebagaimana pengembangnya suka menyebutnya, akselerator HTTP). Sebagian besar situs web dengan lalu lintas tinggi dan perusahaan hosting premium menggunakannya sebagai solusi cache HTTP mereka.

Mereka menggunakannya karena kuat dan menawarkan fleksibilitas paling tinggi. Varnish memiliki bahasa konfigurasi sendiri, yang disebut VCL. Ini memungkinkan Anda mengontrol setiap elemen dari proses caching. Varnish juga dilengkapi dengan banyak alat untuk menganalisis apa yang dilakukan cache dan bagaimana kinerjanya.

Ini adalah perbedaan utama antara menggunakannya dan hanya menggunakan cache HTTP server web bawaan. Cache HTTP server web bawaan sangat berkinerja baik tetapi juga cukup mendasar. Anda tidak memiliki banyak kendali di luar beberapa opsi konfigurasi.

Namun demikian, kekuatan dan fleksibilitas ini ada harganya. Varnish juga merupakan opsi cache HTTP yang paling rumit. Itu tidak melakukan apa pun selain men-cache respons HTTP. Itu tidak menangani penghentian SSL, yang diinginkan sebagian besar pengembang WordPress (atau seharusnya diinginkan). Ini berarti bahwa tumpukan server WordPress modern kita akan menjadi lebih kompleks saat kita menggunakannya.

Diagram di atas menggambarkan kompleksitas ekstra ini. Kami sekarang memiliki dua komponen lagi di tumpukan server WordPress kami: Varnish dan proxy terbalik.

Proxy terbalik ada untuk mengatasi keterbatasan yang dimiliki Varnish dengan SSL. Itu duduk di depan Varnish dan mendekripsi permintaan yang diterima server kami. Anda juga dapat menyebut jenis proxy terbalik ini sebagai proxy penghentian SSL. Proxy kemudian mengirimkan permintaan yang didekripsi ini ke Varnish untuk diproses.

Setelah permintaan mengenai Varnish, file konfigurasi VCL masuk. Mereka adalah otak Varnish. Misalnya, mereka memberi tahu cara:

• menganalisis, membersihkan, dan memodifikasi permintaan yang masuk;
• cari respons yang di-cache;
• menganalisis, membersihkan, dan memodifikasi tanggapan balik dari WordPress;
• cache tanggapan yang kembali ini;
• menangani permintaan untuk menghapus satu atau lebih tanggapan dari cache.

Yang terakhir ini sangat penting. Dibiarkan sendiri, Varnish tidak memiliki cara untuk mengetahui kapan WordPress ingin menghapus halaman dari cache. Jadi, secara default, jika Anda membuat perubahan pada postingan dan memperbaruinya, pengunjung akan tetap melihat halaman cache yang sama. Beruntung bagi kami, ada plugin yang menghapus halaman dari cache Varnish.

WordPress

Baiklah, permintaan kami untuk halaman beranda modern.wordpress-stack.org telah mencapai WordPress. Itu melewati siklus permintaan-tanggapan yang baru saja kita bahas. Cache HTTP melakukan apa saja untuk menemukan respons HTTP untuk dikirim kembali.

Tetapi tidak ada respons HTTP yang di-cache untuk dikirim kembali ke browser. Pada saat itu, cache HTTP tidak punya pilihan lain. Itu harus meneruskan permintaan HTTP ke WordPress.

Semuanya ada di tangan WordPress sekarang. WordPress harus mengubah permintaan HTTP kami menjadi respons HTTP dan mengirimkannya kembali ke cache HTTP. Seperti yang kita lihat sebelumnya, ini adalah hambatan utama dari seluruh tumpukan server WordPress modern kami.

Penyebab kemacetan ini ada dua. WordPress memiliki banyak kode PHP untuk dieksekusi. Ini memakan waktu, dan semakin lambat PHP melakukannya, semakin lama waktu yang dibutuhkan.

Hambatan lainnya adalah kueri basis data yang perlu dilakukan WordPress. Kueri basis data adalah operasi yang mahal. Semakin banyak, semakin lambat WordPress. Ini akan menjadi fokus bagian terakhir pada siklus hasil kueri.

Mengoptimalkan Waktu Proses PHP

Mari kembali ke PHP. Saat ini, WordPress memiliki persyaratan minimum PHP 5.2. Versi PHP ini hampir 10 tahun! (Tim PHP berhenti mendukungnya pada tahun 2011.)

Tim PHP tidak tinggal diam selama bertahun-tahun. Banyak peningkatan kinerja telah dilakukan, terutama selama beberapa tahun terakhir. Mari kita lihat apa yang dapat Anda lakukan untuk mengoptimalkannya saat ini.

Gunakan Versi Terbaru PHP

Hal termudah yang dapat Anda lakukan adalah memutakhirkan versi PHP Anda. Versi 5.4, 5.5 dan 5.6 semuanya mengalami peningkatan kinerja. Peningkatan terbesar adalah dari 5,3 menjadi 5,4. Beralih ke sana meningkatkan kinerja WordPress dengan jumlah yang layak.

Instal Opcode Caching

Caching Opcode adalah cara lain untuk mempercepat PHP. Sebagai bahasa skrip sisi server, PHP memiliki kelemahan besar: PHP harus mengkompilasi skrip PHP setiap kali dijalankan.

Solusi untuk masalah ini adalah dengan men-cache kode PHP yang dikompilasi. Dengan begitu, PHP tidak perlu mengompilasinya setiap kali dijalankan. Ini adalah tugas dari cache opcode.

Sebelum PHP 5.5, PHP tidak dibundel dengan cache opcode. Anda harus menginstalnya sendiri di server. Ini adalah alasan lain mengapa menggunakan versi PHP yang lebih baru lebih baik.

Beralih ke Kompilator Generasi Berikutnya

Hal terakhir yang dapat Anda lakukan adalah beralih ke salah satu dari dua kompiler generasi berikutnya: HHVM Facebook atau PHP 7, versi PHP terbaru. (Mengapa PHP 7? Ceritanya panjang.)

Facebook dan tim PHP membangun dua kompiler ini dari awal. Mereka ingin memanfaatkan strategi kompilasi yang lebih modern. HHVM menggunakan kompilasi just-in-time, sedangkan PHP 7 menggunakan kompilasi sebelumnya. Keduanya menawarkan peningkatan kinerja yang luar biasa dibandingkan PHP 5 yang bagus.

HHVM adalah yang pertama tiba di tempat kejadian beberapa tahun yang lalu. Banyak host tingkat atas telah sukses besar dengannya, menawarkannya sebagai kompiler PHP utama mereka.

Perlu ditekankan, bahwa HHVM bukan kompiler PHP resmi. Ini tidak 100% kompatibel dengan PHP. Alasannya adalah bahwa HHVM tidak hanya dirancang untuk mendukung PHP; itu juga merupakan kompiler untuk bahasa pemrograman Hack Facebook.

PHP 7 adalah kompiler PHP resmi. Sudah lama tidak ada. Tim PHP merilisnya pada bulan Desember 2015. Ini tidak menghalangi beberapa perusahaan hosting WordPress untuk mendukungnya.

Berita baiknya adalah WordPress itu sendiri 100% kompatibel dengan kedua kompiler! Kabar buruknya adalah tidak semua plugin dan tema, karena versi PHP minimum untuk WordPress masih 5.2.

Tidak ada yang memaksa penulis untuk membuat plugin atau tema mereka bekerja dengan kompiler ini. Jadi, Anda tidak bisa masuk semua dengan salah satu dari mereka. Tumpukan Anda harus selalu kembali ke PHP 5.

Siklus Hasil Kueri

Pada titik ini, runtime PHP akan melalui semua file WordPress PHP dan mengeksekusinya. Namun, file WordPress PHP ini tidak berisi data apa pun. Mereka hanya berisi kode WordPress.

Masalahnya adalah WordPress menyimpan semua datanya di database MySQL. Jadi, untuk sampai ke sana, runtime PHP perlu menanyakan database itu. Server MySQL mengembalikan hasil kueri itu, dan runtime PHP kemudian melanjutkan mengeksekusi file WordPress PHP… yah, hingga dibutuhkan data lagi.

Bolak-balik ini dapat terjadi dari beberapa lusin kali hingga beberapa ratus kali. (Anda mungkin ingin berbicara dengan pengembang Anda jika itu yang terakhir!) Itulah mengapa ini menjadi hambatan utama.

Mengoptimalkan Siklus Hasil Kueri

Tujuan optimasi di sini adalah untuk mempercepat waktu eksekusi file WordPress oleh PHP. Di sinilah query database bermasalah. Mereka cenderung membutuhkan lebih banyak waktu daripada hanya menjalankan kode PHP biasa (kecuali kode Anda melakukan sesuatu yang keterlaluan).

Cara yang jelas untuk memperbaiki masalah ini adalah dengan mengurangi jumlah kueri yang perlu dilakukan WordPress. Dan itu selalu berharga! Tapi itu bukan sesuatu yang dapat dibantu oleh tumpukan server WordPress modern.

Kami mungkin tidak dapat mengurangi jumlah kueri yang dibuat WordPress, tetapi kami juga tidak kehabisan opsi. Masih ada dua cara agar tumpukan dapat membantu kami mengoptimalkan siklus hasil kueri. Itu dapat mengurangi jumlah kueri yang dibuat ke database di tempat pertama. Dan untuk kueri yang masuk ke database, ini dapat mengurangi waktu yang diperlukan untuk menjalankannya.

Kedua opsi ini dimaksudkan untuk melakukan hal yang sama: membuat PHP menunggu sesedikit mungkin untuk hasil dari database, yang akan membuat WordPress sendiri lebih cepat.

Elemen Tumpukan Untuk Siklus Hasil Kueri

Mari kita lihat berbagai elemen tumpukan yang terlibat dalam siklus hasil kueri. Bagian tumpukan ini kurang kompleks. Tetapi masih melibatkan lebih dari satu komponen — yaitu, server database MySQL dan cache objek.

Server Basis Data MySQL

Beberapa tahun yang lalu, server database MySQL memiliki arti yang sama bagi semua orang. Itu adalah server dengan server MySQL diinstal. Tetapi banyak hal telah berubah dalam beberapa tahun terakhir.

Berbagai kelompok tidak senang dengan cara Oracle mengelola proyek MySQL. Jadi, setiap grup melakukan fork dan membuat versinya sendiri sehingga Anda bisa "masuk" sebagai gantinya. Hasilnya sekarang sudah ada beberapa database server MySQL.

Server MySQL "resmi" yang baru adalah server MariaDB. Ini adalah versi server MySQL yang dikembangkan komunitas. Komunitas berencana untuk mempertahankan kompatibilitas penuh dengan proyek server MySQL.

Alternatif populer lainnya untuk MySQL adalah server Percona. Tidak seperti MariaDB, Percona lebih merupakan cabang dari MySQL. Pengembangnya tidak menentang proyek MySQL itu sendiri; mereka hanya ingin fokus pada peningkatan kinerja MySQL. Tim MariaDB kemudian menggabungkan beberapa peningkatan kinerja ini ke dalam proyek MariaDB.

Di penghujung hari, Anda dapat memilih yang Anda sukai. Tidak ada perbedaan kinerja antara server Percona dan server MariaDB (bagaimanapun juga bagi kebanyakan dari kita). Keduanya berkinerja lebih baik daripada MySQL. Namun, Percona mempertahankan kompatibilitas yang lebih dekat dengan proyek Oracle.

Apa yang mempengaruhi kinerja adalah mesin penyimpanan yang digunakan database WordPress. Mesin penyimpanan mengontrol bagaimana server database mengelola data yang disimpannya. Anda juga dapat mengatur mesin penyimpanan yang berbeda per tabel database; Anda tidak harus menggunakan yang sama untuk seluruh database.

Sebuah server database memiliki beberapa mesin penyimpanan. Kami tidak akan melihat semuanya. Hanya dua yang menarik bagi kami: InnoDB dan MyISAM.

Secara default, WordPress menggunakan mesin database MySQL default. Sebelum MySQL 5.5, mesin itu adalah MyISAM. Jika Anda menjalankan situs web WordPress kecil, maka MyISAM baik-baik saja. MyISAM mengalami masalah kinerja setelah situs web bertambah besar. Pada saat itu, InnoDB adalah satu-satunya pilihan untuk mesin database.

Satu-satunya masalah dengan InnoDB adalah ia memerlukan beberapa penyetelan untuk melakukan yang terbaik. Jika Anda menjalankan server database besar, Anda mungkin perlu menyesuaikan beberapa hal. Beruntung bagi kami, ada alat untuk membantu dengan itu.

MySQLTuner adalah skrip kecil yang menganalisis server database Anda. Ini akan menghasilkan laporan dan memberi Anda rekomendasi penyetelan.

Cache Objek

Beban kerja optimalisasi siklus hasil kueri terletak pada cache objek. Pekerjaan cache objek adalah untuk menyimpan data yang memakan waktu untuk mendapatkan atau menghasilkan. Seperti yang Anda duga, kueri basis data adalah kandidat yang sempurna.

WordPress banyak menggunakan cache objek. Katakanlah Anda menggunakan get_option untuk mendapatkan opsi dari database. WordPress hanya akan menanyakan database untuk opsi itu satu kali. Itu tidak akan menanyakannya lagi saat berikutnya seseorang membutuhkannya.

Sebagai gantinya, WordPress akan mengambil hasil kueri dari cache objek. Ini adalah langkah proaktif yang diambil WordPress untuk mengurangi jumlah kueri basis data yang perlu dibuat. Tapi itu bukan solusi yang sangat mudah.

Sementara WordPress akan melakukan yang terbaik untuk memanfaatkan cache objek, plugin atau tema tidak harus melakukannya. Jika plugin atau tema membuat banyak kueri basis data dan tidak menyimpan hasil cache, tumpukan tidak dapat berbuat apa-apa.

Dalam kasus seperti itu, sebagian besar kueri basis data akan berasal dari WordPress itu sendiri. Jadi, Anda akan mendapatkan jarak tempuh yang luar biasa dari penggunaan cache objek bawaan WordPress. Itulah mengapa ini merupakan elemen penting dari tumpukan server WordPress modern.

Sekarang, masalah dengan cache objek adalah bahwa ia tidak menyimpan data yang disimpannya secara default. Itu hanya menyimpan data dalam memori saat PHP mengeksekusi semua file WordPress. Tetapi begitu proses PHP berakhir, semua data yang disimpan dalam memori akan dihapus.

Ini sama sekali tidak ideal. Cache objek bisa tetap valid untuk waktu yang lama, jadi Anda tidak ingin membatasinya pada satu permintaan. Solusinya adalah dengan menggunakan cache objek persisten .

Cache objek persisten sering kali datang dalam bentuk plugin. Plugin itu akan menggunakan drop-in object-cache.php untuk melakukan tugasnya. Drop-in ini memungkinkan pembuat plugin mengubah perilaku default cache objek.

Plugin kemudian menghubungkan cache objek ke penyimpanan data persisten. Mereka melakukannya dengan mengganti fungsi pengambilan dan penyimpanan cache objek default. Alih-alih menyimpan dan mengambil data ke memori, cache objek melakukannya dari penyimpanan itu.

Plugin Cache Objek Persisten

Saat ini, ada dua opsi penyimpanan data populer untuk caching objek persisten:

• Memcache (plugin)
• Redis (plugin)

Kedua penyimpanan data ini menggunakan RAM untuk penyimpanan, yang membuatnya secepat kilat. Faktanya, kinerjanya sebanding dengan cache objek default.

Satu-satunya masalah adalah mereka tidak terinstal di server. Dan ekstensi PHP mereka juga tidak (yang opsional dengan Redis). Anda perlu menginstalnya sebelum Anda dapat menggunakan plugin WordPress yang sesuai.

Yang mana yang harus Anda instal? Dalam praktiknya, tidak ada banyak perbedaan antara keduanya untuk caching objek. Di masa lalu, opsi yang populer adalah Memcached. Ini telah berubah selama beberapa tahun terakhir. Redis telah menambahkan banyak fitur yang menjadikannya pilihan masuk untuk caching objek.

Mendapatkan Server WordPress Modern Anda Sendiri

Jadi, bagaimana Anda mendapatkan server Anda sendiri? Cara yang jelas adalah mendapatkannya dari perusahaan hosting WordPress tingkat atas. Perusahaan-perusahaan ini ingin tetap menjadi yang terdepan dalam bisnis hosting WordPress, yang memotivasi mereka untuk mengadopsi terobosan dan teknologi terbaru.

Tetapi bagaimana jika Anda menginginkannya tanpa merusak bank? Beberapa alat tersedia bagi siapa saja yang lebih suka melakukannya sendiri dan membayar lebih sedikit untuk hosting. Mari kita lihat mereka.

DebOps untuk WordPress

DebOps untuk WordPress adalah alat yang saya buat untuk membantu siapa saja membangun server WordPress modern. Misinya adalah membuat tumpukan server WordPress modern tersedia bagi siapa saja di komunitas. Itu sebabnya saya mencoba membuatnya semudah mungkin digunakan. Anda tidak memerlukan pengetahuan administrasi sistem untuk menggunakannya.

DebOps untuk WordPress mengonfigurasi server dengan yang berikut:

• HHVM (sampai PHP 7 membuatnya menjadi repositori Linux resmi)
• MariaDB
• nginx
• Redis
• Pernis

Alat ini tidak hanya mengonfigurasi server dengan teknologi terbaru. Ini juga menangani pengamanan server untuk Anda. Ini adalah sesuatu yang sering diabaikan orang ketika mengelola server mereka sendiri.

EasyEngine

EasyEngine adalah alat baris perintah yang dirancang untuk membantu Anda menyiapkan situs web WordPress di server. Hal hebat tentang EasyEngine adalah fleksibilitasnya: Anda dapat menggunakannya untuk mengatur hampir semua kombinasi teknologi server yang telah kita lihat sejauh ini.

Misalnya, ini memungkinkan Anda mengatur server dengan HHVM atau PHP 7. Ini memungkinkan Anda memilih antara Memcached dan Redis untuk penyimpanan data persisten Anda. Dan itu memungkinkan Anda menginstal alat administrator seperti phpMyAdmin.

Ini juga menawarkan sejumlah besar opsi saat membuat situs web WordPress. Anda dapat memberitahunya untuk menyiapkan situs web dengan cache HTTP menggunakan plugin atau nginx. Semua fleksibilitas ini adalah mengapa EasyEngine adalah alat yang sangat populer.

Terali

Teralis adalah alat yang dikembangkan oleh Roots. Seperti DebOps, ia mengonfigurasi server dengan seperangkat teknologi server tertentu:

• MariaDB
• Memcache
• nginx
• nginx HTTP cache (opsional)
• PHP 7

Satu hal yang perlu diketahui tentang Trellis adalah hubungannya dengan Bedrock, alat lain yang dibuat oleh Roots. Bedrock adalah boilerplate untuk menyusun situs WordPress di sekitar prinsip "Aplikasi Dua Belas Faktor".

Tim Roots membuat Trellis untuk memungkinkan orang mengonfigurasi server yang menggunakan situs web WordPress berstruktur Bedrock. Anda tidak dapat menggunakannya dengan instalasi WordPress normal, jadi ingatlah itu.

Waktu telah berubah

Seperti yang Anda lihat, server WordPress memiliki lebih banyak bagian yang bergerak hari ini! Tapi ini tidak perlu menjadi penyebab putus asa. Tidak seburuk kelihatannya karena Anda tidak selalu perlu menggunakan semua bagian.

Itulah mengapa begitu banyak artikel ini membahas bagaimana bagian-bagian ini bekerja bersama. Intinya adalah untuk memberdayakan Anda untuk membuat keputusan sendiri. Gunakan pengetahuan ini untuk memutuskan bagian mana yang perlu Anda gunakan dan kapan. Dengan cara ini, Anda juga akan memiliki situs WordPress yang cepat.