Pre-Warming Magento Enterprise Full Cache แคช

ประโยชน์ด้านประสิทธิภาพของแคชแบบเต็มหน้าใน Magento Enterprise นั้นเป็นที่รู้จักกันดี สิ่งที่อาจไม่ค่อยเป็นที่รู้จักกันดีก็คือเพื่อให้เกิดประโยชน์เต็มที่ในการรับรู้สิ่งนี้จะต้องมีประชากรเต็มและร้อนโดยเฉพาะอย่างยิ่งในชุดผลิตภัณฑ์ขนาดใหญ่ที่คุณไม่มีหน้ากระดาษเพียงไม่กี่หน้า นายกมันเร็วพอ

วีโอไอพีรวมถึง cronjob ในตัวเพื่อคลานไซต์และทำให้ FPC อุ่นขึ้นในตอนเช้า

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

• รวบรวมเชลล์สคริปต์เพื่อรวบรวมข้อมูลทุกหน้าในไฟล์แผนผังไซต์ที่สร้างขึ้น
• ใช้รายการ crontab แยกต่างหากและสคริปต์ PHP สั้น ๆ เพื่อ bootstrap Magento และดำเนินการกระบวนการรวบรวมข้อมูลโดยตรง

ความคิดและ / หรือประสบการณ์เกี่ยวกับเรื่องนี้ยินดีต้อนรับ!

คุณสามารถใช้ล้อมร่วมกับsitemap.xmlไฟล์เช่นMageSpeedTestไม่

#categories
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
#products
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1.0 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' >> urls.txt

จากนั้นเรียกใช้

siege -i -c 1 -t 7200s -f urls.txt

^{เนื้อหาที่มาจากที่นี่}

เราแค่ทำไม่ได้เลย เคย เราจะพูดแบบนี้ซ้ำแล้วซ้ำอีก แต่

การแคช! = ประสิทธิภาพ

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

ในร้านค้าที่ไม่มีการโหลดเวลาโหลดหน้าเว็บด้วย FPC ไม่ควรจะน่าประทับใจไปกว่าการที่ไม่ใช่ FPC วีโอไอพีมีความสามารถในการ< 400msโหลดหน้าในแคชมาตรฐานได้อย่างมีความสุข(ในหมวดหมู่ / ผลิตภัณฑ์ / หน้าการค้นหา) FPC จะนำสิ่งนั้นลงไป< 80ms- แต่มาพร้อมกับคำเตือน

1. ข้อมูลหุ้น / ราคาล้าสมัยจนกว่าการตรวจสอบความถูกต้องหรือหมดอายุของ TTL

2. รายการใหม่ / การค้นหาที่เกี่ยวข้องเพิ่มเติมล้าสมัยจนกว่าการตรวจสอบความถูกต้องหรือหมดอายุ TTL

   เป็นต้น

เหตุใดการพึ่งพา FPC (หรือวานิช) จึงเป็นความคิดที่ไม่ดี

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

1. คุณไม่มีฝีเท้าตามธรรมชาติเพียงพอที่จะเก็บแคชไว้ในพื้น(ดูที่ 'FPC มีประโยชน์ที่ไหน')
2. เว็บไซต์ของคุณช้าเกินไปหากไม่มีพวกเขา

คุณไม่สามารถแคชทุกอย่าง

หากคุณใช้ร้านค้าที่มีเพียง 5 หมวดหมู่คุณสามารถกรองแอททริบิวต์ที่กรองได้ 2 ระดับ 5 ระดับตัวเลือกแอททริบิว 5 รายการแต่ละผลิตภัณฑ์และ 1,000 รายการ; ที่มีเป็นจำนวนมากรวมกันได้

25 ตัวเลือกให้เลือกโดยเลือกหนึ่งครั้งถึง 5 ครั้งติดต่อกัน - ฉันไม่มีสถิติแต่ฉันรู้ว่านั่นคือ ... (สมมติว่าจำนวนตัวเลือกแอตทริบิวต์ไม่ลดลงอย่างสมบูรณ์)

25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5  possible URLs on the fifth selection

5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)

ตกลงข้างต้นไม่ได้เป็นสถานการณ์ที่น่าจะเป็นอย่างที่ฉันคิดว่าภายใน 3 คลิก - จำนวนของผลิตภัณฑ์ที่มีอยู่จะลดลงอย่างเพียงพอสำหรับลูกค้าในการค้นหาผลิตภัณฑ์ของพวกเขา ดังนั้นแม้ว่ามันจะเป็น ...

25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection

5^3 = 125 possible URL combinations 

จากนั้นคูณด้วย 5 หมวดหมู่นั่นคือ 625 URL ในขั้นตอนนี้เรากำลังพูดถึงแคตตาล็อกขนาดเล็กและไม่สนใจ URL ผลิตภัณฑ์ทั้งหมดอย่างสมบูรณ์

นอกจากนี้เรายังไม่แยกตัวประกอบว่าหากคุณมีหมวดหมู่ที่ซ้อนกันด้วยis_anchorบนจะมีการเพิ่มขึ้นแบบทวีคูณ

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

หากหน้าเว็บของคุณมีเวลาในการโหลดหน้าเว็บ 0.4 วินาทีและคุณมีซีพียู 8 คอร์ - จากนั้น ...

625 * 0.4 = 250 / 8 = 31 seconds

0.5 นาทีไม่เลว - แต่ลองจินตนาการว่าคุณมีเวลาในการโหลดหน้าเว็บ 2 วินาที

625 * 2 = 1250 / 8 = 156 seconds

แต่ถ้าคุณเอาสถานการณ์ที่เป็นไปได้สูงสุด

3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes

