nginx מול Apache: יתרונות, חסרונות ואירוח מעשי
השוואה למנהלי מערכות: תצורה, PHP-FPM, זיכרון, פרוקסי ואבטחה.
English
לבחור מערכת שיודעים להפעיל היטב
nginx ו־Apache HTTP Server הם שרתי אינטרנט המסוגלים להגיש בלוג, קבצים סטטיים ובקשות ליישום דינמי. הבחירה המועילה תלויה ביישום, בשיטת התצורה ובצוות שמתחזק אותו. טענה כללית ששרת אחד תמיד מהיר או בטוח יותר אינה מספיקה לתכנון אמיתי.
מנהל Linux צריך לחשוב גם על יומנים, שחזור, תעודות ועדכונים. תהליך שמאזין ברשת אינו מוכיח שהאתר תקין: יש לבדוק בחירת מארח, הפניות, הפעלת PHP והרשאות גישה.
ארכיטקטורה: להשוות תצורות מודרניות
nginx משתמש במודל עובדים מונע אירועים. Apache מציע מודולי עיבוד שונים; event MPM מאפשר לטפל בחיבורים שאינם מעבדים כרגע בקשה בלי להעסיק תהליכון עבודה באותה דרך כמו בבקשה פעילה. לכן השוואה ל־Apache ישן בתצורת prefork אינה מייצגת את כל אפשרויות ההפעלה.
במדידה יש לתעד MPM, מודולים, שיטת הפעלת PHP ועומס עבודה. בדיקת קובץ סטטי ובדיקת דף שפונה למסד נתונים עשויות לחשוף צווארי בקבוק שונים לגמרי.
| נושא | nginx | Apache HTTP Server |
|---|---|---|
| תצורה | כללים מרכזיים מסוג server ו־location | מארחים וירטואליים, תיקיות ומודולים |
| .htaccess | אינו קורא קובצי Apache כאלה | מאפשר הגדרות לפי תיקייה כשניתנה הרשאה |
| PHP-FPM | חיבור FastCGI | FastCGI באמצעות mod_proxy_fcgi |
| קבצים ו־Reverse Proxy | שימוש מרכזי ונפוץ | נתמך גם כאן; תלוי בתצורה |
| ניהול | ניתוב מפורש ושליטה מרכזית | גמישות במודולים ובכללי תיקיות |
| תוכנה חופשית | רישיון קוד פתוח מתירני | Apache License 2.0 |
יתרונות nginx והמחיר שלהם
nginx מתאים לצוות שמעדיף תצורה מרכזית וניתוב מפורש. הוא יכול להגיש תוכן סטטי ולשמש פרוקסי לפני שירותי יישום. ריכוז הכללים במקום מבוקר יכול להקל על ביקורת שינויים.
מן הצד השני, יישום שמגיע עם כללי Apache דורש תרגום ובדיקה. הנחת קובץ .htaccess בתיקייה לא תשנה את התנהגות nginx. צריך להבין את בחירת ה־location ואת מיפוי הנתיבים; כלל שנראה דומה עלול להתנהג אחרת. שליטה מרכזית גם מצריכה בדרך כלל התערבות מפעיל לשינויים כאלה.
יתרונות Apache והמחיר שלהם
תצורה לפי תיקייה יכולה לעזור באירוח משותף, כשבעל האתר צריך יכולת מוגבלת לשנות התנהגות בלי לערוך את תצורת השרת הראשית. מערכת המודולים היא סיבה מעשית נוספת לבחור ב־Apache או להשאירו ליישום קיים.
עם זאת, קובצי .htaccess מוסיפים עבודת בדיקה ומפזרים כללים במערכת הקבצים. תיעוד Apache ממליץ להעדיף תצורה ראשית כאשר יש גישה אליה. המלצתנו היא להאציל רק את ההרשאות הנחוצות ולתעד מדוע כל מודול והגדרת תאימות נשארים פעילים.
PHP-FPM מתאים לשניהם
שני השרתים יכולים להעביר בקשות ל־PHP-FPM דרך FastCGI. יש למפות בקשה לקובץ הנכון ולהפעיל את מאגר תהליכי PHP בחשבון ובהגבלות מתאימים. החלפת שרת אינה מתקנת מעצמה שאילתת מסד איטית או כמות גדולה מדי של עובדי PHP.
להשוואה הוגנת משתמשים באותו יישום ובנתונים דומים. יש לבדוק שבקשות לקובצי PHP שאינם קיימים אינן מנותבות בטעות, ושקבצים שהועלו אינם הופכים לקוד בר־הרצה. אנו ממליצים להפריד העלאות מקוד היישום ולהגדיר במפורש היכן מותר לבצע קוד.
זיכרון: למדוד את המערכת כולה
תצורת nginx רזה יכולה להסתפק בטביעת זיכרון קטנה לשרת עצמו. מכאן לא נובע חיסכון קבוע לכל אתר. צריך לספור גם עובדי PHP, מטמונים, מודולים, מסד נתונים ומאגרים לחיבורים. Apache עם event ו־PHP-FPM הוא מקרה שונה מ־prefork עם PHP מוטמע.
המלצתנו היא למדוד זיכרון, זמני תגובה ושיעור שגיאות בעומס מייצג, לרבות בקשות דינמיות במקביל. ממוצע נאה אינו עוזר כשהמערכת מחזירה תשובות שגויות או נתקעת בשיא. לכן אין במאמר הבטחת מספר מגה־בייט או יתרון מהירות אוניברסלי.
אבטחה והחלטה שימושית
אף שרת אינו מאובטח רק בזכות שמו. צריך לעדכן חבילות, להגביל כתיבה לתצורה, להגן על סודות ולבדוק התנהגות מבחוץ. כשיש פרוקסי קדמי, מגדירים מי מהימן לפני שמאמינים לכותרות כתובת לקוח. אין לשמור במטמון תשובות פרטיות בלי להבין את כללי ההזדהות והמטמון.
בחרו nginx כשהתצורה המרכזית ותפקיד הפרוקסי מתאימים לעבודה. בחרו Apache כשהתאימות, המודולים או האצלת התצורה נותנים מענה אמיתי. אפשר להפעיל את שניהם, אך זה מוסיף רכיבים ונתיבי תקלה. לבלוג קטן כדאי להתחיל ממבנה שהצוות יודע להסביר ולשחזר. להמשך: PHP, HTML ו־MariaDB.