ฉันควรใช้ Transient API เพื่อจัดเก็บสตริง HTML หรือวัตถุหรือไม่

สมมติว่ามีปลั๊กอินที่แสดงโพสต์ที่เกี่ยวข้อง 20 รายการ (สำหรับแต่ละโพสต์) ด้วยข้อความค้นหาที่ซับซ้อน จากนั้นใช้ข้อมูลจากแบบสอบถามนี้มันสร้างเค้าโครง HTML ที่ซับซ้อน นอกจากนี้ควรสังเกตว่าปลั๊กอินนั้นเป็นสาธารณะและสามารถติดตั้งบนเซิร์ฟเวอร์ใดก็ได้ที่มีการกำหนดค่าใด ๆ

สิ่งที่ต้องการ:

/* complex and large query */
$related_posts = get_posts( ... );

$html_output = '';
foreach($related_posts as $key => $item) {
     /* complex layout rendering logic (but not as slow as the previous query) */   
     $html_output .= ...;
}

ดังนั้นคำถามของฉันคือ:

• วิธีที่ปลอดภัยและถูกต้องที่สุดในการแคชข้อมูลดังกล่าวคืออะไร
• ฉันควรใช้ Transient API เพื่อแคช$related_postsอาร์เรย์หรือ$html_outputสตริง? หากฉันจะแคช$html_ouputสตริงจะถึงขีด จำกัด สูงสุดหรือไม่ ฉันควร gzip ก่อนที่จะบันทึกหรือไม่
• ฉันควรใช้ Transient API ที่นี่หรือไม่

ฉันควรใช้ Transient API ที่นี่หรือไม่

เลขที่

ในสต็อก WordPress ติดตั้งชั่วคราวจะถูกเก็บไว้ในตาราง wp_options และล้างเฉพาะในระหว่างการอัพเกรดหลัก สมมติว่าคุณมี 50,000 โพสต์นั่นคือ 50,000 แถวเพิ่มเติมในตารางตัวเลือก เห็นได้ชัดว่าพวกเขากำลังตั้งค่าเป็น autoload = ไม่ดังนั้นมันจะไม่ใช้หน่วยความจำทั้งหมดของคุณ แต่มีข้อแม้อื่น

ฟิลด์ autoload ในตารางตัวเลือกไม่มีดัชนีซึ่งหมายความว่าการเรียกไปยังwp_load_alloptions()กำลังทำการสแกนตารางเต็ม ยิ่งคุณมีแถวมากเท่าไหร่ก็จะยิ่งใช้เวลานานขึ้นเท่านั้น ยิ่งคุณเขียนลงในตารางตัวเลือกบ่อยเท่าไหร่แคชภายในของ MySQL ที่มีประสิทธิภาพน้อยกว่าก็คือ

หากข้อมูลแคชเกี่ยวข้องโดยตรงกับโพสต์คุณควรเก็บไว้ในโพสต์เมตา การทำเช่นนี้จะช่วยให้คุณบันทึกแบบสอบถามทุกครั้งที่คุณต้องการแสดงเนื้อหาที่แคชเนื่องจากโพสต์เมตาแคช (โดยปกติ) ลงสีพื้นระหว่างการดึงโพสต์ใน WP_Query

โครงสร้างข้อมูลของคุณสำหรับค่าเมตาอาจแตกต่างกันคุณสามารถมีการประทับเวลาและดำเนินการค้นหาที่มีราคาแพงหากค่าแคชล้าสมัยแล้ว

อีกสิ่งหนึ่งที่สำคัญที่ควรคำนึงถึงก็คือ WordPress สามารถเปลี่ยนแปลงได้ในสภาพแวดล้อมที่มีการแคชวัตถุถาวร ซึ่งหมายความว่าหากคุณเก็บข้อมูลที่แคชไว้เป็นเวลา 24 ชั่วโมงในช่วงเวลาชั่วคราวไม่มีการรับประกันว่าจะสามารถใช้ได้ใน 23 ชั่วโมงหรือ 12 หรือแม้กระทั่ง 5 นาที แบ็กเอนด์แคชวัตถุสำหรับการติดตั้งจำนวนมากเป็นที่เก็บคีย์ - ค่าในหน่วยความจำเช่น Redis หรือ Memcached และหากมีหน่วยความจำที่จัดสรรไม่เพียงพอเพื่อให้พอดีกับวัตถุที่ใหม่กว่ารายการที่เก่ากว่าจะถูกขับออก นี่เป็นชัยชนะครั้งใหญ่ของเมตาดาต้าสตอเรจ