นั่นคือเซิร์ฟเวอร์ที่ใช้งานจริงของคุณภายใต้โหลด CPU 100% เป็นเวลา 15 นาที คุณจะลดความเร็วการรวบรวมข้อมูลให้เป็นสัดส่วนกับ TTL ที่คุณต้องการ

ดังนั้นหากคุณต้องการให้เนื้อหามี 3600s TTL การรวบรวมข้อมูลอาจช้าลง 4 เท่านั่นคือ CPU เพียง 25% เท่านั้นที่ทุ่มเทให้กับการรวบรวมข้อมูล นั่นเป็นทรัพยากรจำนวนมากเพียงเพื่อรักษาเนื้อหาหมวดหมู่ไว้ให้พร้อม - เรายังไม่ได้รวมอยู่ในผลิตภัณฑ์คำค้นหาหรือมุมมองร้านค้าเพิ่มเติมในขั้นตอนนี้

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

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

FPC มีประโยชน์ที่ไหน

ที่ซึ่งผลประโยชน์ของ FPC เข้ามาเล่นอยู่ในร้านค้าที่มีการโหลดหนาแน่น - ซึ่งคุณมีปริมาณการใช้งานสูงและแท้จริงแคชนั้นเป็นธรรมชาติ

จากนั้น FPC ก็เข้าสู่การเล่นโดยการลดค่าโสหุ้ยโครงสร้างพื้นฐานสำหรับเนื้อหาที่ต้องการโดยทั่วไป - ลดการเรียกซ้ำไปที่แบ็กเอนด์ Magento

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

ใครสนใจฉันยังคงต้องการรวบรวมข้อมูล

ถ้าอย่างนั้นคุณมีสองทางเลือก

1. รวบรวมข้อมูลจากเทมเพลต (เช่น sitemap)
2. แยกลิงก์ทีละหน้าและรวบรวมข้อมูลแต่ละอัน

และมีสาธารณูปโภคหลายอย่างให้ทำทั้งสองอย่างนี่คือสิ่งที่ฉันรู้

1. ผู้วิเศษ-perftest
2. HTTrack
3. นัทช์
4. Sphider
5. Crawler4j

ใช้ Mage-Perftest

คุณสามารถรวบรวมข้อมูลร้านค้าของคุณด้วย Mage-Perftest ได้อย่างง่ายดายดาวน์โหลดได้ครั้งแรก

wget http://sys.sonassi.com/mage-perftest          (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386     (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*

จากนั้นกำหนดกระบวนการรวบรวมข้อมูลโดยใช้แผนผังเว็บไซต์วีโอไอพี (คุณสามารถปรับแต่งสิ่งนี้ได้โดยสร้างแผนผังไซต์ของ URL ใด ๆ โดยที่ URL ถูกห่อด้วย<loc></loc>แท็ก) คำสั่งต่อไปนี้จะอ่าน URL ทั้งหมดจากไฟล์ sitemap จากนั้นรวบรวมข้อมูล (PHP เท่านั้น) URL ในช่วงเวลา 1440 นาที (1 วัน) หากเซิร์ฟเวอร์เกิน 20% CPU หรือโหลดเฉลี่ย 2 - การรวบรวมข้อมูลจะหยุดชั่วคราว

./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2  

หากคุณมี 1,000 URL จะถูกรวบรวมข้อมูลเกิน 1 วันซึ่งจะมีค่าประมาณ 1 คำขอทุก ๆ 86 วินาที ~ เป้าหมาย 0.011 RPS

ฉันจะบันทึกพูดจาโผงผางเต็มรูปแบบของฉันสำหรับโพสต์บล็อกหนึ่งวันนี้ wfpcแต่ในขณะเดียวกันมีสูงสุดที่อากาศอบอุ่นแคชน้อยของฉัน

การทดสอบประสิทธิภาพ

คุณสามารถทดสอบประสิทธิภาพของเว็บไซต์ Magento ของคุณ

./wfpc -t http://mymagentosite.com/sitemap.xml

Finished testing your Magento site performance
Total download time (in seconds)   : 5.0269110202789
Total download time (formatted)    : 0:0:5.026
Average page time (in milliseconds): 502.69110202789

FPC ภาวะโลกร้อน

และคุณสามารถอุ่น FPC ได้ซึ่งจะมีผลกับ URL ทุกรายการใน sitemap.xml

./wfpc -w http://mymagentosite.com/sitemap.xml

นอกจากนี้คุณยังสามารถหน่วงเวลาระหว่างคำขอได้หากต้องการนี่คือความล่าช้า 1 วินาทีระหว่างคำขอ

./wfpc -w -d=1 http://mymagentosite.com/sitemap.xml

โหมดทดสอบจะมีเพียง 10 URL ที่สุ่มเท่านั้นดังนั้นเมื่อคุณอุ่น FPC ของคุณแล้วคุณสามารถเรียกใช้โหมดทดสอบเพื่อดูว่า FPC แตกต่างกันมากแค่ไหน!

ความคิด

โดยส่วนตัวแล้วฉันคิดว่าตัวอุ่นกว่าเหมาะสม ... ในไซต์เล็ก ๆ ที่มีหน้าประมาณ 40 หน้าเวลาดาวน์โหลดจะถูกตัดประมาณครึ่งหนึ่งโดย FPC ในไซต์ขนาดใหญ่ที่มีผลิตภัณฑ์เกือบ 40,000 รายการที่ใช้ Lesti_FPC กับ APCu เป็นแบ็กเอนด์ฉันใช้แคชน้อยกว่า 200MB สำหรับแคชซึ่งไม่มีอะไรในเซิร์ฟเวอร์การผลิต 8GB