שלום Apache – ברוך הבא NGINX

האם אפאצ’י, שרת ה HTTP הוותיק עדיין מתאים לשירות יישומי אינטרנט מודרניים? זהר ארד סוקר את החלופות בעולם שרתי ה HTTP

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

קצת היסטוריה

אפאצ’י הוא שרת ה HTTP הנפוץ ביותר משנת 1996 ועד היום, ולא ארחיק מאוד מהאמת אם אומר שהוא ללא ספק אחד מהנדבכים החשובים של האינטרנט כפי שאנו מכירים אותה כיום. עם נתח של יותר מ 60% בשוק שרתי ה HTTP ומעל 100 מיליון אתרים המוגשים באמצעותו, אין ספק שאפאצ’י הוא שרת טוב, מוכח ומכובד המספק מענה למגוון צרכים בצורה הולמת ואמינה.

ועכשיו, הגיע הזמן להיפרד מאפאצ’י קשישא.

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

בעיות במקבול

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

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

בהווה, אנו מתחילים לראות בעיות עם מודל העבודה של אפאצ’י באתרים שדורשים טיפול בבקשות HTTP רבות במקביל (concurrency בלעז). מכיוון שאפא’צי מטפל בכל בקשה באמצעות נים או תהליך נפרד, הרי שעמוד המכיל 20 בקשות יצריך 20 נימים או תהליכים. אפילו אם אמרנו לאפאצ’י להחזיק תמיד 300 נימים או תהליכים פתוחים כדי לטפל במספר רב של בקשות במקביל, נתקל בסופו של דבר במגבלה – או של משאבי זיכרון ומעבד או של מספר הבקשות שניתן לטפל בהן במקביל, שיהיה שווה לגבול העליון של מספר הנימים או תהליכים שאפאצ’י יכול להחזיק פתוחים עבור חומרה נתונה.

אם נחזור לדוגמת העמוד עם 20 הבקשות, ונתחשב במגבלת הדפדפן להוציא שתי בקשות לאותו שם מתחם במקביל, הרי שתצורה התומכת בטיפול ב 300 בקשות במקביל תספיק ל 150 צפיות של אותו עמוד באותו רגע (בהנחה שכל הבקשות הן לאותו שרת כמובן). כל שאר הצפיות יאלצו לחכות לאפאצ’י שישחרר בקשה ישנה כדי לטפל בחדשה, ואנו כמובן יודעים שמשתמשינו אינם אוהבים לחכות.

מחפשים פתרונות

הפתרון לבעיית המקבול התחיל אי שם כשריילס נהייתה פלטפורמה פופולרית וחיפשו דרך טובה לשרת ישומי ריילס אינטרנטיים. מכיוון שלא היה מודול אמין שאפשר להריץ יישומי רובי ע”ג אפאצ’י באופן דומה להרצת יישומי PHP, חיפשו חלופה שלא תצריך הרצת רובי ע”ג אפאצ’י. הפתרון היה להריץ את היישום ע”ג שרת-יישומים ייעודי שידבר עם אפאצ’י (או עם כל שרת HTTP אחר) כפרוקסי. וכך, אפאצ’י יקבל את בקשות ה HTTP מהדפדפן ויעבירם אחורה לשרת היישומים שיודע להריץ את קוד היישום ולהחזיר את התשובה לאפאצ’י.

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

הפרד ומשול

אם נשים רגע את ההרגלים והדעות הקדומות בצד, למודל ההפרדה המתואר לעיל יש מספר יתרונות על המודל של “One Web Server to Rule Them All!!!”.

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

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

אומרים שלום לאפאצ’י

הזכרתי בתחילת המאמר את תחביב זלילת המשאבים של אפאצ’י ומגבלת מקבול הבקשות שלו. לפני כשנתיים נכנס שחקן חדש לשוק שרתי ה HTTP וכיום הוא מחזיק בנתח של כ 7.5% משוק שרתי ה HTTP.

הכירו בבקשה את Nginx (נהגה Engine X).

מודל Reactor

