เว็บไซต์ช้าหลังจากการล้างแคช

[tavenger5]

ผมเคยผ่านไปแล้วและดำเนินการทั้งหมดเทคนิคการเพิ่มประสิทธิภาพที่เป็นไปได้ฉันสามารถหา ซึ่งรวมถึง Nginx เป็น proxy เพื่อ Apache, vbOptimize กับ memcached, และทุกขั้นตอนปกติ vBulletin การเพิ่มประสิทธิภาพ

ผมทำงานกับ Quad - core สองเซิร์ฟเวอร์ที่ใช้โปรเซสเซอร์คู่กับ 12 และ *** ของ RAM และไดรฟ์ SAS 15k ในการโจมตี ดังนั้นในคำอื่น ๆ เซิร์ฟเวอร์ที่มีอำนาจพอที่จะดำเนินการทุกอย่าง

เว็บไซต์หลักเริ่มชะลอตัวขวาหลังจากที่แคชจะถูกล้าง vBET ทุก 15 วันที่ผ่านมา (ฐานข้อมูลที่ได้รับไปเพียงกว่า *** หลังจากนี้ระยะเวลา 15 วัน)> 500K หน้าวันที่มีการรวบรวมข้อมูลโดยเครื่องมือค้นหา

มีอะไรที่ฉันสามารถทำเพื่อปรับแต่ง Apache เพื่อการจัดการการร้องขอเหล่านี้ดีขึ้นหรือไม่ เหล่านี้มีการตั้งค่าปัจจุบันของฉัน Apache :
จาก httpd - mpm.conf
MPM # prefork

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
1000 MaxRequestsPerChild
จาก httpd default.conf :

150 หมดเวลา
KeepAlive เกี่ยวกับ
MaxKeepAliveRequests 80
3 KeepAliveTimeout
UseCanonicalName ปิด

[vBET]

ให้ฉันเดา -- คุณมีภาษาไทยและจำนวนมากของการเชื่อมโยงในหน้าหลัก -- ฉันขวา? ;)

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

ถัดไปปล่อย vBET 3.x สามารถช่วยให้คุณ -- เราจะเพิ่มพารามิเตอร์ใหม่ที่มีประสิทธิภาพสูงสำหรับหน้าเว็บที่ใหญ่จริงๆ นอกจากนี้เรายังพบคอขวดกับการแปลการเชื่อมโยง ขณะนี้เราได้ดำเนินการแก้ปัญหาสำหรับ URL ที่เป็นมิตร VB ใน vBET4.x (ไม่ออกยัง) และเราจะพยายามที่จะนำมาใช้สำหรับนโยบายส่วนบุคคล ถ้าเราประสบความสำเร็จเราจะย้ายมันไปยัง vBET 3.x ปัญหาก็คือภาษาไทยขอให้สำหรับการเชื่อมโยงหนึ่งโดยหนึ่งและนี้ผลิตนับสิบของการร้องขอของ Google ที่ฉันเขียนที่เราดำเนินการอยู่แล้ววิธีการแก้ปัญหาสำหรับ URL vB Frinedly -- การแปลภาษาที่เราทำล่าช้า มีปัญหากับภาษาไทยเป็นที่ทำงานนอก VB, หลังจากการแปลที่เกิดขึ้นและยังไม่ได้บอกไม่ต้องการ URL เพื่อตรวจสอบความถูกต้องของจริงอย่างใดอย่างหนึ่ง
หรือจะนำมันในการส่งออก
มากรายละเอียด -- ในไม่ช้าเรารู้ว่าหนึ่งในคอขวดที่เกิดขึ้นเฉพาะเมื่อแคชไม่เต็มและเรามีอยู่แล้วทำงานเกี่ยวกับปัญหานี้

