יישומי אינטרנט נמצאים כעת בשימוש בכל מקום, ובין כל פרוטוקולי התחבורה, HTTP תופס את חלקו הארי. כאשר לומדים את הניואנסים של פיתוח אפליקציות אינטרנט, רוב האנשים מקדישים מעט מאוד תשומת לב למערכת ההפעלה שבה יישומים אלו פועלים בפועל. ההפרדה בין פיתוח (Dev) לבין פעולות (Ops) רק החמירה את המצב. אבל עם עליית תרבות ה-DevOps, מפתחים הופכים להיות אחראים על הפעלת האפליקציות שלהם בענן, כך שמאוד שימושי עבורם להכיר לעומק את הקצה האחורי של מערכת ההפעלה. זה שימושי במיוחד אם אתה מנסה לפרוס מערכת עבור אלפי או עשרות אלפי חיבורים בו זמנית.

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

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

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

אמנם אתה יכול להשתמש בידע הזה כדי לבנות אפליקציה מאפס והיא תעבור אופטימיזציה מושלמת, אבל עדיף לא לעשות זאת. אם אתה כותב שרת אינטרנט חדש ב-C או C++ עבור היישום העסקי של הארגון שלך, זה עשוי להיות היום האחרון שלך בעבודה. עם זאת, הכרת המבנה של יישומים אלה תעזור בבחירת תוכניות קיימות. תוכל להשוות בין מערכות מבוססות תהליכים למערכות מבוססות פתיל וכן למערכות מבוססות אירועים. אתה תבין ותעריך מדוע Nginx מתפקד טוב יותר מאשר Apache httpd, מדוע יישום Python מבוסס Tornado יכול לשרת יותר משתמשים בהשוואה ליישום Python מבוסס Django.

ZeroHTTPd: כלי למידה

ZeroHTTPd הוא שרת אינטרנט שכתבתי מאפס ב-C ככלי הוראה. אין לו תלות חיצונית, כולל גישה ל-Redis. אנו מנהלים את נהלי Redis משלנו. ראה למטה לפרטים נוספים.

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

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

דף הבית של ZeroHTTPd. זה יכול להפיק סוגי קבצים שונים כולל תמונות

יישום ספר אורחים

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

אפליקציית אינטרנט "ספר אורחים" ZeroHTTPd

דלפק המבקרים ורשומות ספר האורחים מאוחסנים ברדיס. עבור תקשורת עם Redis, נהלים משלו מיושמים; הם אינם תלויים בספרייה החיצונית. אני לא מעריץ גדול של הפעלת קוד ביתי כשיש פתרונות זמינים לציבור ובדוקים היטב. אבל המטרה של ZeroHTTPd היא ללמוד את ביצועי לינוקס וגישה לשירותים חיצוניים, בעוד שלשרת בקשות HTTP יש השפעה רצינית על ביצועים. עלינו לשלוט באופן מלא בתקשורת עם Redis בכל אחת מארכיטקטורות השרתים שלנו. בארכיטקטורות מסוימות אנו משתמשים בשיחות חסימה, באחרות אנו משתמשים בפרוצדורות מבוססות אירועים. שימוש בספריית לקוח חיצונית של Redis לא יספק שליטה זו. בנוסף, לקוח Redis הקטן שלנו מבצע רק כמה פונקציות (קבלה, הגדרה והגדלה של מפתח; קבלת והוספה למערך). בנוסף, פרוטוקול Redis אלגנטי ופשוט במיוחד. אתה אפילו לא צריך ללמד את זה במיוחד. עצם העובדה שהפרוטוקול עושה את כל העבודה בכמאה שורות קוד מראה עד כמה הוא מחושב.

האיור הבא מראה מה האפליקציה עושה כאשר הלקוח (הדפדפן) מבקש /guestbookURL.

כיצד פועלת אפליקציית ספר האורחים

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

ארכיטקטורות שרת ZeroHTTPd

אנו בונים שבע גרסאות של ZeroHTTPd עם אותה פונקציונליות אך עם ארכיטקטורות שונות:

• איטרטיבי
• שרת מזלג (תהליך ילד אחד לכל בקשה)
• שרת טרום-מזלג (קדם-מזלג תהליכים)
• שרת עם שרשורי ביצוע (שרשור אחד לכל בקשה)
• שרת עם יצירת שרשורים מראש
• מבוסס אדריכלות poll()
• מבוסס אדריכלות epoll

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

מתודולוגיית בדיקה

הגדרת בדיקת עומס ZeroHTTPd

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

מה עושה כל אחד מהשרתים האלה?

• load.unixism.net: זה המקום שבו אנחנו רצים ab, כלי השירות Apache Benchmark. זה מייצר את העומס הדרוש לבדיקת ארכיטקטורות השרת שלנו.
• nginx.unixism.net: לפעמים אנחנו רוצים להפעיל יותר ממופע אחד של תוכנית שרת. לשם כך, שרת Nginx עם ההגדרות המתאימות פועל כמאזן עומסים שמגיע ממנו ab לתהליכי השרת שלנו.
• zerohttpd.unixism.net: כאן אנו מריצים את תוכניות השרת שלנו בשבע ארכיטקטורות שונות, אחת בכל פעם.
• redis.unixism.net: שרת זה מריץ את הדמון Redis, שבו מאוחסנים רשומות ספר אורחים ומונה מבקרים.

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

מה אנחנו מודדים?

אתה יכול למדוד אינדיקטורים שונים. אנו מעריכים את הביצועים של כל ארכיטקטורה בתצורה נתונה על ידי טעינת השרתים בבקשות ברמות שונות של מקביליות: העומס גדל מ-20 ל-15 משתמשים במקביל.

תוצאות הבדיקה

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

להלן טבלה עם התוצאות.