Nginx הוא סוג של ילד פלא שהותיר מאחוריו את מורשת הנימים והתהליכים המסורבלת ואימץ מודל עבודה לא-חוסם (non-blocking). מודל זה מפעיל תהליך אחד שמאזין לכל הבקשות הנכנסות, ושם אותן במאגר הנקרא כור (Reactor). התהליך רץ על הכור בצורה מעגלית ובודק האם הגיעה תשובה לכל בקשה בכור. בקשה שקיבלה תשובה מוצאת מהכור ומוחזרת ללקוח המבקש.

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

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

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

מכיוון ש Nginx מתמחה בטיפול במשאבים סטטיים, הוא מגיע מצוייד ביכולות הטמנה (Caching) מפוארות, כולל צימוד ל memcached המאפשר טיפול בהטמנת עמודים או מידע אחר ברמת השרת ולא ברמת היישום (או אם לומר ישירות – יש לכם HTML caching מובנה עם תמיכה ב memcached בלי להניד עפעף).

אם תבחרו בנתיב מעט שונה, תוכלו להשתמש ב Nginx כדי לשרת עמודי HTML עם SSI המפנים לחלקים דינאמיים. Nginx ישמח לאחסן את החלקים הסטטיים במטמונו ולהעביר את הבקשות הדינמיות אחורה לטיפול.

אם אתם חרדים לביצועים, תוכלו לבחור משלל שרתי-יישומים עבור פיתון ורובי דוגמת:

  • Gunicorn, Twisted, GEvent לפייתון
  • Unicorn, Thin, Mongrel לרובי
  • PHP-FPM, Photon ל PHP (שימו לב ש Photon עדיין בשלבי פיתוח)

אז למה כן אפאצ’י?

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

החשיבות הרבה שיש לטעמי באימוץ החלופה שמציג מודל ההפרדה לשרת אחורי וקדמי בכלל ו Nginx בפרט היא בפתיחת אופקים לחלופות שונות המתאימות לצרכים שונים. בעוד שבמודל העבודה עם אפאצ’י התמודדות עם צרכים שונים נעשית כמעט אך ורק ברמת התצורה של אפאצ’י, במודל השרתים הנפרדים, נוכל לבחור בשרת אחורי דוגמת Thin או Twisted למצבים בהם מקבול בקשות רבות הוא קריטי או ב Unicorn או Gunicorn למצבים בהם יש פחות מגבלת משאבים אך קיים צורך באתחול הדרגתי של השרת אחרי שדרוג עם down-time מינימלי.

חלופות ל Nginx

ישנן כמובן חלופות ל Nginx כמו Lighttpd או Cheroke כך שאין מגבלה על בחירת השרת הקדמי. כל עוד אתם מאמצים את מודל הפרדת השרתים, תוכלו לבחור צמד אחורי וקדמי שמתאים לצורכי המערכת שלכם. בגלל הנפוצות של Nginx מצויים רשת הרבה מדריכים להתקנה והגדרת תצורה של השרת החביב הזה, כולל תצורה לעבודה עם PHP כאשר אפאצ’י משמש כשרת אחורי או כשרת קדמי באמצעות FCGI כך שגם למתכנתי ה PHP באשר הם אין סיבה להתעצל.

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

אז מה היה לנו?

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

זהר ארד

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

הגב

