Tidak Semua Kode WP Adalah Kode Publik
Jika Anda akan merilis sesuatu untuk umum, maka semua hal yang dikatakan kovshenin benar-benar valid.
Hal-hal berbeda jika Anda akan menulis kode pribadi untuk diri sendiri atau perusahaan Anda.
Cache Objek Eksternal Adalah Manfaat Besar, Bagaimanapun
Untuk mengatur cache objek persisten eksternal sangat dianjurkan , bila Anda bisa.
Semua hal yang dikatakan dalam jawaban kovshenin tentang transien dan MySQL sangat benar, dan mengingat WP itu sendiri dan sekelompok plugin menggunakan cache objek ... maka peningkatan kinerja yang Anda dapatkan, sangat sepadan dengan usaha (kecil) untuk menyiapkan sistem cache modern seperti Redis atau Memcached.
Nilai-Nilai Cached Mungkin Tidak Ada Di Sana: Tidak masalah
Selain itu, ya, cache objek eksternal tidak dapat diandalkan. Anda seharusnya tidak pernah mengandalkan fakta bahwa transien ada di sana. Anda perlu memastikan itu berfungsi jika cache tidak berada di tempat seharusnya .
Cache bukan penyimpanan, cache adalah cache.
Gunakan Cache Secara Selektif
Lihat contoh ini:
function my_get_some_value($key) {
// by default no cache when debug and if no external object_cache
$defUse = ! (defined('WP_DEBUG') && WP_DEBUG) && wp_using_ext_object_cache();
// make the usage of cache filterable
$useCache = apply_filters('my_use_cache', $defUse);
// return cached value if any
if ($useCache && ($cached = get_transient($key))) {
return $cached;
}
// no cached value, make sure your code works with no cache
$value = my_get_some_value_in_some_expensive_way();
// set cache, if allowed
$useCache and set_transient($key, $value, HOUR_IN_SECONDS);
return $value;
}
Menggunakan kode seperti ini, di situs pribadi Anda, kinerja situs dapat meningkat banyak , terutama jika Anda memiliki banyak pengguna.
Perhatikan bahwa:
- Secara default, cache tidak digunakan saat debug aktif, jadi semoga pada lingkungan pengembangan Anda. Percayalah, cache bisa membuat debug menjadi neraka
- Secara default cache juga tidak digunakan ketika WP tidak diatur untuk menggunakan cache objek eksternal. Ini berarti bahwa semua masalah yang terhubung dengan MySQL tidak ada, karena Anda tidak menggunakan transient ketika mereka menggunakan MySQL. Alternatif yang mungkin lebih mudah adalah menggunakan
wp_cache_*fungsi , jadi jika tidak ada cache eksternal yang diatur, maka cache terjadi dalam memori, dan database tidak pernah terlibat.
- Penggunaan cache dapat difilter, untuk menangani beberapa kasus tepi yang mungkin Anda temui
Tidak Ada Skala Web Jika Tidak Ada Tembolok
Anda seharusnya tidak mencoba memecahkan masalah kecepatan dengan cache. Jika Anda memiliki masalah kecepatan, maka Anda harus memikirkan kembali kode Anda.
Tetapi untuk skala situs web di webscale, cache sangat diperlukan .
Dan banyak kali (tetapi tidak selalu) fragmen, cache yang sadar konteks jauh lebih fleksibel dan cocok daripada caching fullpage yang agresif.
Pertanyaan Anda:
Haruskah saya menggunakan API sementara di sini?
Itu tergantung .
Apakah kode Anda menghabiskan banyak sumber daya? Jika tidak, mungkin tidak perlu cache. Seperti yang dikatakan, bukan hanya masalah kecepatan. Jika kode Anda berjalan cepat tetapi membutuhkan banyak CPU dan memori untuk beberapa pengguna ... apa yang terjadi ketika Anda memiliki 100 atau 1000 pengguna secara bersamaan?
Jika Anda menyadari cache akan menjadi ide yang bagus ..
... dan kode publik: mungkin tidak . Anda dapat mempertimbangkan untuk melakukan cache secara selektif, seperti dalam contoh saya di atas dalam kode publik, tetapi biasanya lebih baik jika Anda menyerahkan keputusan tersebut kepada pelaksana.
... dan merupakan kode pribadi: sangat mungkin ya . Tetapi bahkan untuk kode pribadi, melakukan cache secara selektif masih merupakan hal yang baik, misalnya untuk debug.
Ingatlah, wp_cache_*fungsi itu dapat memberi Anda akses ke cache tanpa risiko mencemari basis data.
Haruskah saya menggunakan Transient API ke cache $ related_posts array, atau $ html_output string?
Itu tergantung pada banyak hal. Seberapa besar talinya? Cache eksternal mana yang Anda gunakan? Jika Anda akan meng-cache posting, menyimpan ID sebagai array bisa menjadi ide yang baik, meminta jumlah posting yang layak dengan ID mereka cukup cepat.
Catatan Akhir
API sementara mungkin merupakan salah satu hal terbaik dari WordPress. Berkat plugin yang dapat Anda temukan untuk semua jenis sistem cache, itu menjadi API sederhana yang bodoh untuk sejumlah besar perangkat lunak yang dapat bekerja di bawah tenda.
Di luar WordPress, abstraksi semacam itu yang bekerja di luar kotak dengan sekelompok sistem caching yang berbeda, dan memungkinkan Anda untuk beralih dari satu sistem ke sistem lainnya tanpa upaya yang sangat sulit ditemukan.
Anda jarang dapat mendengar saya mengatakan bahwa WordPress lebih baik daripada hal-hal modern lainnya, tetapi API sementara adalah salah satu dari beberapa hal yang saya lewatkan ketika saya tidak bekerja dengan WordPress.
Tentunya cache itu sulit, tidak memecahkan masalah kode dan bukan peluru perak, tetapi sesuatu yang Anda butuhkan untuk membangun situs lalu lintas tinggi yang berfungsi.
Gagasan WordPress untuk menggunakan tabel MySQL yang dioptimalkan untuk melakukan cache cukup gila, tetapi tidak lebih baik untuk menjauhkan diri dari cache hanya karena WordPress, secara default, melakukannya.
Anda hanya perlu memahami cara kerja berbagai hal, lalu tentukan pilihan Anda.