การตรวจสอบความถูกต้องอาจทำได้อย่างชาญฉลาดด้วยเช่นกันเหตุใดคุณจึงทำการตรวจสอบแคชบทความที่เกี่ยวข้องในเวลา X ชั่วโมง เป็นเพราะเนื้อหาบางส่วนมีการเปลี่ยนแปลงหรือไม่? โพสต์ใหม่ได้รับการเพิ่ม? มีการกำหนดแท็กใหม่หรือไม่ ขึ้นอยู่กับ "ข้อความค้นหาที่ซับซ้อนและมีขนาดใหญ่" ของคุณคุณอาจเลือกที่จะทำให้เป็นโมฆะเท่านั้นหากมีสิ่งใดเกิดขึ้นที่จะเปลี่ยนผลลัพธ์ของข้อความค้นหาของคุณ

ฉันควรใช้ Transient API เพื่อแคช $ related_posts array หรือสตริง $ html_output หรือไม่ ถ้าฉันจะแคช $ html_ouput สตริงมันจะถึงขีด จำกัด ขนาดสูงสุดหรือไม่ ฉันควร gzip ก่อนที่จะบันทึกหรือไม่

มันขึ้นอยู่กับขนาดของสตริงเนื่องจากข้อมูลที่จะไหลระหว่าง PHP, MySQL, ฯลฯ คุณจะต้องพยายามอย่างหนักเพื่อให้ถึงขีด จำกัด ของ MySQL แต่ตัวอย่าง Memcached เริ่มต้นต่อขีด จำกัด ของวัตถุคือ เพียง 1 mb

ตรรกะการเรนเดอร์โครงร่างที่ซับซ้อนของคุณใช้เวลานานเท่าไหร่ เรียกใช้ผ่านตัวสร้างโปรไฟล์เพื่อค้นหา โอกาสที่มันจะเร็วมากจะไม่กลายเป็นคอขวด

หากเป็นกรณีนี้ฉันขอแนะนำให้แคชรหัสโพสต์ ไม่ใช่วัตถุ WP_Post เพราะสิ่งเหล่านั้นจะมีเนื้อหาโพสต์แบบเต็ม แต่เป็นอาร์เรย์ของรหัสโพสต์ จากนั้นใช้เพียงแค่WP_Querya post__inซึ่งจะส่งผลให้แบบสอบถาม MySQL รวดเร็วมากโดยคีย์หลัก

ที่กล่าวว่าหากข้อมูลที่ต้องการต่อรายการค่อนข้างง่ายบางทีชื่อเรื่อง URL ของภาพขนาดย่อและลิงก์ถาวรจากนั้นคุณสามารถจัดเก็บข้อมูลทั้งสามนี้ได้โดยไม่ต้องมีค่าใช้จ่ายในการไปกลับไปยัง MySQL เป็นพิเศษ เงื่อนไข

ว้าวนั่นเป็นคำพูดมากมายหวังว่าจะช่วยได้

ไม่ใช่รหัส WP ทั้งหมดเป็นรหัสสาธารณะ

หากคุณกำลังจะเผยแพร่สิ่งที่เป็นสาธารณะทุกสิ่งที่kovsheninกล่าวจะถูกต้องสมบูรณ์

สิ่งต่าง ๆ ถ้าคุณกำลังจะเขียนรหัสส่วนตัวสำหรับตัวคุณเองหรือ บริษัท ของคุณ

แคชวัตถุภายนอกมีประโยชน์มากในทุกกรณี

ในการตั้งค่าแคชวัตถุถาวรภายนอกขอแนะนำอย่างมากเมื่อคุณสามารถ

ทุกสิ่งที่กล่าวไว้ในคำตอบของ kovshenin เกี่ยวกับ transients และ MySQL นั้นเป็นเรื่องจริงมากและเมื่อพิจารณาว่า WP และปลั๊กอินจำนวนมากใช้ประโยชน์จากแคชวัตถุ ... จากนั้นการปรับปรุงประสิทธิภาพที่คุณได้รับนั้นคุ้มค่ากับความพยายามเล็ก ๆ ระบบแคชที่ทันสมัยเช่น Redis หรือ Memcached

ค่าที่เก็บไว้อาจไม่อยู่ที่นั่น: ก็ดี