ดังนั้นขณะนี้ฉันสามารถขอแนะนำให้คุณเล่นกับกลยุทธ์การล้างและพารามิเตอร์อื่น ๆ สำนักหักบัญชี สำหรับกลยุทธ์การอื่น ๆ :
-- หากการล้างแคชของตารางหนึ่งจะไม่ฆ่าเซิร์ฟเวอร์ของคุณแล้วชุดใหญ่'การล้างข้อมูลแคช timelap'-- เซิร์ฟเวอร์ของคุณจะนำลมหายใจระหว่าง clearings
-- การจราจร Analise ฟอรั่มของคุณและตรวจสอบเมื่อมีน้อย -- การดำเนินการล้างการเปลี่ยนแปลงในครั้งนี้
-- ตั้งค่าแคช TTL ต่ำ -- ตารางที่มีขนาดเล็กจะถูกล้างเพื่อล้างตัวเองจะใช้ทรัพยากรน้อย ด้านอื่น ๆ -- เซิร์ฟเวอร์จะต้องถาม Google บ่อยสำหรับการแปล
-- การทดลอง : ตั้ง'การลบท้องถิ่นด่วนกับตารางการเพิ่มประสิทธิภาพ'เปิด / รวม vbenterprisetranslator_functions.php / และแสดงความคิดเห็นมี 3 บรรทัดของรหัสกับ'ตารางท้องถิ่นเพิ่มประสิทธิภาพ' นี้จะทำให้การลบอย่างรวดเร็วจริงๆโดยไม่ต้องอัพเกรดดัชนี หมายเหตุ : ดัชนีจะเติบโตดังนั้นคุณจะมีการดำเนินการแบบสอบถามด้วยตนเอง -- คือตรวจสอบครั้งต่อสัปดาห์ ถ้ามันจะทำงานให้คุณเราจะใช้กลยุทธ์ใหม่ที่ดัชนีจะปรับโครงสร้างไม่ได้ทุกวัน

[tavenger5]

ใช่เกี่ยวกับภาษาไทย

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

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

เป็นเรื่องที่ดีที่ทราบว่ารุ่นถัดไปจะปรับปรุงในความเร็วอีกครั้ง ผมเพียงแค่ให้แน่ใจว่ามีไม่อะไรอีกที่ฉันสามารถทำกับ apache tweaking

[vBET]

ถ้าคุณกำลังใช้การล้างปกติแล้วลืมเกี่ยวกับคำแนะนำของฉัน ผมคิดว่าคุณกำลังใช้กลยุทธ์ล่าสุดและลบแคชทั้ง ขออภัย -- ความเข้าใจผิด :) เพียงแค่ปล่อยให้มันเป็นมันเป็น

ในลักษณะดังกล่าวก็สามารถให้คำแนะนำเพื่อตั้งค่าแคช TTL ใหญ่ ข้อมูลน้อยกว่าจะถูกลบออกในแต่ละครั้งเพื่อให้ข้อมูลน้อยจะสามารถกู้คืน
ที่ฉันเขียนเราแล้วพบว่าหนึ่งในคอขวดที่มีภาษาไทย + แคชว่างเปล่าและเราจะทำงานกับมัน :)

สิ่งที่คุณยังสามารถทำคือตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ของคุณไม่ได้เป็นผู้ถือหุ้นร้องขอขาออก เราค้นพบว่าเซิร์ฟเวอร์บางประพฤติเช่นนี้หากการร้องขอออกจำนวนมากจะไปเซิร์ฟเวอร์เดียวกัน เนื่องจาก 100 การร้องขอสามารถใช้เวลา 1000 x มากกว่า 1 คำขอ (ในทางทฤษฎีควรใช้เวลา 100 x มากกว่า) มันสามารถจะมีบางไฟร์วอลล์, ปัญหาความปลอดภัยของเซิร์ฟเวอร์ แน่นอนมันสามารถที่ Google ทำให้บาง'ลงโทษ'เล็ก ๆ น้อย ๆ ในกรณีดังกล่าว ดังนั้นหากคุณสามารถหาสิ่งที่อยู่ในบริเวณนี้ -- มันสามารถช่วยให้ ถ้าไม่โปรดรอสักครู่สำหรับการปรับปรุง :)