Refactoring Wordpress เพื่อปรับปรุงประสิทธิภาพหน่วยความจำ [ปิด]


63

ฉันได้ดูที่การใช้หน่วยความจำ Wordpress บนเว็บไซต์ของฉันดูเหมือนว่าแต่ละหน้าจะได้รับการจัดสรร RAM ขนาด 20MB เพียงเพื่อเตรียมสภาพแวดล้อมที่แสนสบายสำหรับปลั๊กอินทั้งหมดที่จะใช้งานฉันวางแผนลงมือดังนี้

ไม่มีจุดเดียวที่จะเพิ่มประสิทธิภาพไม่มีชายเลวคนเดียวที่กินหน่วยความจำส่วนใหญ่ ปริมาณการใช้ทั้งหมดแผ่กระจายไปทั่วหลายโมดูล PHP มากมาย

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

นอกจากนี้ ... ทำไม 20MB ใครสามารถให้ข้อมูลเชิงลึกเกี่ยวกับเรื่องนี้?

แก้ไข: นี่คือผลลัพธ์ WinCacheGrind ใน Wordpress ที่ทำงานบนเครื่องพัฒนาของฉัน (เร็วกว่าโฮสติ้งที่แชร์) อย่างที่คุณเห็นมันใช้เวลามากกว่าหนึ่งวินาทีในการบีบอัดเพื่อสร้าง HTML ของหน้าหลัก ชะลอตัวลงด้วยการแชร์โฮสติ้งและคุณมีสูตรสำหรับปัญหา ฉันเลือกวิธีที่ใช้เวลาส่วนใหญ่ คุณจะเพิ่มประสิทธิภาพสิ่งนี้อย่างไร

แก้ไข: นี่คือสถิติแบบสอบถามจากเป็นเครื่องมือโปรไฟล์ functions.php ที่ยอดเยี่ยมนี้

โหลด: 12 คิวรี - 532ms - 19.1MB - 43 แคชฮิต / 53
การค้นหา: 15 คำค้นหา - 563ms - 19.0MB - 72 แคชยอดฮิต / 86
จอแสดงผล: 21 คำสั่ง - 705ms - 19.2MB - 234 แคชที่ฮิต / 257

แก้ไข: คุณต้องการที่จะเห็นสิ่งที่รับประกันว่าจะทำให้คุณประหลาด? แทรกบรรทัดเหล่านี้ที่ท้าย index.php:


echo "<pre>\n";
print_r(get_defined_vars());
echo "</pre>\n";

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

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

แก้ไข: หลังจากวันที่พยายามคิดออกนี่คือการค้นพบของฉัน:

1) 88% ของหน่วยความจำทั้งหมดมาจากความต้องการหรือรวมหรือรวมประเภทของการโทร:

2) ไฟล์ php ส่วนใหญ่เกิดขึ้นในช่วงแรกของการให้บริการตามคำขอ (ไม่น่าแปลกใจ) ซึ่งเป็นที่ที่หน่วยความจำทั้งหมดถูกกินหมด:

3) มันค่อนข้างน่าสนใจที่จะพล็อตฟังก์ชั่นทั้งหมดที่จะถูกดำเนินการในระหว่างการร้องขอ มีการโทรทั้งหมดมากกว่า 12,000 สาย ฉันกระวนกระวายใจพวกเขาเพื่อให้มองเห็นได้มากขึ้น (แกนระดับคือความลึกของกองซ้อน):

4) หนทางเดียวที่ฉันจะนึกถึงคือการลดจำนวนไฟล์. php ที่รวมอยู่ให้น้อยที่สุด หากฉันแยกฟังก์ชั่นต่อไฟล์ที่มาจากคุณจะเห็นว่ามีหลาย ๆ ไฟล์ที่ถูกตีหนึ่งครั้งหรือสองครั้ง เราต้องการวิธีที่จะข้ามสิ่งเหล่านั้นเมื่อไม่ต้องการ ตัวอย่างเช่นปลั๊กอินสำรองฐานข้อมูลระยะไกลของฉันได้รับการโหลดและลงทะเบียนเพียงเพื่อไม่ให้ใช้เลย นี่คือการลงจุดแยกตามชื่อไฟล์:

ฉันกำลังเสนอรางวัลที่คุ้มค่ากับชื่อเสียงทั้งหมดของฉัน :) สำหรับการปรับโครงสร้างซึ่งจะนำไปสู่การลดการใช้หน่วยความจำบล็อกของฉันลง 30% หรือมากกว่า

แก้ไข: ฉันติดตั้ง WP 3.1 นี่คือการเปรียบเทียบกับรุ่นเก่า

