איטי לאחר ניקוי המטמון באתר

[tavenger5]

עברתי וליישם את כל הטריקים אופטימיזציה אפשרי אני יכול למצוא. זה כולל nginx כמו פרוקסי כדי Apache, vbOptimize עם memcached, וכל אופטימיזציה הנהלים הרגילים vBulletin.

אני עובד עם שני כפול ליבה לשרתים עם מעבד מרובע *** ו 12 של RAM, כונני SAS 15k בפשיטה. אז, במילים אחרות, השרתים יש מספיק כוח כדי תהליך הכל.

האתר העיקרי מתחיל להאט מיד אחרי המטמון vBET מנוקה כל 15 ימים. (מסד נתונים מגיע קצת יותר *** לאחר תקופת 15 היום)> 500k עמודים ביום הם נסרק על ידי מנועי החיפוש.

האם יש משהו שאני יכול לעשות כדי לצבוט Apache על מטפל בבקשות הללו טוב יותר? אלו ההגדרות הנוכחיות שלי apache:
מ mpm.conf-httpd
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000

מ default.conf-httpd:

Timeout 150
משך חיים ב
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName כבוי

[vBET]

תן לי לנחש - יש לך vBSEO והרבה קישורים בדף הראשי - אני צודק?

הטריק הוא - אם אתה לא באמת צריך, אז לא להשתמש באסטרטגיה הסליקה האחרון. אני יודע שיש אם - האם בדקת אסטרטגיות ניקוי אחרים? אחרים לא לנקות את המטמון כולו יקח יותר משאבים ברור מן הצד השני.

הבא לשחרר vBET 3.x יכול לעזור לך - נוסיף פרמטרים חדשים ביצועים מתקדמים עבור דפי הגדולים באמת. גילינו גם צוואר בקבוק עם תרגום קישורים. ברגע זה יישמנו פתרון כתובות vB ידידותי vBET4.x (לא שוחרר עדיין) ואנחנו ננסה לאמץ אותה גם עבור vBSEO. אם נצליח נעבור את זה גם vBET 3.x העניין הוא vBSEO מבקש קישורים אחד אחד וזה מייצר עשרות בקשות של גוגל. כפי שכתבתי כבר יישמנו פתרון כתובות Frinedly vB - עשינו התרגום מתעכב. בעיה עם vBSEO היא שזה עובד מחוץ VB, לאחר התרגום קורה וגם לא אומרים אינו צריך כתובת כדי לבדוק תקינות של אחד בפועל
או לשים את זה הפלט.
הרבה פרטים - בקרוב אנחנו מכירים זה את צוואר הבקבוק וזה קורה רק כאשר המטמון לא מתמלא ואנחנו כבר עובדים על הנושא הזה.

אז ברגע זה אני יכול רק לייעץ לך לשחק עם אסטרטגיות ניקוי ופרמטרים ניקוי אחרים. עבור אסטרטגיות אחרות:
- אם ניקוי זיכרון מטמון של שולחן אחד לא הורג את השרת, ולאחר מכן הגדר גדול "מטמון ניקוי timelap" - השרת יהיה לקחת נשימה בין קרחות
- Analise תנועה בפורום שלך לבדוק כאשר הוא פחות - ניקוי לשנות ביצוע לעת הזאת
- בחר מטמון TTL נמוך - שולחנות קטנים תימחק כך הסליקה עצמו ייקח פחות משאבים. לוואי אחרות - שרת תצטרך לשאול Google לעתים קרובות יותר לתרגומים.
- ניסיונית: להגדיר "מחיקה מהירה המקומית עם שולחנות לייעל" פתוח / כולל / vbenterprisetranslator_functions.php ולהעיר יש 3 שורות של קוד עם "מיטוב לוח LOCAL". זה יגרום למחיקה ממש מהר מבלי לשדרג את האינדקסים. הערה: אינדקסים יגדל, כך יהיה לך לבצע את השאילתה באופן ידני - כלומר לבדוק את זה פעם אחת בשבוע. אם זה יעבוד בשבילך נוכל ליישם אסטרטגיה חדשה, שם אינדקסים יהיה לא בכל יום מחדש.

[tavenger5]

על כן vBSEO.

אני משתמש המחיקה נורמלי כרגע, זה לא נראה לקחת זמן רב מדי כדי לקבל דברים התבהרו. עם המחיקה המקומי מהיר הם אינדקסים שמאל טקט, ואת המדדים המחיקה נורמלי נמחקים? האם יש צורך אינדקסים ישנים כל תועלת אם הם לא מותאמים?

דברים רק נראה להאט כשיש הרבה תנועה באתר ו המטמון הוא נבנה מחדש. אני בטוח שזה בגלל תהליכים apache לא נסגרים מהר ככל שהם כרגיל (שכן הנתונים המבוקש מ-Google).

זה טוב לשמוע את הגירסה הבאה ישפרו את המהירות שוב. אני רק מוודא שלא היה שום דבר אחר שאני יכול לעשות עם apache tweaking.

[vBET]

אם אתה משתמש ניקוי רגילים ואז שכח רמזים שלי. חשבתי שאתה משתמש האסטרטגיה האחרונה ולהסיר את המטמון כולו. מצטער - אי הבנה פשוט להשאיר אותו כפי שהוא.

באופן כזה אני יכול לייעץ להגדיר TTL מטמון גדול יותר. נתונים פחות יוסרו כל הזמן, כך פחות נתונים יהיה לשחזר.
כפי שכתבתי כבר מצאנו צוואר בקבוק אחד עם vBSEO + מטמון ריק ואנחנו עובדים על זה

מה אתה גם יכול לעשות הוא לוודא כי השרת אינו מחזיק בקשות יוצאות. גילינו כי שרתי מסוימים מתנהגים כמו זה אם בקשות יוצאות רבים הולכים לשרת אותו. כי 100 בקשות יכול לקחת זמן 1000 x יותר מ 1 בקשה (תיאורטית צריך לקחת את הזמן 100 x יותר). זה יכול להיות קצת, חומת אש בשרת בעיית אבטחה. כמובן שזה יכול להיות שגוגל מכניס קצת "עונש" קטן במקרה כזה. אז אם אתה יכול למצוא משהו בתחום זה - זה יכול לעזור. אם לא אנא המתן לשיפורים