นอกจากนี้ใช่แคชวัตถุภายนอกไม่น่าเชื่อถือ คุณไม่ควรพึ่งพาความจริงที่ว่ามีอยู่ชั่วขณะ คุณต้องตรวจสอบให้แน่ใจว่ามันใช้งานได้หากแคชไม่ได้อยู่ในที่ที่ควรจะเป็น

แคชไม่ได้เก็บไว้, แคชคือแคช

ใช้แคชเลือก

ดูตัวอย่างนี้:

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;
}

การใช้รหัสเช่นนี้ในเว็บไซต์ส่วนตัวของคุณประสิทธิภาพของเว็บไซต์สามารถปรับปรุงได้มากโดยเฉพาะหากคุณมีผู้ใช้จำนวนมาก

โปรดทราบว่า:

• โดยค่าเริ่มต้นแคชจะไม่ถูกใช้เมื่อมีการดีบักดังนั้นหวังว่าในสภาพแวดล้อมการพัฒนาของคุณ เชื่อฉันสิแคชสามารถทำให้ดีบั๊กได้
• โดยค่าเริ่มต้นแคชยังไม่ได้ใช้เมื่อ WP ไม่ได้ตั้งค่าให้ใช้แคชวัตถุภายนอก หมายความว่าไม่มีปัญหาทั้งหมดที่เชื่อมต่อกับ MySQL เพราะคุณไม่ได้ใช้ชั่วคราวเมื่อพวกเขาใช้ MySQL ทางเลือกที่ง่ายกว่าน่าจะเป็นการใช้งานwp_cache_*ฟังก์ชั่นดังนั้นหากไม่มีการตั้งค่าแคชภายนอกดังนั้นแคชจะเกิดขึ้นในหน่วยความจำและฐานข้อมูลไม่เกี่ยวข้อง
• การใช้แคชสามารถกรองได้เพื่อจัดการกับขอบบางกรณีที่คุณอาจพบ

ไม่มีหน้าเว็บหากไม่มีแคช

คุณไม่ควรพยายามแก้ไขปัญหาความเร็วของแคช หากคุณมีปัญหาเรื่องความเร็วคุณควรคิดรหัสอีกครั้ง

แต่การที่จะปรับขนาดได้ที่เว็บไซต์ webscale ที่แคชสวยต้อง

และหลายครั้ง (แต่ไม่เสมอไป) แคชที่รับรู้บริบทมีความยืดหยุ่นและเหมาะสมกว่าแคชแบบเต็มหน้าเชิงรุก

คำถามของคุณ:

ฉันควรใช้ Transient API ที่นี่หรือไม่

มันขึ้นอยู่กับ

รหัสของคุณใช้ทรัพยากรจำนวนมากหรือไม่? ถ้าไม่เช่นนั้นอาจไม่จำเป็นต้องใช้แคช ดังที่ได้กล่าวมาไม่ใช่แค่เรื่องของความเร็ว หากรหัสของคุณทำงานเร็ว แต่ต้องการ CPU และหน่วยความจำจำนวนมากสำหรับผู้ใช้สองคน ... จะเกิดอะไรขึ้นเมื่อคุณมีผู้ใช้งานพร้อมกัน 100 หรือ 1,000 คน

หากคุณรู้ว่าแคชจะเป็นความคิดที่ดี ..

... และเป็นรหัสส่วนกลาง: อาจจะไม่มี คุณสามารถพิจารณาเลือกแคชเช่นในตัวอย่างด้านบนของฉันในรหัสสาธารณะ แต่โดยปกติจะดีกว่าถ้าคุณออกจากการตัดสินใจไปยังผู้ใช้งาน

... และเป็นรหัสส่วนตัว: อาจเป็นไปได้ แต่สำหรับรหัสส่วนตัวการเลือกแคชก็ยังคงเป็นสิ่งที่ดีตัวอย่างเช่นสำหรับการดีบั๊ก

โปรดจำไว้ว่าwp_cache_*ฟังก์ชั่นนั้นสามารถให้คุณเข้าถึงแคชได้โดยไม่ต้องเสี่ยงกับฐานข้อมูล

ฉันควรใช้ Transient API เพื่อแคช $ related_posts array หรือสตริง $ html_output หรือไม่

มันขึ้นอยู่กับหลาย ๆ อย่าง สตริงใหญ่แค่ไหน? คุณกำลังใช้แคชภายนอก หากคุณกำลังจะโพสต์แคชการจัดเก็บ ID เป็นอาร์เรย์อาจเป็นความคิดที่ดีการสอบถามจำนวนการโพสต์ที่เหมาะสมด้วย ID ของพวกเขานั้นค่อนข้างเร็ว