สีน้ำเงินคือ WP 3.1, สีแดงคือ 3.0.4 WP ใหม่นั้นเร็วกว่า แต่ก็กินหน่วยความจำได้มากกว่า

นี่คือรายการโดยรวมไฟล์

สิ่งนี้ให้ฉันรู้ว่าหน่วยความจำนั้นถูกกินโดย "All In One SEO pack" เท่าไหร่ - หนึ่งอเวนิวจะใช้เพียงเศษเสี้ยวของการทำงานของปลั๊กอินเพื่อให้ได้สิ่งที่ฉันต้องการ นอกจากนี้ปลั๊กอินของฉันเองก็ดูไม่ดีเหมือนกัน

ฉันต้องการลองโหลดแบบมีเงื่อนไขเช่น comment.php (ฉันไม่อนุญาตให้แสดงความคิดเห็นในบล็อกของฉัน) และอีกหลาย ๆ ฉันลบรหัสที่ไม่สอดคล้องทั้งหมด ฉันลด kses.php ลงเพื่อโหลดเฉพาะตารางทั่วโลกตามต้องการ ฉันทำให้ l10n ง่ายขึ้น (ฉันไม่ได้แปลหลายภาษา) ทำให้ฟังก์ชันของมันคืนค่าสตริงทันทีโดยไม่มีการค้นหา ฉันยังห่างไกลจากเครื่องหมาย 30% ที่ฉันตั้งขึ้นโดยพลการ

แก้ไข: ฉันดาวน์โหลดและเปิดใช้งาน APC ด้วยการตั้งค่าเริ่มต้น (แคช opcode 32MB) นี่คือการเปรียบเทียบ:

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


คุณสามารถอัปโหลดไฟล์ cachegrind เองได้ไหม แค่ทราบว่าฉันจำไม่ได้ว่ามีสิ่งใดที่ควรค่าแก่การรักษาความเป็นส่วนตัวรวมอยู่ในนั้นถ้าเป็น - ก็อย่า
Rarst

@Rarst มันควรจะดี foxloft.com/files/mbala/cachegrind.out
Roman Zenka

1
อืมฉันเห็นด้วยกับข้อสรุปของคุณ - ไม่มีอะไรที่จะกระโดดออกไปได้จริงขอให้แก้ไข ฉันทิ้งโปรไฟล์ใหม่ในสแต็คการทดสอบในพื้นที่ของฉัน (3.1, MS, Twenty Ten, ข้อมูลการทดสอบหน่วย Theme) และได้ 1,5s (ความแตกต่างส่วนใหญ่น่าจะเป็นเพราะเมนูที่กำหนดเอง - เป็นสิ่งที่สกปรก) ดังนั้นฉันเดาว่าจะไม่แก้ไข = การวิจัยแคชเป็น
Rarst

@Rarst ขอบคุณมากสำหรับความช่วยเหลือของคุณ ฉันคิดว่ามีสิ่งที่ต้องแก้ไข แต่ต้องเปลี่ยนสถาปัตยกรรมของ Wordpress เป็นปรัชญาที่แตกต่างกันโดยสิ้นเชิงและนั่นก็เป็นงานที่มากเกินไป
Roman Zenka

คำตอบ:


25

ไม่คุ้มกับปัญหา WordPress ไม่ได้กินหน่วยความจำมากมายเพียงเพราะ - มันกินหน่วยความจำมากเพราะมันใช้งานได้หลากหลายภายใต้ประทุน

มันง่ายกว่าและมีประสิทธิภาพมากกว่าในการแคชผลลัพธ์ (สร้างหน้า) ด้วยปลั๊กอินแคชแบบสแตติกและแสดงผลนั้น ด้วยวิธีนี้ผู้เข้าชมส่วนใหญ่จะไม่ได้ชม WP ด้วยตัวเอง


2
ฉันใช้แคชอยู่แล้ว แต่ฉันยังมีหน้าไม่กี่หน้าที่มีการเคลื่อนไหวอย่างแท้จริงในธรรมชาติ (เช่นตะกร้าสินค้า) และเมื่อดาวไม่ได้รับการจัดวางอย่างถูกต้องผู้ใช้สามารถรอ 20 วินาที - นั่นคือได้รับบน GoDaddy แต่ถึงแม้ว่าจะไม่ใช่ก็ตามฉันคิดว่าอย่างน้อยมันจะเป็น ~ 3 วินาที ฉันไม่สามารถมอบประสบการณ์ที่น่าพึงพอใจที่ผู้คนคุ้นเคยจาก Google ได้
Roman Zenka

