מיקום הבררת מחדל של קבצי לוג של apache נמצא ב-etc/httpd/logs/
ב-DirectAdmin, ה-access log נמצא ב:
var/log/httpd/domains/domain.com.log/
וה-error log נמצא ב:
var/log/httpd/domains/domain.com.error.log/
מיקום הבררת מחדל של קבצי לוג של apache נמצא ב-etc/httpd/logs/
ב-DirectAdmin, ה-access log נמצא ב:
var/log/httpd/domains/domain.com.log/
וה-error log נמצא ב:
var/log/httpd/domains/domain.com.error.log/
באחד משרתי הווידאו שאני מפעיל, ניצול רוחב הפס עומד על 40-50Mbit, בשעות העומס יש קפיצה ל250-300Mbit, רוחב פס מאוד זול בארץ בהשוואה לחו"ל (כל Mbit עולה בין 4-8 שקל – תלוי בכמות), המחיר מאוד זול, אבל עדיין ניתן להתייעל ולחסוך בתעבורה, אז הפעלתי Traffic shaping בסרטי הווידאו בשרת, כתבתי סקריפט שמוציא את ניצול רוחב הפס כל 30 שניות, הנה הפקודה שהשתמשתי בה כדי למדוד את רוחב הפס:
vnstat -tr | grep tx | awk '{print $3 "n" $2}' | sed 's/Mbit/s/1/g' | sed 's/kbit/s/0/g'
הערה: יש להתקין vnstat בשרת (בידקו ש-UnitMode מוגדר ל-0).
פלט לדוגמא:
1
77.15
הסבר:
לאחר קינפוג המערכת לפי ההגדרות החדשות, לאחר שמשתמש מוריד 1500kb (בין 8-15 שניות), מהירות ההורדה מוגבלת ל-120kb לשנייה.
במשך השבוע שההגבלה פועלת, ניצול התעבורה בשעות השיא הגיע ל-150Mbit.
אחד הלקוחות שלי ביקש ממני להוסיף קוד מעקב של גוגל אנליטיקס לאתר שלו,
המתכנת של האתר, מסיבותיו שלו, תכנן את הקוד כמו מבצר, לא ניתן לערוך שום דבר באתר שלו, וחלק מהאתר מקודד ב-Ioncube.
הצירוף של כל הגורמים ביחד, גרם לכל הסיפור להיות תענוג אחד גדול.
יש פונקציה שמאפשרת ביצוע של קוד דינאמי/סטאטי ולהציגו ב-Header (לא רצוי), או אחרי ה-FOOTER (מומלץ), באמצעות auto_append_file.
הפונקציה הזו מבצעת require() לקובץ שאנו מגדירים.
כתבתי את קוד האנליטיקס כ-HTML והצבתי אותו בספריית הלקוח (הפונקציה מוגבלת ל-include_path), בנוסף, הגדרתי הרשאות קריאה בלבד והוספתי הגדרה ב-htaccess:
php_value auto_append_file "/path/to/file"
לאחר מכן הבנתי שתיתכן התנגשות מאחר והאתר משתמש ב-POST וב-AJAX, להחזיר תשובה לבקשות אלה עם קוד JavaScript יכול לשבור את התהליך.
אז ערכתי את הקוד והוספתי קוד PHP שקוד ה-HTML יתווסף רק במידה ומדובר בבקשת GET:
הפתרון הזה הוא זמני, עד אשר אני אמצא פתרון יעיל יותר, שיאפשר ליישם את הפונקציה רק על בקשות GET באמצעות Htaccess (אשמח אם מישהו יגיב עם פתרון).
אבי
מזל טוב, אתם הולכים להקים אתר חדש, בחרתם כבר בחברה לבניית האתר, כתבתם איפיון ועכשיו נשאר רק להתחיל לעבוד,
הנה כמה טיפים לבניית האתר (מומלץ להדפיס ולהגיש לבונה האתר):
הם לא, הם פשוט לא מהירים, הם איטיים להחריד.
באמצעות WebPageTest.org ערכתי מספר בדיקות מהירות (בדיקה המדמה גולש שמשתמש ב-IE8 בישראל עם חיבור 5/1 עם זכרון מטמון נקי), הנה סרטון המציג את הליך הטעינה בהילוך איטי:
והנה חלק מהמסקנות:
בכל האתרים האלו, יש המון השקעה ב-BackEnd (שרתי Web, שרתי Cache, Load Balance ועוד), אבל אין שום תכנון לשימוש יעיל ב-FrontEnd, אפשר להשוות את זה לנסיעה עם Ferrari במגרש חצץ.
אז איך אפשר לשפר את ה-FrontEnd?
ישנם המון תהליכים שאפשר לעשות כדי לשפר ביצועי טעינה ב-FrontEnd, ככל שהאתר גדול ומכיל יותר תוכן, כך יש יותר "עבודות שיפוץ", אתן דוגמא ל-3 תהליכים שישפרו את טעינת האתר (במקרה הזה, ב-Ynet):
Css Sprites מאפשר לנו להשתמש בתמונה שמכילה המון אלמנטים, ובאמצעות קורדינטות להציג חלק מהתמונה שאנו מעוניינים להציג במקומות שונים, בגלל שבשונה מהמדורים ב-Ynet שלא משתנים, התאריך משתנה מיום ליום, והוא מורכב מ-3 תמונות שונות (יום, חודש, שנה), קובץ התמונה והחודש מורכב מ-31 קבצים (מ-01.jpg עד 31.jpg), הקובץ מכיל את המספר ונקודה (01.jpg יכיל את הספרה 1 ונקודה), וקובץ השנה (מ-00.jpg עד-015.jpg) מורכב מצירוף מהספרות בלבד).סה"כ יש 47 קבצים שונים בתיקיה, הקובץ הקל ביותר הוא 1.gif ששוקל 264 ביט, הקובץ הכבד ביותר הוא 013.jpg והוא שוקל 1188 ביט. (כל התיקייה שוקלת 192K).
אם ניקח את הספרות 0-9 ואת הנקודה ונחבר אותם לקובץ אחד, נקבל קובץ ששוקל 6776 ביט (ניתן להקטין את המשקל עוד יותר עם דחיסה/פורמט שונה):
עם הטמעה נכונה כולל הגדרות מטמון(מגדירים לדפדפן שמור את הקובץ במחשב לשנה קדימה), אנחנו חוסכים 2 בקשות לגולש עם זכרון מטמון נקי ולאחר מכן הדפדפן לא יבקש את הקובץ מהשרת אלא יטען אותו מהמחשב. בשימוש כזה אנו חוסכים 0.15 שניה בממוצע.
מעבר לחיסכון בתעבורה וטעינה מהירה יותר של האתר, שימוש ב-Css Sprites ו-Image Map חוסכים המון משאבים לשרת ה-Web.
באחד השרתים שלי מותקן Nginx להפחתת עומסים לאתרים כבדים, את כל קבצי ה-JS, CSS והתמונות (עד משקל של 55kb) אני מארח דרך השרת הזה.
השרת מאחורי FW, עם 64Gb זכרון ראם, כל התוכן יושב על RamDisk.
אצל חלק מהלקוחות לא כל המערכות מוגדרות לייעילות מרבית, אצלי כבררת מחדל:
בנוסף, שימוש ב-IP של השרת מאשר בכתובת האתר מאפשר טעינה מהירה יותר מאחר והדפדפן פותח עוד 2-8 חיבורים והאייפי הוא "חסר עוגיה".
ערכתי מס' בדיקות ומצאתי שאפשר לחסוך זמן מעבד ולשפר את ה-TTFB עוד יותר (ב-HTTP/1.1), באמצעות פונקצית gzip_static ב-nginx.
הפונקציה הזו מאפשרת לך ליצור מראש שני קבצים:
כאשר תתקבל בקשה לקובץ, לא תתבצע פעולת דחיסה אלא קריאת הקובץ הדחוס וכך נחסכת פעולת הדחיסה (וזמן מעבד) בכל בקשת קובץ.
מספר טיפים:
1. שימוש ב-gzip_static ללא קבצי gz הוא בזבזני, מאחר וכל בקשת קובץ Nginx מחפש את קובץ ה-gz, ורק במידה והוא לא קיים הוא ממשיך לקובץ המקור, ניתן לחסוך המון I/O בביטול האפשרות הזאת.
2. במידה ואתם מציגים גם תמונות (שאותם לא דוחסים) וגם קבצי טקסט, יש לבטל את gzip_static עבור התמונות:
location ~* ^.+.(jpg|png|bmp|jpeg|tif)$ {
# Rest of configuration
gzip_static off;
}
3. במידה ו-Nginx משרת המון קבצים שונים, נפעיל את האפשרות רק עבור קבצי טקסט:
location ~* ^.+.(js|css|txt)$ {
# Rest of configuration
gzip_static on;
}
אבי קינן.
ברשת אינטרנט ארגונית, יש המון תעבורה כפולה ומיותרת, כדי ליעל את השימוש ברשת, ניתן לסנן המון תעבורה מיותרת (לדוגמא: פרסומות) ולשפר את מהירות טעינת האתרים הפופולרים.
נעשה זאת ע"י 2 הפעולות הבאות:
1. נערוך את ערכי ה-DNS ונציב 0.0.0.0 בכתובות לא נחוצות (כמו פרסומות) – ניתן לבצע זאת בשרת ה-DNS במקום העבודה, או בקובץ ה-HOSTS בכל המחשבים בעבודה.
2. נתקין שרת Proxy (לדוגמא: Squid) ברשת הפנימית ונגדיר CACHE לתוכן סטטי (קבצי JS, CSS, תמונות), בנוסף, נוסיף Expires header ל-30 יום לכל התוכן מהסוג הזה.
קצת מספרים:
1. ב-Ynet יש 21 קבצי JS (זה המון!) בעמוד הראשי, המשקל שלהם עומד על קצת יותר מ-450Kb.
2. יישום פעולה מס' 1 על 80% מהפרסומות ב-Ynet, יגרום לטעינה מהירה יותר ב-5 שניות לפחות לדף הבית של Ynet.
קיבלתי לפני כ-3 ימים כונן SSD מ-KSP במקום הקודם שמת. (אני רוצה להודות לאלכס מ-KSP על השירות שלהם).
הנה האריזה פתוחה:
פתיחת הקרטון:
לאחר פתיחת האריזה ופריקת הקרטון:
מה באריזה:
1. קרטון מהודר.
2. מדריך למשתמש.
3. פלטה המאפשרת חיבור כונן ה-SSD 2.5" לחיבור 3.5".
4. הכונן באיזה אנטי סטטית.
5. ברגים.
הכונן החדש:
כדי להראות כמה שהכונן קטן, הנחתי את הכונן על דיסק.
הרכבתי הכל והנה:
מצד ימין, LG X120 השני שלי שהשתמשתי בו בזמן ה-RMA.
מצד שמאל, המחשב מורכב עם הכונן החדש במהלך התקנה של WINDOWS 7.
סוף סיפור.
לפני 4 חודשים החלטתי לשדרג את המחשב הנייד שלי(LG x120).
הזמנתי מ-eBay זכרון ראם של Kingston בנפח 2Gb. (חמצן למערכת הפעלה) ומ-KSP קניתי כונן G.Skill Phoenix, שנראה כך. (שיפור עצום בזמני ה-I/O).
החלפתי בין הכונן (160Gb 5400RPM), לבין ה-SSD החדש, התקנתי Windows 7 במקום XP והשיפור היה מאוד מורגש, המחשב מריץ יישומים הרבה יותר מהר, פחות מתחמם והסוללה מחזיקה קצת יותר זמן (בגלל שצריכת החשמל של כונני ה-SSD נמוכה יותר).
אתמול בזמן עבודה המסך החשיך לפתע, ניסיתי להפעיל את המחשב מחדש ונתקלתי במסך ביוס מעצבן שלא זז (פה, התחלתי לחשוש). בדיקה זריזה הראתה שהנייד לא מזהה את ה-SSD (לא צפוי).
פתחתי את המחשב היום וחיברתי את הכונן למחשב נייח כדי לוודא שלא מדובר בתקלה בלוח האם,
איך מפרקים (מי שלא התנסה בזה בעבר – לא לנסות את זה בבית – באחריותכם בלבד):
1. מוציאים את כל הברגים (כולל Memory ו-KeyBoard) – סה"כ 11 ברגים.
2. בשלב זה אנחנו רואים את הלוח אם של המחשב ורואים גם את הכונן הקשיח, הכונן מוברג לתושבת של לוח האם ע"י 2 ברגים שנמצאים מתחת למקלדת.
3. מוציאים את המקלדת, ומוציאים את 2 הברגים.
4. אפשר להוציא את הכונן ע"י הרמה קלה(בעדינות), של הכונן מצד ימין ומשיכה כלפי חוץ – כפי שמסומן באדום בתמונה.
והכונן בחוץ.
בשלב הבא חיברתי את הכונן למחשב בבית, ווידאתי שהכונן באמת תקול.
והוא אכן מת, כרגע נמצא ב-RMA אצל KSP, ויש גיבוי לכל החומר.
אחרי כל מסכת הפירוקים הזו, אפשר להתנחם בחבילה שקיבלתי מ-eBay הבוקר,
כיסוי של Angry Birds למחשב.
החיפוש המובנה של Windows XP לא כל כך מוצלח בחיפוש בתוך קובץ (לדוגמא, לחפש קוד מסויים בתוך סקריפט). ב-Windows 7 החיפוש נעשה עוד יותר גרוע למרות שלחיפוש יש אינדקס.
אני משתמש ב-Seeker, תוכנה מעולה לחיפוש והיא חינמית, ניתן להוריד אותה כאן.
אלו שמעוניינים לקרוא עוד לגביה, הנה קישור לדף התוכנה.
שבוע טוב,
אבי.