קרב שרתי WEB. חלק 2 - תרחיש HTTPS מציאותי:

דיברנו על המתודולוגיה ב החלק הראשון במאמר זה, אנו בודקים HTTPS, אך בתרחישים מציאותיים יותר. לבדיקה, השגנו אישור Let's Encrypt ואפשרנו את דחיסת Brotli ל-11.

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

• 25% - מה שמקביל לתדר של ~ 1350 מגה-הרץ
• 35% -1890 מגה-הרץ
• 41% - 2214 מגה-הרץ
• 65% - 3510 מגה-הרץ

מספר החיבורים החד-פעמיים הצטמצם מ-500 ל-1, 3, 5, 7 ו-9,

תוצאות:

עיכובים:

TTFB נכלל במיוחד כבדיקה נפרדת, מכיוון שכלי HTTPD יוצרים משתמש חדש עבור כל בקשה בודדת. המבחן הזה עדיין די מנותק מהמציאות, מכיוון שהמשתמש עדיין ילחץ על כמה עמודים, ובמציאות TTFP ישחק את התפקיד הראשי.

הבקשה הראשונה, בדרך כלל, הבקשה הראשונה לאחר ההפעלה הראשונה של המחשב הוירטואלי של IIS נמשכת בממוצע 120 אלפיות השנייה.

כל הבקשות הבאות מציגות TTFP של 1.5 אלפיות השנייה. Apache ו-Nginx מפגרים מאחור בהקשר זה. באופן אישי, המחבר מחשיב את המבחן הזה כחושפני ביותר והיה בוחר את הזוכה רק על סמך זה.
התוצאה אינה מפתיעה שכן מטמון IIS כבר דחוס תוכן סטטי ואינו דוחס אותו בכל פעם שניגשים אליו.

זמן בילוי לכל לקוח

כדי להעריך ביצועים, מספיקה בדיקה עם חיבור בודד אחד.
לדוגמה, IIS השלים בדיקה של 5000 משתמשים תוך 40 שניות, שהם 123 בקשות לשנייה.

הגרפים למטה מציגים את הזמן עד שתוכן האתר מועבר במלואו. זהו שיעור הבקשות שהושלמו בזמן נתון. במקרה שלנו, 80% מכל הבקשות טופלו ב-8ms ב-IIS וב-4.5ms ב-Apache ו-Nginx, ו-8% מכל הבקשות ב-Apache וב-Nginx הושלמו במרווח של עד 98 מילישניות.

זמן שבו טופלו 5000 בקשות:

זמן שבו טופלו 5000 בקשות:

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

כשמדובר במצב קצת יותר מציאותי, כל שרתי האינטרנט הולכים ראש בראש.

תפוקה:

גרף של עיכובים לעומת מספר החיבורים בו זמנית. יותר חלק ונמוך יותר עדיף. 2% האחרונים הוסרו מהתרשימים מכיוון שהם יהפכו אותם לבלתי קריאים.

כעת נבחן את האפשרות שבה השרת מתארח באחסון וירטואלי. ניקח 4 ליבות במהירות 2.2 גיגה-הרץ וליבה אחת במהירות 1.8 גיגה-הרץ.

איך מדרגים

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

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

כדי לעשות זאת, ניקח את מחוון הבקשות לשנייה (RPR). אופקי הוא התדר, אנכי הוא מספר הבקשות המעובדות בשנייה, קווים הם מספר הליבות.

מראה מתאם עד כמה Nginx מעבד בקשות בזו אחר זו. 8 ליבות מתפקדות טוב יותר במבחן זה.

הגרף הזה מראה בבירור כמה טוב יותר (לא הרבה) Nginx עובד על ליבה אחת. אם יש לך Nginx, כדאי לשקול לצמצם את מספר הליבות לאחת אם אתה מארח רק סטטיות.

IIS, למרות שיש לו את ה-TTFB הנמוך ביותר לפי DevTools בכרום, מצליח להפסיד גם ל-Nginx וגם ל-Apache בקרב רציני עם מבחן המאמץ של קרן Apache.

כל העקמומיות של הגרפים משוחזרות בציפוי ברזל.

סוג של מסקנה:

כן, Apache עובד גרוע יותר על 1 ו-8 ליבות, אבל עובד קצת יותר טוב על 4.

כן, Nginx על 8 ליבות מעבד בקשות טוב יותר בזה אחר זה, על 1 ו-4 ליבות, ועובד גרוע יותר כשיש הרבה חיבורים.

כן, IIS מעדיף 4 ליבות עבור עומסי עבודה מרובי הליכי ומעדיפים 8 ליבות עבור עומסי עבודה עם חוטים בודדים. בסופו של דבר, IIS היה מעט מהיר יותר מכולם על 8 ליבות בעומס גבוה, למרות שכל השרתים היו בשוויון.

זו לא שגיאת מדידה, השגיאה כאן היא לא יותר מ-+-1ms. באיחורים ולא יותר מ-+- 2-3 בקשות לשנייה עבור RPR.

התוצאות שבהן 8 ליבות מתפקדות גרוע יותר אינן מפתיעות כלל, ליבות רבות ו-SMT/Hyperthreading פוגעות מאוד בביצועים אם יש לנו מסגרת זמן שבה עלינו להשלים את כל הצינור.

מקור: www.habr.com