8
@ Roman Zenka หากคุณมีความต้องการด้านประสิทธิภาพที่เฉพาะเจาะจงคุณจะมองหาวิธีการแก้ปัญหาได้ดีกว่าหวังว่า WordPress จะกลายเป็นแหล่งข้อมูลที่รวดเร็วและมีพลัง สิ่งแรกที่ฉันขอแนะนำให้ดูคือแคช opcode และการแคชแบบสแตติกแฟรกเมนต์ ... แต่ก่อนหน้านี้คุณต้องทำการเปรียบเทียบ heck จากมันและกำหนดว่าหน่วยความจำจะไปที่ใด WordPress เป็นสภาพแวดล้อมไม่ใช่คอขวดด้วยตัวเอง คอขวดอยู่ในสิ่งที่คุณทำ
Rarst

@ ครั้งแรกที่จริงฉันได้ทำมาตรฐานการใช้งาน CPU และฉันไม่สามารถระบุตำแหน่งใด ๆ ที่ทำให้เกิดปัญหาได้ คล้ายกับหน่วยความจำ - ดูเหมือนว่าจะกระจายไปทั่วสถานที่ อย่างไรก็ตามการเปรียบเทียบของฉันอาจทำไม่ได้ด้วยวิธีที่ดีที่สุด - ฉันใช้ XDebug profiler และ Cachegrind - มันค่อนข้างยากที่จะหยอกล้อเวลาแฝงเนื่องจากการเรียกฐานข้อมูล ฉันจะขอบคุณสำหรับพอยน์เตอร์ถึงเทคนิคการทำโปรไฟล์ที่ดีขึ้น
Roman Zenka

เพิ่มภาพหน้าจอ @Rarst Profiling แล้ว
Roman Zenka

4
อาจเป็นเพราะเซิร์ฟเวอร์ของ GoDaddy นั้นช้า พวกเขารู้จักกันดีว่าไม่มีฮาร์ดแวร์ที่ยอดเยี่ยมและจะ " จ่ายค่าโฆษณาทางโทรทัศน์มากกว่าอัพเกรดเซิร์ฟเวอร์ "
Zack

23

และนี่คือเหตุผลที่ฉันคิดว่า WordPress ต้องการการเขียนใหม่อย่างจริงจัง คุณไม่สามารถตำหนิการใช้หน่วยความจำในความซับซ้อนที่แท้จริงของสิ่งที่มันทำอีกต่อไป มันทำสิ่งผิดปกติ

สรุปไร้เดียงสาอะไร อ่านสิ่งที่คุณไม่ควรทำตอนที่ 1

ขอบคุณสำหรับแผนการใช้หน่วยความจำแม้ว่า

การแก้ไขในภายหลังมาก: Autommatic ได้เปิดตัวห้องสมุดชื่อpreforkที่ดูเหมือนว่าจะทำสิ่งที่คุณต้องการ: การโหลดรหัส WordPress ใน RAM เพียงครั้งเดียว


จริงมันไร้เดียงสา บางทีฉันควรจะพูดว่า "refactor" แทน "rewrite" จากนั้นฟังดูดีขึ้นมาก โพสต์อัพเดทแล้ว
Roman Zenka

2
ตกลงดีถ้าคุณมีข้อเสนอแนะเฉพาะ (โดยเฉพาะแพทช์) คุณสามารถโพสต์ไว้ใน trac: core.trac.wordpress.org
scribu

ฉันกำลังทำงานอยู่ในขณะนี้ ฉันพยายามพล็อตแผนที่ของวัตถุในหน่วยความจำดังนั้นฉันสามารถดูได้ว่ามีการใช้งานอะไรมาก มีเครื่องมือที่จะถ่ายโอนข้อมูลหน่วยความจำและพล็อตหรือไม่
Roman Zenka

5
@criu - +1 สำหรับลิงก์ไปยังโพสต์ของ Joel!
MikeSchinkel

1
OK เพียงแค่เก็บไว้ในใจว่า WP_Object_Cache สามารถถูกแทนที่ด้วยการดำเนินงาน ฯลฯ memcached
scribu

17

เริ่มต้นด้วย WordPress 3.2, PHP 5.2 จะเป็นข้อกำหนดขั้นต่ำ ฉันคิดว่าภายใต้เข็มขัดของเราบิตของแกนสามารถเริ่มปรับโครงสร้างและใช้คลาสที่มีการโหลดอัตโนมัติ สิ่งนี้จะช่วยให้เราหลีกเลี่ยงการโหลดโค้ดบางส่วนเว้นแต่จำเป็นต้องใช้จริง ตัวอย่างเช่นหากไม่มีการฝังหรือแกลเลอรี่ในการดูหน้าเว็บเราอาจหลีกเลี่ยงการโหลดรหัสสื่อจำนวนมากได้

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

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


