logo


פרק 12: הכרות עם mod_perl

סיפורו של ה fork

השרת apache, הוא שרת רשת פופולרי מאוד. פופולרי עד כדי כך שנכון למרץ 2000, כ 60% מהאתרים שנמצאים על הרשת מורצים על גבי שרת כזה. הקוד לשרת זה היינו קוד פתוח (open source), והוא חופשי להתקנה. שרת רשת היינו דבר פשוט מאוד כאשר הוא צריך לשרת משתמש יחיד, אולם בהתחשב בעובדה שאוכלוסיית כדור הארץ עברה זה מכבר את סף שש המיליארדים, סביר להניח שמצב זה נדיר למדי. למעשה השרת צריך לעבור ממבקר למבקר ולהעניק לכולם שירות בו זמנית, ממש כמו מלצר במסעדה עמוסה. לשרתים ישנם מספר דרכי תגובה אפשריות לבקשות, חלקן יעילות יותר מאחרות. Apache בגרסת x.1 הנוכחית היינו שרת pre-forking. משמעות ביטוי זה הוא שתהליך האב של השרת "מוליד" תהליכים בנים. תהליכים אילו יחכו להתקשרות. ברגע שבקשת התקשרות מגיעה, תהליך בן מטפל בה, במידה והוא כבר מטפל בבקשה אחרת, תהליך בן אחר יטפל בבקשה. במידה וכל התהליכים תפוסים, apache יכול להוליד תהליכי בן נוספים בהתאם להגדרות השרת, כאשר מספר התהליכים במערכת מקסימאלי, הבקשה תשלח לתור המתנה, ותמתין לתהליך בן שיתפנה.

כל תהליך בן לוקח משאבי מערכת, כלומר, זיכרון וזמן CPU (בהתאם למה שהוא מבצע). בצורה האידיאלית, apache תשמור תמיד על מספר בנים זהה למספר הבקשות הנכנסות. במידה ויש פרץ בקשות Apache תוליד תהליכים בנים, ותהרוג אותם לאחר סיום עבודתם, על מנת לא לבזבז עליהם משאבי מערכת מיותרים. העולם של Apache הוא עולם אכזר.

איך כל זה קשור ל Perl ? בקשת התחברות מגיעה לשרת Apache, ומבקשת לדוגמא, סקריפט CGI. תהליך ה CGI מתרחש מחוץ לתהליך הבן של ה Apache, והמשמעות היא שתהליך הבן צריך להוליד בן נוסף שיפעיל את תהליך ה CGI. במידה וה CGI מקודד ב Perl צריך להפעיל גם קומפילר, כיוון ש Perl היא לא שפה מקומפלת. הקומפילר מורץ כתהליך נפרד, המקמפל ומריץ את התהליך ב Perl, ומחזיר את התוצאה לבן של ה apache, אשר מעביר אותה למבקר. זה עובד נהדר, פרט לשתי בעיות: זה איטי מדי, כיוון שסקריפט ה Perl צריך להיות מתורגם מחדש בכל הרצה, וזה דורש המון זיכרון כיוון שצריך להריץ את הקומפילר כל פעם שמריצים סקריפט של Perl.

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

הכניסו את הגיבור

יום בהיר (או מעונן, אין אנו יודעים) אחד, בחור מבריק בשם Doug MacEachern החליט לחתן את Perl ו Apache, כך שבמקום שתי ישויות נפרדות, נקבל ישות מאוחדת. בהיותו מתכנת מבריק אך חלש בשמות, קרא דאג ליציר הכלאים שלו mod_perl. שבניסוח מדוייק, mod_perl הינו מודול של Apache אשר מכניס את קומפילר ה Perl לתוך שרת ה Apache.

היתרונות של איחוד זה הינם:

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

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

mod_perl שאתם צריכים לדעת: הכרות עם Perl ספיישל ה
תוכן עניינים
השגת הסחורה

אודות
תוכן עניינים
פרק 1: ה Perl שאתם צריכים לדעת
פרק 2: קישור Perl לעמודי הרשת
פרק 3: שמירת מצב
פרק 4: HTML בחטף ותבניות (Templates) רשת
פרק 5: עיבוד וניתוח של עמודי רשת
פרק 6: להשתעשע עם בסיסי נתונים מקוונים:אקסס
פרק 7: המודל MySQL
פרק 8: להשתעשע בבסיסי נתונים - GUFE - החזית הכללית והשימושית
פרק 9: המילניום - ניהול זמן ותאריך
פרק 10: ניהול רשימות והאשים (Hashs)
פרק 11: הפניה להפניה
פרק 12: הכרות עם mod_perl
סיפורו של ה fork  
השגת הסחורה  
ואו, איזה גודל!  
תצורה ראשונית  
נתחיל לכתוב את הקוד  
יעילות