หมายเหตุสุดท้าย

Transient API น่าจะเป็นหนึ่งในสิ่งที่ดีที่สุดของ WordPress ขอบคุณปลั๊กอินที่คุณสามารถค้นหาระบบแคชทุกประเภทมันกลายเป็น API ง่าย ๆ ไปจนถึงซอฟต์แวร์จำนวนมากที่สามารถทำงานได้ภายใต้ประทุน

นอก WordPress สิ่งที่เป็นนามธรรมที่ทำงานนอกกรอบด้วยระบบแคชที่แตกต่างกันมากมายและให้คุณเปลี่ยนจากระบบหนึ่งไปอีกระบบหนึ่งโดยไม่ต้องใช้ความพยายามมากนัก

คุณไม่ค่อยได้ยินฉันพูดว่า WordPress ดีกว่าสิ่งทันสมัยอื่น ๆ แต่ API ชั่วคราวเป็นหนึ่งในสองสามสิ่งที่ฉันพลาดเมื่อฉันไม่ทำงานกับ WordPress

แคชแน่นอนยากไม่แก้ปัญหารหัสและไม่ใช่ bullet เงิน แต่เป็นสิ่งที่คุณต้องสร้างไซต์ที่มีปริมาณการใช้งานสูง

แนวคิดของ WordPress ในการใช้ตาราง MySQL ภายใต้การทำแคชที่ไม่เหมาะสม แต่ก็ไม่ดีกว่าที่จะป้องกันตัวคุณเองให้ห่างจากแคชเพียงเพราะ WordPress เป็นค่าเริ่มต้น

คุณเพียงแค่ต้องเข้าใจว่าสิ่งต่าง ๆ ทำงานอย่างไรจากนั้นเลือก

คำตอบก่อนหน้านี้ได้เน้นย้ำถึงข้อบังคับ " ขึ้นอยู่กับ " ซึ่งฉันเห็นด้วยอย่างเต็มที่

ฉันต้องการที่จะเพิ่มข้อเสนอแนะขึ้นอยู่กับว่าฉัน " คิดว่า " นี้จะทำดีที่สุดในสถานการณ์ที่คุณอธิบายไว้ข้างต้น

ฉันจะไม่ใช้Transientsในกรณีที่ว่า แต่โพสต์ Metaเพราะประโยชน์หนึ่งที่หลังมี: การควบคุม

เมื่อคุณต้องการแคชข้อมูลตามการโพสต์จำนวนของข้อมูลที่คุณจะแคชขึ้นอยู่กับจำนวนโพสต์และจะเพิ่มขึ้นเมื่อเวลาผ่านไป เมื่อคุณโพสต์เกินจำนวนที่กำหนดแล้วคุณอาจถึงขีด จำกัด ของหน่วยความจำแคชวัตถุของคุณที่ได้รับอนุญาตให้ใช้และจะเริ่มลบข้อมูลที่แคชไว้ก่อนหน้านี้ออกจากหน่วยความจำก่อนที่มันจะหมดอายุ สิ่งนี้อาจนำไปสู่สถานการณ์ที่คุณมีผู้เยี่ยมชมจำนวนมากซึ่งผู้เข้าชมแต่ละคนจะเรียก "SQL ที่ซับซ้อนมากเกินไป" ตามคำขอหน้าเว็บแต่ละหน้าและไซต์ของคุณจะจมลงอย่างสมบูรณ์

หากคุณแคชข้อมูลใน Post Meta ของคุณคุณไม่เพียงสามารถควบคุมวิธีการจัดเก็บและดึงข้อมูลได้ แต่คุณยังสามารถควบคุมวิธีการอัปเดตได้อย่างแม่นยำ คุณจะเพิ่มงาน cron สำหรับสิ่งนี้ที่ทำงานเฉพาะในช่วงเวลาที่มีการเข้าชมน้อยไปยังเว็บไซต์ ดังนั้น "การค้นหาที่ช้า" จะไม่เคยพบโดยผู้ใช้จริงของเว็บไซต์และคุณสามารถโหลดล่วงหน้าได้เพื่อที่ว่างานจะเสร็จสิ้นเมื่อผู้เยี่ยมชมคนแรกเข้ามา

โปรดทราบว่าการแคชทั้งหมดเป็นการแลกเปลี่ยน! นั่นเป็นเหตุผลที่คำตอบปกติคือ "มันขึ้นอยู่กับ" และทำไมไม่มี "จอกศักดิ์สิทธิ์แคช"