@Dougal Campbell ฉันเริ่มตั้งคำถามกับคำถามนี้เพื่อดูว่าเราสามารถแฮ็คอย่างน้อยหนึ่งอินสแตนซ์ของ WordPress ที่แย่พอที่จะได้รับการปรับปรุงการใช้หน่วยความจำอย่างน้อย 30% ในตอนนี้หรือไม่ มันสามารถสร้างแรงบันดาลใจในการพัฒนาในอนาคต
Roman Zenka

การโหลดแบบมีเงื่อนไขในขณะที่อาจลดการใช้หน่วยความจำแบบมีเงื่อนไขจะทำให้ความเร็วในการแคช opcodeเกี่ยวข้องกัน เรามักจะชอบความเร็ว
scribu

ความคิดเพิ่มเติมเกี่ยวกับการโหลดอัตโนมัติ: stackoverflow.com/questions/4788452/…
scribu

@ Subsu เมื่อคุณพูดว่า "การโหลดตามเงื่อนไข" คุณกำลังพูดถึงการโหลดอัตโนมัติหรือการโหลดรหัสตามเงื่อนไขหรือไม่? มันเจ็บความเร็วแค่ไหน?
Roman Zenka

1
ขอขอบคุณ! อย่างที่ฉันบอกไปแล้วฉันไม่รู้ว่า Core WP จะใช้เส้นทางนั้นหรือไม่ แต่ฉันประทับใจมากกับความพยายามที่คุณวิเคราะห์สิ่งนี้และกราฟที่คุณสร้างขึ้น ดีแล้วทำต่อไป!
Dougal Campbell

16

เราจะทำให้ Wordpress เริ่มต้นสภาพแวดล้อมในหน่วยความจำเพียงครั้งเดียวแล้วนำมาใช้ซ้ำหลายครั้งสำหรับการเข้าชมแต่ละครั้งได้อย่างไร

มันเรียกว่า opcode-caching

http://en.wikipedia.org/wiki/PHP_accelerator


1
ฉันจะลอง APC และดูว่าเกิดอะไรขึ้น เมื่อตอนแรกที่ฉันถามคำถามนั้นฉันหมายถึงมากกว่าแค่ opcode caching - ฉันหมายถึงการนำสภาพแวดล้อมทั้งหมดที่ WordPress สร้างกลับมาใช้ใหม่ - รหัส + ข้อมูล Memcached จะช่วยให้คุณรับข้อมูลได้เร็วขึ้น แต่คุณจะยังคงทำการโคลนข้อมูลในหน่วยความจำเซิร์ฟเวอร์ ตอนนี้ดูเหมือนว่าการแคช opcode อาจดูแลประมาณ 90% ของการใช้หน่วยความจำทั้งหมด
Roman Zenka

หากคุณมีทรัพยากรสำหรับการทดลองบางอย่างคุณอาจลองตั้งค่าสภาพแวดล้อม FastCGI ฉันสนใจมากในการเปรียบเทียบระหว่าง mod_php และทำงานภายใต้ FastCGI
Dougal Campbell

5

คุณอาจจะไม่สามารถลดการใช้ RAM ได้มากนัก แต่ถ้าคุณใช้mod_phpคุณอาจเปลี่ยนไปmod_fcgidใช้แทน

ในขณะที่ mod_php ช้าลงเล็กน้อยมันจะโหลด php แม้ในขณะที่ไม่ต้องการเช่นการแสดงรูปภาพไฟล์คงที่หรือแม้แต่การแคช หากคุณมีคำขอจำนวนมากนี่คือ RAM จำนวนมาก

การใช้ fcgid จะช่วยลดสิ่งนี้ได้มาก

นอกจากนี้การใช้แคชแบบคงที่ (เช่นแคช w3total) จะหลีกเลี่ยงการเรียก php เลยซึ่งเป็นข้อได้เปรียบที่ยอดเยี่ยมมาก: การใช้ ram น้อยลงการเชื่อมต่อฐานข้อมูลน้อยลง


4