בקשות לשנייה

במקביל
איטרטיבי
מזלג
מראש מזלג
נְהִירָה
סטרימינג מראש
בו
אפול

20
7
112
2100
1800
2250
1900
2050

50
7
190
2200
1700
2200
2000
2000

100
7
245
2200
1700
2200
2150
2100

200
7
330
2300
1750
2300
2200
2100

300
-
380
2200
1800
2400
2250
2150

400
-
410
2200
1750
2600
2000
2000

500
-
440
2300
1850
2700
1900
2212

600
-
460
2400
1800
2500
1700
2519

700
-
460
2400
1600
2490
1550
2607

800
-
460
2400
1600
2540
1400
2553

900
-
460
2300
1600
2472
1200
2567

1000
-
475
2300
1700
2485
1150
2439

1500
-
490
2400
1550
2620
900
2479

2000
-
350
2400
1400
2396
550
2200

2500
-
280
2100
1300
2453
490
2262

3000
-
280
1900
1250
2502
התפשטות גדולה
2138

5000
-
התפשטות גדולה
1600
1100
2519
-
2235

8000
-
-
1200
התפשטות גדולה
2451
-
2100

10
-
-
התפשטות גדולה
-
2200
-
2200

11
-
-
-
-
2200
-
2122

12
-
-
-
-
970
-
1958

13
-
-
-
-
730
-
1897

14
-
-
-
-
590
-
1466

15
-
-
-
-
532
-
1281

מהגרף ומהטבלה ניתן לראות שמעל 8000 בקשות בו זמנית נותרו לנו רק שני שחקנים: pre-fork ו-epoll. ככל שהעומס גדל, הביצועים של שרת מבוסס סקרים גרועים יותר משרת סטרימינג. ארכיטקטורת ה-Thread-Pre-Creation היא מתחרה ראויה ל-epoll, עדות עד כמה ליבת לינוקס מתזמנת מספר רב של שרשורים.

קוד מקור ZeroHTTPd

קוד מקור ZeroHTTPd כאן. יש ספרייה נפרדת לכל ארכיטקטורה.

ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking ─ ─c _ השרשור │ ├── main.c ├── 04_prethreading │ ├── main.c ├── 05_poll │ ├── main.c ├── 06_epoll │ └── main.c ├ הפוך לציבורי ─ ├── index .html │ └── tux . png └── תבניות └── ספר אורחים └── index.html

בנוסף לשבע ספריות לכל הארכיטקטורות, ישנן שתי ספריות נוספות בספרייה ברמה העליונה: ציבורית ותבניות. הראשון מכיל את הקובץ index.html ואת התמונה מצילום המסך הראשון. אתה יכול לשים שם קבצים ותיקיות אחרים, ו- ZeroHTTPd אמור לשרת את הקבצים הסטטיים האלה ללא בעיות. אם הנתיב בדפדפן תואם לנתיב בתיקייה הציבורית, אז ZeroHTTPd מחפש את הקובץ index.html בספרייה זו. התוכן של ספר האורחים נוצר באופן דינמי. יש לו רק דף בית, והתוכן שלו מבוסס על הקובץ 'templates/guestbook/index.html'. ZeroHTTPd מוסיף בקלות דפים דינמיים להרחבה. הרעיון הוא שמשתמשים יכולים להוסיף תבניות לספרייה הזו ולהרחיב את ZeroHTTPd לפי הצורך.

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

API של לינוקס

אינך צריך להיות בקי ב-API של Linux כדי להבין את המידע בסדרת מאמרים זו. עם זאת, אני ממליץ לקרוא עוד על נושא זה; ישנם משאבי עיון רבים באינטרנט. למרות שניגע במספר קטגוריות של ממשקי API של לינוקס, ההתמקדות שלנו תהיה בעיקר בתהליכים, שרשורים, אירועים וערימת הרשת. בנוסף לספרים ומאמרים על ה-API של Linux, אני ממליץ גם לקרוא מאנה עבור קריאות מערכת ופונקציות ספרייה בשימוש.

ביצועים ומדרגיות

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

משימות מעבד ו-I/O

לבסוף, במחשוב יש תמיד שני סוגים אפשריים של משימות: עבור I/O ו-CPU. קבלת בקשות דרך האינטרנט (רשת I/O), הגשת קבצים (רשת ודיסק I/O), תקשורת עם מסד הנתונים (רשת ודיסק I/O) הן כל פעילויות I/O. כמה שאילתות מסד נתונים יכולות להיות מעט אינטנסיביות של מעבד (מיון, ממוצע של מיליון תוצאות וכו'). רוב יישומי האינטרנט מוגבלים על ידי ה-I/O המקסימלי האפשרי, ולעתים רחוקות נעשה שימוש במעבד בקיבולת מלאה. כשאתה רואה שמשימת קלט/פלט כלשהי משתמשת במעבד רב, סביר להניח שזה סימן לארכיטקטורת יישומים לקויה. המשמעות יכולה להיות שמשאבי CPU מבוזבזים על ניהול תהליכים והחלפת הקשר - וזה לא לגמרי שימושי. אם אתה עושה משהו כמו עיבוד תמונה, המרת קבצי אודיו או למידת מכונה, היישום דורש משאבי CPU רבי עוצמה. אבל עבור רוב היישומים זה לא המקרה.

למידע נוסף על ארכיטקטורות שרתים

1. חלק א': ארכיטקטורה איטרטיבית
2. חלק שני. שרתי מזלג
3. חלק ג'. שרתי טרום מזלג
4. חלק ד'. שרתים עם פתילים של ביצוע
5. חלק V. שרתים מושרים מראש
6. חלק ו'. ארכיטקטורה מבוססת פול
7. חלק VII. ארכיטקטורה מבוססת epol

מקור: www.habr.com