Apakah get_option () lebih cepat daripada mengakses get_transient ()?

Hari ini saya menjalankan tes pada db saya untuk mengeksplorasi perbedaan kecepatan antara mengakses kunci dari opsi, tabel khusus & transien. Saya menjalankan tes untuk 1000 kali dan berikut ini adalah waktu yang dibutuhkan untuk menjalankan 1000 operasi:

1. get_transient() 0,0245 detik
2. get_option() 0,0068 detik
3. operasi pilih sederhana dari Tabel Kustom 0,65 detik

Saya juga memeriksa bahwa transien tidak kedaluwarsa selama tes ini. Jadi pertanyaannya adalah, apakah get_option()lebih cepat dari get_transient()atau apakah saya mengacaukan sesuatu dalam pengujian saya? Apakah custom table delay karena opsi di-cache default oleh WordPress? Juga, apakah opsi juga di-cache oleh plugin caching yang berbeda seperti transien?

Hari ini saya menjalankan tes pada db saya untuk mengeksplorasi perbedaan kecepatan antara mengakses kunci dari opsi, tabel khusus & transien. Saya menjalankan tes untuk 1000 kali dan berikut ini adalah waktu yang dibutuhkan untuk menjalankan 1000 operasi:

Ingatlah bahwa tabel opsi digunakan untuk opsi dan transien pada sebagian besar sistem, dan tabel itu telah dioptimalkan, dengan indeks yang ditambahkan. Jadi itu bukan perbandingan yang adil

get_transient () 0,0245 detik get_option () 0,0068 detik operasi pilih sederhana dari Tabel Kustom 0,65 detik

Ini juga merupakan perbandingan yang tidak adil, opsi dengan autoloadset opsi, akan dimuat lebih lanjut dalam satu permintaan awal. Begitu get_optionmenarik dari WP_Cache, opsi sudah diambil.

TLDR: Ini sebenarnya bukan mengambil opsi, itu sudah diambil, itu hanya menariknya dari memori karena autoloadopsi

Saya juga memeriksa bahwa transien tidak kedaluwarsa selama tes ini.

Ini seharusnya tidak berdampak pada sistem normal pada pengambilan sementara, setelah semua itu tidak tahu apakah itu kadaluwarsa sampai itu diambil.

Jadi pertanyaannya adalah, apakah get_option () lebih cepat dari get_transient () atau apakah saya mengacaukan sesuatu dalam pengujian saya?

Tergantung:

• Pada kebanyakan sistem, transien disimpan menggunakan opsi, keduanya melibatkan get_optionpanggilan
• Pilihan dengan autoloadset ke true semua dimuat dalam satu panggilan di awal sehingga mereka disimpan dalam memori, tidak ada pertanyaan yang terjadi setelah ini
• Tembolok cache cache kedua opsi dimuat secara otomatis, dan transien

Apakah custom table delay karena opsi di-cache default oleh WordPress?

Sangat mungkin, tetapi seberapa cepat pemilihan yang dilakukan sangat bergantung pada kueri dan desain tabel

Juga, apakah opsi juga di-cache oleh plugin caching yang berbeda seperti transien?

Ya, WP_Cachedigunakan, yang akan menyimpannya dalam memori selama sisa permintaan. Plugin caching mungkin bertahan nilai-nilai ini untuk alasan kinerja.

Pengulangan

Ini semua di-cache via WP_Cachebegitu kedua kali Anda memintanya, tidak ada DB yang terlibat.

Variabilitas dan Tergantung

Ini semua mengasumsikan dasar yang sama, tetapi bagaimana dengan cache objek?

Mari kita perkenalkan instance MemcacheD, atau instance Redis (SAYA SANGAT menyarankan Anda melakukannya jika Anda memiliki opsi, manfaat kinerja BESAR untuk situs yang dibangun dengan baik, terutama jika Anda menggunakannya untuk caching halaman, kecuali jika Anda memiliki sesuatu seperti pengaturan Varnish)

Sekarang kami memiliki situasi baru:

• Sekarang data disimpan dalam RAM, dan setelah diambil dari DB, itu disiapkan, dan waktu akses berkurang secara dramatis. Masih lebih lambat dari variabel, tetapi secara signifikan lebih cepat dari permintaan basis data
• Banyak data baru disimpan di tempat WP_Cacheyang biasanya tidak. Misalnya WP_Postobjek, posting meta, dll
• WP_Cache sekarang tetap ada di seluruh permintaan
• MemcacheD dll dapat menghilangkan transien kadaluarsa dll

Jadi sekarang transien dan opsi memiliki biaya akses yang sama. Mereka sudah dekat, tetapi mereka sekarang diabaikan dan lebih berkaitan dengan beban CPU pada saat permintaan dibuat.

Jadi Untuk Kinerja, Haruskah Saya Menggunakan Transien atau Opsi?

Meskipun ini adalah pertanyaan yang layak untuk ditanyakan, jawabannya adalah bahwa perbedaannya dapat diabaikan dan dalam batas kesalahan

Jadi berhentilah mengoptimalkan-mikro, mereka adalah media penyimpanan yang sama, dan ini tidak pantas untuk waktu Anda

• Gunakan opsi jika Anda perlu menyimpan sesuatu yang luas situs
• Gunakan transien untuk menyimpan sementara hal-hal yang mahal untuk dihitung sehingga Anda tidak perlu ke waktu berikutnya

Tidak sepadan dengan waktu Anda untuk memilih satu dari yang lain berdasarkan kinerja, tidak ada perbedaan yang berarti.

Ada banyak hal yang lebih baik untuk dilakukan untuk mengoptimalkan yang memberikan penghematan yang jauh lebih besar, misalnya menggunakan taksonomi alih-alih meta dalam kueri pos, tidak menggunakan __notparameter gaya, melakukan lebih sedikit hal pada halaman, memasang cache objek, posting lebih rendah per halaman, menghindari permintaan jarak jauh dll

Bagaimana Dengan Meja Kustom Yang Akan ...

Tidak, tabel opsi sudah dioptimalkan dengan baik, menggunakan tabel khusus hanya akan memindahkan operasi di luar sistem Caching WP, memaksa Anda untuk menulis sendiri

Jika tidak ada cache objek ditemukan, get_transientpanggilan get_optiondua kali, sekali atau interval kadaluwarsa dan satu untuk nilai, karenanya tidak akan menjadi lebih cepat.

get_optionkinerja dengan sendirinya akan berdampak pada apakah opsi "diisi otomatis" (default) atau tidak. Semua opsi yang diambil secara otomatis diambil dalam satu permintaan untuk DB dan disimpan dalam cache memori, dan karenanya harus ada dampak yang sangat kecil pada berapa kali Anda menelepon get_optionbahkan jika itu untuk opsi yang berbeda.

Ketika Anda mengakses DB secara langsung, Anda melewati semua caching dan peningkatan kinerja lainnya, dan itu diharapkan akan lebih lambat kecuali jika Anda menerapkan beberapa logika pintar sendiri.

Semua yang mengatakan, saya tidak yakin pengujian Anda adalah yang baik, tetapi terlepas dari itu, seluruh diskusi tidak ada gunanya jika Anda benar-benar peduli tentang kinerja Anda akan menggunakan sistem cache objek (dan plugin yang relevan) yang akan membawa waktu akses data lebih dekat ke nol .... dan tentu saja jika Anda memutuskan untuk menggunakan tabel DB Anda sendiri, Anda harus mengintegrasikan API akses Anda dengan mekanisme caching objek.