ฮ้า ผมทำงานใน app เว็บตอนนี้ที่ผมอย่างเต็มที่ตั้งใจจะเกินกับข้อมูลและการใช้งานเกินกว่าสิ่งที่บัญชีโฮสติ้งที่ใช้ร่วมกันของฉันสามารถจัดการดังนั้นฉันตัดสินใจ - ในขณะที่มันจะได้รับสุดง่ายที่จะสร้างใน WP - การพยายามทำงานจากBackPressเป็น กรอบและสร้างสิ่งที่ฉันต้องการสำหรับกรณีการใช้งานเฉพาะของฉัน

ดังนั้นฉันจึงสามารถลดสภาพแวดล้อมหลักของฉันจากไฟล์ PHP หลายร้อยไฟล์ใน WP เหลือเพียงยี่สิบหรืออย่างที่ฉันต้องการจริง ๆ ในขณะที่ยังสามารถใช้ db, HTTP, การจัดการผู้ใช้, การจัดรูปแบบและ cron ได้ทั้งหมด ฟังก์ชั่นที่ฉันชอบใน WordPress

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


1
ฉันยอมรับว่า WP ได้รับการปรับแต่งเป็นเวลานาน แต่ฉันไม่คิดว่ามันถูกปรับแต่งให้ทำงานกับโฮสติ้งเส็งเคร็งโดยมีส่วนผสมของปลั๊กอินที่เฉพาะเจาะจง ฉันอยากรู้ว่าฉันจะผลักมันไปได้ไกลแค่ไหน แม้ว่าการเปลี่ยนแปลงนั้นจะไม่ทำให้มันกลายเป็นแกนหลัก แต่ก็เป็นเรื่องที่ดีที่จะมีเอกสารเกี่ยวกับการแฮ็คแกนถ้าคุณคิดว่าคุณต้อง
Roman Zenka

3

ใช่ WordPress โหลดทุกอย่างก่อนแล้วจึงทำตามที่เราขอให้ทำ ฉันจำได้ว่าเราสามารถสร้างพูลเสมือนใน RAM ที่เราสามารถใส่ไฟล์ได้ ฉันมีความคิดที่จะนำเวิร์ดเพรสทั้งหมดลงในหน่วยความจำ (<10MB) จากนั้นเราสามารถบันทึก I / O จำนวนมากซึ่งควรเพิ่มความเร็วเพียงอย่างเดียว แต่ฉันไม่เคยมีโอกาสลองเลยและยิ่งกว่านั้นฉันไม่ได้มีความเชี่ยวชาญในการใฝ่หาอะไรแบบนั้น แต่มันก็คุ้มค่าที่จะลอง


และฉันเห็นด้วยกับ Rarst ในการใช้ปลั๊กอินแคชแบบสแตติกเพื่อไม่ให้มีการประมวลผลเลย แต่นั่นก็สามารถใช้ได้กับการเปลี่ยนแปลงที่ดีเช่นกัน :)
Ashfame

ฉันชอบความคิดนั้น ฉันไม่แน่ใจว่าปัญหานี้มีสาเหตุมาจากความล่าช้าของ I / O และเท่าไหร่เนื่องจาก PHP จะทำการเคี้ยวข้อมูลช้าๆ คุณรู้วิธีที่จะบอกได้อย่างไร?
Roman Zenka

ขออภัยเป็นเพียงความคิดในหัวของฉัน อาจไม่ส่งผลกระทบต่อประสิทธิภาพที่ดูเหมือนว่าโดยทั่วไปข้อมูลจะอ่านจากฮาร์ดดิสก์เป็นบล็อกดังนั้นข้อมูลอื่น ๆ ที่จำเป็นจำนวนมากอาจถูกดึงไปแล้ว ฉันก็ไม่แน่ใจเหมือนกัน
Ashfame

3

คำแนะนำพื้นฐานบางประการ:

  1. ปลั๊กอินแคช W3 ทั้งหมดสำหรับการแคช ..
  2. รับ memcache ที่ติดตั้งและเปิดใช้งานยังเปิดใช้งานจากการตั้งค่าแคชทั้งหมด w3 (แคช opcode เป็นตัวเลือกที่ดีเช่นกัน แต่ก็ไม่ได้ทำงานได้ดีกับปลั๊กอินแคชทั้งหมดของ w3)
  3. ลดการสืบค้นลงลิงก์โดยตรงในไฟล์ธีม ..
  4. ปิดใช้งานปลั๊กอินที่ไม่ได้ใช้งานทั้งหมดและนำออก
  5. ปรับฐานข้อมูลให้เหมาะสม

ฉันใช้งานเว็บไซต์ wordpress ที่รู้จักกันดีกับการเข้าชมจำนวนมากทุกวัน .. ฉันไม่ได้ทุ่มเทให้ทำเพื่อฉัน :)

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.