מעבד (CPU), מעבד גרפי (GPU), זיכרון וארכיטקטורה של תהליכים מרובים
בסדרת הבלוג הזו, שמחולקת ל-4 חלקים, נבחן את דפדפן Chrome, החל מהארכיטקטורה ברמה גבוהה ועד לפרטים הספציפיים של צינור עיבוד הנתונים לעיבוד (render). אם תהיתם איך הדפדפן הופך את הקוד לאתר פונקציונלי, או אם אתם לא בטוחים למה מומלצת שיטה ספציפית לשיפור הביצועים, הסדרה הזו מיועדת לכם.
בחלק הראשון של הסדרה נבחן את המונחים הבסיסיים של המחשוב ואת הארכיטקטורה של Chrome עם כמה תהליכים.
הליבה של המחשב היא המעבד (CPU) והמעבד הגרפי (GPU)
כדי להבין את הסביבה שבה הדפדפן פועל, צריך להבין כמה חלקים במחשב ואת הפעולות שהם מבצעים.
CPU
הרכיב הראשון הוא יחידת עיבוד מרכזית (CPU). אפשר להתייחס למעבד כמוח של המחשב. ליבה של מעבד, שמוצגת כאן כעובדת משרד, יכולה לטפל בהרבה משימות שונות, אחת אחרי השנייה, כשהן מגיעות. הוא יכול לטפל בכל דבר, החל מחשבון ועד אומנות, וגם לדעת איך להשיב לשיחה של לקוח. בעבר, רוב מעבדי ה-CPU היו שבב יחיד. ליבה היא מעבד נוסף שנמצא באותו צ'יפ. בחומרה מודרנית יש בדרך כלל יותר מליבת מעבד אחת, שמספקת יותר כוח מחשוב לטלפונים ולמחשבים הניידים.
GPU
יחידת עיבוד גרפיקה (GPU) – או GPU – היא חלק אחר במחשב. בניגוד ל-CPU, GPU מתאים לטיפול במשימות פשוטות, אבל בכמה ליבות בו-זמנית. כפי שרואים מהשם, הוא פותח במקור לטיפול בגרפיקה. לכן, בהקשר של גרפיקה, 'שימוש ב-GPU' או 'ממומן על ידי GPU' משויך לעיבוד מהיר ולאינטראקציה חלקה. בשנים האחרונות, בעזרת מחשוב שמואץ על ידי GPU, אפשר לבצע יותר ויותר פעולות חישוב באמצעות GPU בלבד.
כשמפעילים אפליקציה במחשב או בטלפון, המעבד (CPU) והמעבד הגרפי (GPU) הם אלה שמפעילים אותה. בדרך כלל, אפליקציות פועלות במעבד וב-GPU באמצעות מנגנונים שסופקו על ידי מערכת ההפעלה.
הפעלת תוכנית בתהליך ובשרשור
לפני שנכנסים לעומק של ארכיטקטורת הדפדפן, חשוב להבין את המושגים 'תהליך' ו'חוט'. תהליך יכול להיות מתואר כתוכנית שמפעילה אפליקציה. שרשור הוא זה שנמצא בתוך התהליך ומריץ כל חלק בתוכנית של התהליך.
כשמפעילים אפליקציה, נוצר תהליך. יכול להיות שהתוכנית תיצור שרשורים כדי לעזור לה לבצע את העבודה, אבל זה אופציונלי. מערכת ההפעלה מעניקה לתהליך 'לוח' של זיכרון לעבודה, וכל מצב האפליקציה נשמר במרחב הזיכרון הפרטי הזה. כשסוגרים את האפליקציה, התהליך גם נעלם ומערכת ההפעלה משחררת את הזיכרון.
תהליך יכול לבקש ממערכת ההפעלה להפעיל תהליך אחר כדי להריץ משימות שונות. במקרה כזה, חלקים שונים מהזיכרון מוקצים לתהליך החדש. אם שני תהליכים צריכים לתקשר, הם יכולים לעשות זאת באמצעות Inter Process Communication (IPC). אפליקציות רבות תוכננו לפעול כך, כדי שאם תהליך עבודה לא מגיב, אפשר יהיה להפעיל אותו מחדש בלי להפסיק תהליכים אחרים שמריצים חלקים שונים של האפליקציה.
ארכיטקטורת הדפדפן
אז איך דפדפן אינטרנט נבנה באמצעות תהליכים וחוטים? יכול להיות שמדובר בתהליך אחד עם הרבה שרשורים שונים, או בהרבה תהליכים שונים עם כמה שרשורים שמתקשרים דרך IPC.
חשוב לציין שהארכיטקטורות השונות האלה הן פרטי הטמעה. אין מפרט סטנדרטי ליצירת דפדפן אינטרנט. הגישה של דפדפן אחד עשויה להיות שונה לחלוטין מזו של דפדפן אחר.
בסדרת הבלוג הזו, אנחנו משתמשים בארכיטקטורה העדכנית של Chrome, כפי שמתוארת באיור 8.
בחלק העליון מוצג תהליך הדפדפן שמתאם עם תהליכים אחרים שמטפלים בחלקים שונים של האפליקציה. בתהליך העיבוד נוצרים מספר תהליכים שמוקצים לכל כרטיסייה. עד לאחרונה, Chrome הקצה לכל כרטיסייה תהליך כשהיה אפשר. עכשיו הוא מנסה להקצות לכל אתר תהליך משלו, כולל iframes (ראו בידוד אתרים).
איזה תהליך שולט במה?
בטבלה הבאה מתוארים כל התהליכים ב-Chrome והדברים שהם שולטים בהם:
| התהליך והגורמים שהוא שולט בהם | |
|---|---|
| דפדפן |
הפקדים ששולטים בחלק 'כרום' של האפליקציה, כולל סרגל הכתובות, הסימניות, הלחצנים 'הקודם' ו'הבא'. מטפל גם בחלקים הבלתי נראים והמוגנים של דפדפן אינטרנט, כמו בקשות רשת וגישה לקובץ. |
| מפיק | קובעת מה מוצג בכרטיסייה שבה מוצג אתר. |
| פלאגין | הרשאה שמאפשרת לשלוט בכל יישומי הפלאגין שבהם האתר משתמש, למשל Flash. |
| GPU | מטפל במשימות של GPU בנפרד מתהליכים אחרים. הוא מחולק לתהליכים שונים כי מעבדי ה-GPU מטפלים בבקשות ממספר אפליקציות ומציירים אותן באותו משטח. |
יש עוד תהליכים, כמו תהליך התוסף ותהליכי שירות. כדי לראות כמה תהליכים פועלים ב-Chrome, לוחצים על סמל תפריט האפשרויות בפינה השמאלית העליונה, בוחרים באפשרות 'כלים נוספים' ואז בוחרים באפשרות 'מנהל המשימות'. נפתח חלון עם רשימה של התהליכים שפועלים כרגע, ועם נפח הזיכרון או מעבד ה-CPU שהם משתמשים בו.
היתרונות של ארכיטקטורה עם תהליכים מרובים ב-Chrome
קודם אמרתי ש-Chrome משתמש בכמה תהליכי עיבוד. במקרה הפשוט ביותר, אפשר לדמיין שלכל כרטיסייה יש תהליך עיבוד גרפי משלה. נניח שיש לכם 3 כרטיסיות פתוחות, וכל כרטיסייה פועלת על ידי תהליך עיבוד גרפי עצמאי.
אם כרטיסייה אחת לא מגיבה, אפשר לסגור אותה ולהמשיך בלי להפסיק את הפעילות בכרטיסיות האחרות. אם כל הכרטיסיות פועלות בתהליך אחד, כשכרטיסייה אחת לא מגיבה, כל הכרטיסיות לא מגיבות. זה עצוב.
יתרון נוסף של הפרדת העבודה של הדפדפן לכמה תהליכים הוא אבטחה ו-sandboxing. מאחר שמערכות הפעלה מספקות דרך להגביל את ההרשאות של תהליכים, הדפדפן יכול להעביר תהליכים מסוימים לארגז חול (sandbox) מתכונות מסוימות. לדוגמה, דפדפן Chrome מגביל את הגישה לקובצי נתונים שרירותיים לתהליכים שמטפלים בקלט שרירותי של משתמשים, כמו תהליך ה-renderer.
מאחר שלתהליכים יש מרחב זיכרון פרטי משלהם, הם מכילים לעיתים קרובות עותקים של תשתית נפוצה (כמו V8, שהוא מנוע JavaScript של Chrome). המשמעות היא שימוש גדול יותר בזיכרון, כי אי אפשר לשתף אותם כמו שאפשר לשתף אותם אם הם היו חוטים באותו תהליך. כדי לחסוך בזיכרון, ב-Chrome יש הגבלה על מספר התהליכים שאפשר להפעיל. המגבלה משתנה בהתאם לכמות הזיכרון ולעוצמת המעבד של המכשיר, אבל כש-Chrome מגיע למגבלה, הוא מתחיל להריץ כמה כרטיסיות מאותו אתר בתהליך אחד.
חיסכון בזיכרון – שימוש ב-Servitization ב-Chrome
הגישה הזו חלה גם על תהליך הדפדפן. אנחנו מבצעים שינויים בארכיטקטורה של Chrome כדי להריץ כל חלק בתוכנית הדפדפן כשירות, וכך לאפשר פיצול לתהליכים שונים או צבירת חלקים לתוך תהליך אחד.
הרעיון הכללי הוא שכאשר Chrome פועל בחומרה חזקה, הוא עשוי לפצל כל שירות לתהליכים שונים כדי לשפר את היציבות. לעומת זאת, אם הוא פועל במכשיר עם מגבלה על המשאבים, Chrome יאגד את השירותים בתהליך אחד כדי לחסוך בזיכרון. לפני השינוי הזה, השתמשו בגישה דומה של איחוד תהליכים כדי לצמצם את השימוש בזיכרון בפלטפורמות כמו Android.
תהליכי עיבוד לכל פריים – בידוד של אתר
בידוד של אתרים היא תכונה שנוספה לאחרונה ל-Chrome, שמפעילה תהליך רינדור נפרד לכל מסגרת iframe שמופיעה בכמה אתרים. דיברנו על תהליך עיבוד אחד לכל מודל כרטיסייה, שמאפשר להריץ iframes באתרים שונים בתהליך עיבוד אחד, עם שיתוף של שטח הזיכרון בין אתרים שונים. יכול להיות שזה נראה בסדר להריץ את a.com ואת b.com באותו תהליך עיבוד. מדיניות המקור הזהה היא מודל האבטחה המרכזי של האינטרנט, והיא מוודאת שאין לאתר אחד גישה לנתונים מאתרים אחרים בלי הסכמה. עקיפת המדיניות הזו היא אחד היעדים העיקריים של מתקפות אבטחה. בידוד תהליכים הוא הדרך היעילה ביותר להפריד בין אתרים. בעקבות Meltdown ו-Spectre, התברר לנו עוד יותר שאנחנו צריכים להפריד בין אתרים באמצעות תהליכים. התכונה 'בידוד של אתר' מופעלת כברירת מחדל במחשבים החל מגרסה 67 של Chrome, כך שלכל iframe בין אתרים בכרטיסייה מוקצה תהליך רינדור נפרד.
הפעלת הבידוד של האתרים הייתה מאמץ הנדסי שנמשך כמה שנים. בידוד אתרים הוא לא פשוט כמו הקצאת תהליכי רינדור שונים, אלא שינוי מהותי באופן שבו תגי iframe מתקשרים ביניהם. פתיחת devtools בדף עם iframes שפועלים בתהליכים שונים מחייבת את devtools להטמיע עבודה מאחורי הקלעים כדי שהפעולה תיראה חלקה. גם כשמקישים על Ctrl+F כדי למצוא מילה בדף, מתבצע חיפוש בתהליכי עיבוד שונים. עכשיו ברור למה מהנדסי הדפדפנים מדברים על השקת Site Isolation כציון דרך חשוב.
סיכום
במאמר הזה סיפקנו סקירה כללית על הארכיטקטורה של הדפדפן ועל היתרונות של ארכיטקטורה עם תהליכים מרובים. דיברנו גם על שירותי צד שלישי ועל בידוד אתרים ב-Chrome, שקשורים מאוד לארכיטקטורה של תהליכים מרובים. בפוסט הבא נתחיל להסביר מה קורה בין התהליכים והשרשורים האלה כדי להציג אתר.
הפוסט מצא חן בעיניך? אם יש לך שאלות או הצעות לפוסטים עתידיים, אשמח לשמוע ממך בכתובת @kosamari ב-Twitter.