24 תגובות על "שלום Apache – ברוך הבא NGINX"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
משה למפרט
Guest
מוחה על הזלזול באנשי IIS. נכון, מדובר בטכנולוגיה סגורה, אבל המבנה הפנימי שלה (Application Pools) מוצלח הרבה יותר מזה של ה-Apache ושל אחרים בכל מה שקשור לרכיבים דינאמיים. אמנם, נכון שעלות “ייצור ” process על Windows גבוהה משמעותית מזו שעל *nix. ל-IIS ול-ASP.net למשל יש פתרונות מאוד יפים בכל מיני נגזרות, כשאפשר לרוב לבחור בהן או בתחליפי קוד הפתוח בשבילן (MySQL .NET Connector, Memcached Client). זה לא קורה תמיד, אבל למיקרוסופט יש לפעמים יש גם הברקות. ה-Cache המובנה של ASP.net הוא רק דוגמא למימוש פשוט ובסיסי שפותר כ”כ הרבה בעיות באתרים בינוניים, מימוש שבכלל לא אפשרי בסביבות אחרות בגלל מבנה… Read more »
זהר ארד
Guest
הזלזול שלי ב IIS מגיע מאותו מקום של הזלזול שלי בטכנולוגיות סגורות. לדעתי רוב מי שמשתמש בטכנולוגיות סגורות, סוגר את הראש לחלופות פתוחות שעשויות להתאים באותה מידה או יותר. לדעתי הדפוס הזה שגוי בעולם האינטרנט שעיקר הצמיחה שלו הוא תודות לשימוש בטכנולוגיות פתוחות. במילים אחרות, מי שסוגר ראש ועוצם עיניים ישאר מאחור ולא רלבנטי. כלוב הזהב של משפחת דוט.נט הוא דוגמה מצויינת לכך לדעתי. נכון, הזכרת כאן את MySQL ואת Memcached וידוע ש IIS יודע להריץ היום PHP בצורה טובה מאוד אבל ככלל, מיקרוסופט מעוניינים שהמפתחים שמשתמשים בטכנולוגיות שלה ימשיכו לעשות זאת בלי לפזול החוצה. כלומר, אם כבר בחרת בשלל… Read more »
משה למפרט
Guest
אני לא חושב שנכון להימנע משימוש בטכנולוגיה סגורה רק בגלל שהיא סגורה. ASP.net היא דוגמא מצויינת לכך אם כי ממש לא יחידה. במיוחד אם האופציה השניה הקיימת היא PHP. הבחירה (הנדירה בארץ) של Java או Ruby נראית כבר הגיונית יותר. כלוב הזהב של דוט נט כבר מזמן לא רלוונטי מבחינה טכנית, ו”כלוב זהב”, אחר דוחף אנשים ל- LAMP גם שם בלי לבחור חלופות שהיו יכולות להתאים יותר כמו lighttpd או nginx, ועל מגבלות PHP-CGI/FCGI אני חושב שכבר כתבת יותר טוב ממני. אני לא חושב שיש פחות אופציות ב-ASP.net. האופציה לעבוד עם רכיבי קוד פתוח שונים (למשל OOO ו-GhostScript להמרות, Memcached,… Read more »
Erik
Guest

הבחירה בnginx ממש לא חוסמת את אנשי דוט נייט.
mono רץ יופי על NGINX, במקרים מסויימים יותר מהר מIIS :)

משה למפרט
Guest

כל כלי שיכול לסייע – מותקן במערכה :-)

ערן
Guest

הזלזול ב-IIS הוא משום שמסובך לטפל בו!
ניסית פעםלנהל חווה של 10+ שרתי IIS? או לכתוב deployment אוטומאטי לדבר הזה?
או לנהל תצורה של כל ההגדרות שלו? או המוניטורינג מהגיהינום שהם נותנים לך עם כל ה-performance counters? סקריפטים ב-powershell?

ה-cache המובנה של asp.net הוא in-memory מה שלא באמת מתאים לכל אפליקציה שהיא לא דמו… או שאפשר לחבר אותו ל-SQL Server שזה אמממ… יעיל :S

זהר ארד
Guest

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

ליאור קסוס
Guest

nginx + php-fpm = love
אחת התצורות הכי מוצלחות באפליקציות php “שמנמנות” קשורות בשימוש בnginx ו php-fpm.
התצורה הזו עזרה לטפל בבעיות ביצועים רציניות באתר ערוץ הילדים (אתר הדרופל הגדול והעמוס בישראל).
השתמשנו בתצורה הזו גם באתר שטראוס שלי – http://mystrauss.strauss-group.com/ – כשהיה צריך להתמודד עם כמות גדולה של משתמשים מזוהים (נרשמו המון משתמשים בבת אחת מהפרסומת בטלוויזיה).

ארז אלסטר
Guest

פוסט מעולה!
אני משתמש בNginx ואני מאוד מרוצה ממנו.
אני מאוד אוהב את הנוחות שבהגדרה שלי דומיינים נוספים ובכלל בנוחות עבודה איתו.

אני מתכנת כבר 8 שנים ב.Net ולאט לאט מתנסה בעולם הקוד הפתוח.

הבחירה ומוצרים שהם לא מבוססים על Windows מבחינתי היא כספית. אני בטוח שהרבה יותר כואב כלכלית להגדיל את חוות השרתים של האתר במידה ואתה מפתח ב.Net.

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

אני לא מרגיש בנוח להריץ .Net על מונו – אני אשמח לשמוע על ארגון שיקנה מוצר .Net שרץ על לינוקס.

דרופל מן
Guest

כיף לקרוא כתבה כל כך מושקעת – תודה זהר! יש לי אבל שאלה עקרונית שלא קיבלה מענה במהלך הקריאה. איני מומחה שרתים ולכן זו שאלת הדיוט גמור.

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

אמיר סימן טוב

יגאל
Guest

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

ניר גייר
Guest

אם היית מכיר את זהר הית יודע שחוסר ידע זה לא הוא.

מיכאל בן-נס
Guest

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

מה שכן, לרוב התצורות הקלסיות NGINX יעבוד מעולה.

רמי
Guest

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

זהר ארד
Guest

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

משה
Guest

רק כהערה – את IIS מנהלים דרך web.config/machine.config וכשצריך גם applicationHost.config.

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

ולגבי nginx עם mono – נשמע מעניין, נבדוק בהזדמנות ונחזיר תוצאות.

יגאל
Guest

מצטער, באמת זה לא במקום :-) אני מניח שהכותרת באה לעורר עניין בסה”כ.

דניאל
Guest

מאמר מעניין.

לא הייתי ממהר להספיד את ה-Apache,
נכון, רעיון ה”הפרד ומשול” של ה-Nginx הוא רעיון טוב שאפילו עובד מצוין במס’ סביבות Production שאנחנו מפעילים.
אבל, יש עוד לא מעט בעיות ב-Nginx שמונעות ממנו להגיע לסביבת הShared hosting, הן ברמת היכולות של המנוע (למשל, טיפול בSessions, אינטרקציה מול htaccess) והן במשתמשים (כלומר, מפתחים) שעדין לא התאימו את עצמם והאפליקציות (במקרה צורך) לטכנולוגיה.

עד אשר המנוע לא יידע לטפל בנושאים מעין אלו, הוא לא יכנס לסביבות הShared בעולם מה שימנע ממנו להוביל את השוק.

אור
Guest

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

אנחנו עובדים עם nginx ו fastcgi באמאזון וזה עובד נפלא. אנחנו גם משתמשים ב XSendfile עבור שירות המאפשר הורדה של סרטים בתשלום (http://wiki.nginx.org/XSendfile), ההרשאה להוריד/לצפות מגיעה מהסקריפט/סשן ב php ו nginx דואג לשאר :)

ישי סמיט
Guest

אנחנו משתמשים המון בnginx כreverse proxy והוא עובד מצויין (לקחנו את הרעיון מגוגל שם הוא עובד בהיקף נרחב).
נקודות החוזק שאנחנו משתמשים בהם הם תמיכת האבטחה המצויינת שלו, Load Balancing, ופיזור קריאות יעיל. הוא מפנה קריאות לs3, דיסק או אחד מסוגי השרותים ברקע כתלות בחלקי הURL, cookie, פרוטוקולים ועוד.
שרת נוסף באותה קטגוריה הוא הVarnish בעל יכולות דומות, חלש במודולי אבטחה (SSL) אבל חזק מאוד בקונפיגורציה דינאמית! אפשר להתחבר אל תהיוכים שלו ולשנות ניתובים מבלי לאתחל אותו. השינויים מתקמפלים לשפת מכונה ורצים במהירות רבה. מומלץ להריץ עם Nginx כדי לקבל את הטוב משניהם.

זהר ארד
Guest

ישי, אחלה פידבק :)
חשוב רק להבחין בין Nginx שהוא שרת HTTP ובין Varnish שהוא שרת Caching

עומר כץ
Guest

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

wpDiscuz

תגיות לכתבה: