May your sockets never timeout
מפעם לפעם אני מקבל תרומות תמיכה בFireStats, בדרך כלל בסכומים של $5, $10.
זה נחמד, ומראה שאנשים אוהבים את המערכת.
לפני כמה ימים קיבלתי תרומה כזו, בסכום של $10, ומיד לאחריה את האימייל הזה, שבאמת חימם לי את הלב:
Hello!
This donation is my way of appreciating your work.
It comes to you from India, where this amount represents
almost my one day's earnings. That shows how much
I appreciate your work. I am a retired person.Dr.______
בצירוף מקרים קוסמי שחררתי היום גרסאות חדשות לשלושה פרוייקטים בלתי תלויים:
FireStats 1.5.9-RC3:
FireStats 1.5 מתייצב, ורוב הסיכויים שהגרסא הבאה תהיה הגרסא היציבה של הענף הזה.
רשימת השינויים נמצאת כאן.
WPMU Plugin Commander 1.1.0
WPMU Plugin Commander הוא תוסף ניהוי תוספים לWPMU, שמוסיף כמה תכונות מאוד נדרשות לWPMU (אפשרות לבחור איזה תוספים משמשים יכולים להפעיל ולכבות, אפשרות להפעיל אוטומטית תוספים עבור בלוגים חדשים ועוד)
אתמול בלילה קיבלתי תרומת קוד שמוסיפה תמיכה בריבוי שפות לPlugin Commander, וכן שינויי עיצוב שגורמים לא להיות הרבה פחות מכוער.
בנוסף, התורמת של הקוד תרמה גם תרגום לרוסית של התוסף.
Antenna 1.1.0-beta
קיבלתי תרומת קוד גדולה מצוות MTJ, הקוד מממש את הPreprocessor שכתבתי בANTLR 3.0, מה שיאפשר הכנסה של הPreprocesror לתוך MTJ.
MTJ הוא פרוייקט שמטרתו להכניס תמיכה בפיתוח קוד J2ME בEclipse. הפרוייקט יתבסס על EclipseME, שהוא הסטנדרט דה-פקטו לפיתוח J2ME עם Eclipse. הPreprocessor שלי כבר נמצא בתוך EclipseME די הרבה זמן, אבל היתה בעיה עם הרשיון של ANTR 2.7.7 שבו השתמשתי כדי לפתח אותו, ו Eclipse legal לא אישרו את הכנסת הקוד שלי לMTJ מהסיבה הזו.
הצוות של MTJ בחר לבצע Porting של הPreprocessor כך שיעבוד עם ANTLR 3.0 כי הרשיון שלו תואם את זה של Eclipse.
לפני כמה ימים הצוות קיבל אישור מEclipse legal לתת לי את הקוד שהם יצרו כדי שאני אקלוט אותו לתוך Antenna.
הקוד היה איכותי, ועבר את כל בדיקות היחידה שהגדרתי כבר, מה שנתן לי ביטחון גבוה שהוא עובד כמו שצריך. אחרי כמה שעות עבודה, הקוד הוטמע והיום שחררתי גרסא חדשה של Antenna שמשתמשת בPreprocessor החדש כברירת מחדל.
The pirate bay מתחיל להציע בלוגים על בסיס וורדפרס מיו, ונחשו מה הוא מריץ?
FireStats!
לכבוד הוא לי :).
כחלק מהתחרות הבלתי פוסקת בגוגל, מייקרוסופט החליטה לקנות את פיירסטטס, ולשלב אותו בוויסטה.
המערכת המשולבת תקרא Vistats, ותתמוך בהצגת נתונים סטטיסטיים על השימוש של המשתמש במחשב דרך אתר מרכזי.
נתונים שיאספו על משתמשי וויסטה:
* התפלגות השעות בהן הממשתמש עובד על המחשב.
* התפלגות השעות בהן המשתמש משחק משחקי פלאש באינטרנט.
* התפלגות השעות בהן המשתמש צופה בסרטי פורנו.
* קבצים שנפתחים בתדירות הגבוהה ביותר.
ועוד.
כל הנתונים יהיו זמינים לכל דיכפין דרך vistats.microsoft.com.
המערכת נמכרה תמורת סכום שצונזר כדי להמנע מתשלום מס מנופח.
נשבע לכם.
שחררתי בטא שלישית של 1.5, שמתקנת את כל הבעיות שהיו ידועות עד כה.
מי שמריץ את 1.5 מוזמן לשדרג, ומי שלא – שייתביש בפינה!
רשימת התיקונים פה.
אגב, חלק מהבאגים נפתרו בטיסה טרנס אטלנטית :).
למרות שהקטע הראשון של הטיסה לסאן פרינסיסקו היה במטוס מחורבן, הדרך חזרה היתה במטוסים עם מסך אישי כולל חשמל 110 וולט ללפטופים, מה שעזר רבות :).
אגב, התרגום לעברית עודכן, לא הודות לשרון שפוטרה מתפקידה כמתרגמת עקב תפקוד לקוי.
למי שמחפש פתרון תומך לבדיקות יחידה (Unit test) של קוד PHP, יש את PHPUnit.
PHPUnit יהיה מוכר מאוד לכל מי שהשתמש אי פעם בJUnit, ולו משום שהוא port מוצהר של JUnit לשפת PHP.
התחלתי לכתוב בדיקות יחידה לחלקים של פיירסטטס, ואולי יהיה פוסט נוסף על העסק הזה בהמשך.
YUI – יואי, או Why you aye, הוא ספריית JavaScript שמפותחת ביאהו.
יואי משוחרר ברשיון BSD (רשיון תעשו מה שאתם רוצים עם הקוד), וכולל טאבים, עצים, אנימציות, השלמה אוטומטית ועוד פחות או יותר 252 דברים שאולי תרצו לבדוק אם אתם רוצים להכניס עניין באפליקציית WEB שאתם מפתחים.
אני שוקל להתחיל להשתמש בYUI בפיירסטטס – לפחות באופן חלקי, במקום הערמה המגוונת של ספריות חיצוניות שיש שם כרגע.
על YUI שמעתי בפעם הראשונה בפודקסט המצויין של ליאו לפורט – Floss weekly.
למי שמתעניין בקוד פתוח – מומלץ מאוד.
בכל פודקסט (לא ממש פעם בשבוע), יש ראיון עם דמות מפתח מעולם הקוד הפתוח.
החל ממפתחים שהתחילו שפות (PHP, פיתון), דרך מיסד וויקיפדיה, אבן מוגלן ועוד.
מאוד מעניין ומומלץ.
English translation below.
נפגשתי עם סקוט סיגלר לבירה.
למי שלא מכיר, סקוט סיגלר הוא אחד מהראשונים ששחרר ספר שלם בצורה של פודקסט שבועי.
בימים אלו הוא משחרר את הספר החמישי שלו, Nocturnal, שהגיע אחרי Earth core, Ancestor, Infected וThe rookie.
Earth core and Ancestor יצאו כבר כספרים, וInfected יוצא באחד באפריל השנה.
דיברנו על פודקסטים, על העתיד תעשית הבידור, על פיירסטטס ועוד.
יש הרבה דמיון בינינו בהיבט הזה, גם סקוט וגם אני נותנים משהו בחינם כדי להגיע לחשיפה של כמה שיותר אנשים, מתוך הבנה שהכסף יבוא אחר כך:
שלב א: להשיג חשיפה לכמה שיותר אנשים, גם אם זה אומר לתת בחינם את העבודה שלכם. לא לנסות בכלל להלחם במי שיגנוב.
שלב ב: למצוא דרך להרוויח על בסיס קהל המשתמשים/המאזינים הגדול שהשגתם.
במקרה של סקוט, הדרך שלו היא למכור את הספרים. אני יכול לספר שקניתי עד עכשיו את כל הספרים שלו, למרות שבעצם כבר קיבלתי אותם בחינם בצורה שיותר מתאימה לי מאשר ספר נייר – כלומר פודקסט.
הסיבה שקניתי היא שאני רוצה לתגמל את סקוט על העבודה הקשה שהוא השקיע ומשקיע.
כל הסיפור הוא במספרים. אם 15% מהמאזינים של סקוט יקנו את הספרים שלו, אז הוא יהיה בסדר מבחינה כספית.
כמובן, אם 30% מהקוראים גם יספרו לחברים שלהם על הפודקסט, ואפילו יציעו להם להוריד בחינם כי זה אחלה, חלק מהחברים האלו יקנו את הספרים על בסיס ההמלצה כי אנחנו עדיין חיים בעולם שבו רוב האנשים מעדיפים לקנות ספר מאשר להוריד קבצי קול , הוא יהיה עוד יותר בסדר.
במקרה שלי, אני חושב לשחרר בעתיד גרסא של פיירסטטס, או מעין פלאג-אין שיכיל יכולות מתקדמות שאין בגרסא הבסיסית, אולי גראפים או דוחות, שיעלה כסף.
כמו אצל סקוט, זה משחק של מספרים גדולים. אם אחוז מספיק גדול של המשתמשים של הגרסא החינמית יקנה את הפלאגין אז ההשקעה כולה השתלמה לי.
וכמובן, כמה שמספר המשתמשים בגרסא הבסיסית יהיה גדול יותר, המספר המוחלט של המשתמשים שיקנו את הפלאגין יגדל בהתאמה.
תעשית ההוצאה לאור היא תעשיה שמרנית, וקשה לשנות תפיסות של תעשיה כזו.
מה שסקוט ופודקסטרים אחרים שמוציאים ספרים זה נסיון לשנות את התפיסה של חברות ההוצאה לאור, שממש לא רגילות לרעיון של לפרסם ספר אחרי שהוא היה זמין בחינם באינטרנט.
אם סקוט יצליח להמריא, ולחדור למדיה הקלאסית – ובינתיים כל הסימנים מראים שהוא הולך להצליח – נראה ערמה שלמה של סופרים חדשים שילכו בדרכו, כשהטובים מביניהם גם יצליחו להתפרסם.
אז סקוט, תודה שהסכמת להפגש.
מאוד נהנתי מהשיחה איתך.
בפעם הבאה שניפגש אני אחתים אותך על Infected, הזמנתי אותו מאמזון, ביחד עם Little brother של קורי דוקטורו.
ועכשיו תרגום לאנגלית של הפוסט, כדי שאי אלו סקוט סיגלרים יוכלו לקרוא את מה שכותבים עליהם בבלוגים בעברית:
We spoke about Podcasts, the future of the entertainment industry, about FireStats and more.
Me and Scott have a lot in common on this aspect, we both give something for free to gain exposure to as many people as possible, in understanding that the money will follows:
Step A: get Exposure to as many people as possible, even if it means to give your work for free. and not even try to fight those who may steal your work.
Step B: Find a way to make money, based on the large users/listeners audience you have acquired.
Scott`s way to do that is to sell the books. I can tell that I bought all his books until now, despite the fact that I've already received it for free in a form I find more convenient than paper form – a podcast.
The reason I bought the books is that I wanted to support Scott in exchange for the hard work he is putting into the books.
This is a numbers game, if 15% of Scott`s listeners will buy his books, he is doing pretty well already. if 30% of the listeners will tell their friends about it, and even tell them to download it for free – some of those friends will buy the books based on the recommendation because we are still living in a world where most people would rather buy a book than to download audio files.
in my case, I am thinking of releasing in the future a version of FireStats, or a plugin to FireStats, that will add advanced abilities that does not exist in the basic version. maybe graphs or reports – which will cost money.
just like for Scott, it's a game of big numbers. if a large enough percentage of the users of the free version will buy the extending plugin than the entire effort was worth while.
and of course, the bigger the number of users of the basic version, the larger the number of people which will but the plugin.
The publishing industry is a conservative industry, and it's hard to change it's perceptions.
What Scott and other Podcasters that releases books are doing is an attempt to change the perception of the publishing industry, which is really not used to the idea of publishing a book after it have been available on the web for free.
if Scott will manage to take off and infiltrate the mainstream media – and at this moment, the signals indicates that he will succeed – we will see a whole pile of new writers following his foot steps, when the good of them will get famous.
So Scott, Thanks for agreeing to meet.
i really enjoyed our conversation.
Next time we meet I`ll get you to sign Infected – ordered it from Amazon along with Cory Doctoro`s Little brother.
FireStats 1.5 נכנס בשעה טובה לשלב הבטא עם השחרור של 1.5.0-בטא.
בין השינויים הגדולים:
ועוד הרבה.
דף הNew and noteworthy מכיל רשימה יותר מלאה עם תצלומי מסך, ויומן השינויים מכיל רשימה מפורטת.
הערה: יש סקר בסוף.
סקירה היסטורית
בראשית היה ASCII (האמת היא שהיו קידודים לפני ASCII אבל הם לא מעניינים אותנו).
אסקי נועד בעיקר לתווים באנגלית, הערך של 'A' הוא 65, הערך של רווח הוא 32 וכן הלאה. ASCII הוא קידוד 7 ביטים, מה שאומר שהוא משתמש ב128 אפשרויות מתוך 256 האפשרויות שנכנסות בbyte.
הבעיה עם אסקי היא שהוא לא כולל תווים של שפות אחרות – קירילית ועברית למשל.
Code page
הפתרון המתבקש הוא להשתמש בערכים 128-255 כדי לייצג את האותיות החסרות.
הבעיה היא שהרבה אנשים חשבו על הפתרון הזה בו זמנית, ומטבע הדברים היו הרבה טבלאות כאלו, לפעמים אפילו כמה בתוך אותה מדינה.
לא נחמד, כי מסמך שנכתב תוך שימוש בטבלא אחת לא הוצג כמו שצריך למי שהשתמש בטבלא אחרת.
בשלב מסויים הוגדרו סטנדרטים על ידי ארגון התקינה האמריקאי (ANSI) , שנקראו Code pages, מה שעזר למנוע הווצרות של טבלאות מיותרות חדשות.
הבעיה העיקרית עם הפתרון הזה הוא שאי אפשר לערבב שפות שמשתמשות בקודים שונים.
בנוסף, הוא נותן פתרון רק לשפות בעלות פחות מ128 אותיות.
באסיה הוגדר תקן בשם DBCS – Double byte character set, שנועד לתת פתרון לשפות האסיאתיות.
התקן הזה השתמש בקידוד באורך משתנה: חלק מהתווים היו באורך בייט אחד וחלק באורך שני בייטים, ובאופן כללי היה מבלבל למדי.
UNICODE
יוניקוד הוא שם הקוד לטבלא גדולה מאוד שמתאימה מספר לכל אות ידועה (וגם כמה משפות מומצאות כמו קלינגונית), מכיוון שיש טבלא אחת לכל השפות – אין בעיה לערבב בין שפות שונות.
מיתוס נפוץ הוא שניתן לייצג כל אות ביוניקוד בעזרת מספר בין 16 סיביות (או במילים אחרות, שיש פחות מ65536 אותיות ביוניקוד).
זה לא נכון, ולמעשה יש ביוניקוד גרסא 4.0 קרוב ל240,000 סימנים, מה שאומר שצריך לפחות 3 בתים כדי למספר את כל התווים ביוניקוד.
מחרוזת ביוניקוד היא בסך הכל סדרה של מספרים, כאשר כל מספר הוא המיקום של אות מסויימת בטבלא.
מקובל לסמן תו יוניקוד בסימן כמו U+0041, כאשר U+ אומר שזה יוניקוד והמספר שאחריו הוא קוד האות בבסיס הקסדצימלי.
לא במקרה, 128 התווים הראשונים ביוניקוד הם בדיוק אותם 128 התוים הראשונים באסקי וברוב קידודי הCode page.
המחרוזת hello ביוניקוד תכתב ככה:
U+0048 U+0065 U+006C U+006C U+006F
אם נשמור את זה, נקבל:
[code]
00 48 00 65 00 6C 00 6C 00 6F
[/code]
או
[code]
48 00 65 00 6C 00 6C 00 6F 00
[/code]
תלוי בשיטת בה אנחנו מקודדים ספרות בזכרון המחשב (Little endian או Big endian).
כדי להבחין בין שתי השיטות ישנה תוספת של התווים FE FF בתחילת מחרוזת יוניקוד (שתראה ככה או הפוך, לפי הEndianness של המכונה).
הסימון הזה נקרא Unicode Byte Order Mark, או בקיצור BOM – והוא גורם ללא מעט צרות לדפדפנים שכתובים רע.
UTF-8
באו האמריקאים ושאלו, מה אנחנו צריכים את האפסים האלו באמצע המחרוזת? הרי המחרוזת תופסת פי שתיים, והם גם מבלבלים תוכנות שמתייחסות ל0 בתור סימון לסוף המחרוזת (מקובל בC וC++).
וככה נולד UTF-8.
UTF-8 הוא שיטה לקידוד יוניקוד בקידוד בעל אורך משתנה.
כשקוראים UTF-8, מסתכלים על התו הראשון ולפי הביטים הראשונים אפשר לדעת בדיוק על כמה בתים האות הבאה יושבת.
UTF-8 הפך לסטנדרט המקובל ביותר לקידוד מחרוזות יוניקוד.
PHP ויוניקוד
PHP התמיכה של PHP 4 ו5 ביוניקוד חלקית ביותר.
מחרוזות בPHP הן בעצם סדרה של בייטים ולא יותר ולמרות שתמיד אפשר להשתמש במחרוזת PHP כדי לשמור מחרוזות בקידודים שונים – רק במקרה שהPHP קומפל עם תמיכה בmb_string יהיו לנו פונקציות מיוחדות לטיפול במחרוזות מרובות בתים.
פתרון נוסף הוא להשתמש בספריה iconv, שמוסיפה לPHP יכולות המרה של קידודים, אבל היא לא מגיעה כברירת מחדל עם PHP ומי שרוצה תוכנה שתוכל לרוץ בקלות בכל מחשב ימנע ממנה.
בPHP 6 שמתבשל לאיטו צפויה תמיכה ביוניקוד, UTF-8 וכל זה, אבל זה עדיין לא שוחרר, ואם לשפוט לפי הקצב שלוקח לשוק לאמץ את PHP5 – אז PHP6 לא יהיה רלוונטי בשנים הקרובות למי שרוצה לשחרר תוכנה שתרוץ בכל מחשב.
מכיוון שהפונקציות הסטנדרטיות בPHP תומכות בעצם רק בקידוד שבו כל אות תופסת בייט אחד, הן יכולות ליצור בעיות מעניינות.
אם תקבלו מחרוזת שמקודדת בUTF-8, נניח "שלום", ותציגו אותה בדפדפן האורך שלה יהיה 4 אותיות. אם תשתמשו בפונקצית הPHP לחישוב אורך של מחרוזות, תקבלו שהאורך שלה הוא 8 תווים, כי כל אות מקודדת בשני בתים.
אם תנסו את אותו דבר על המחרוזת המעורבת "שלום SHALOM", תקבלו שהאורך הוא 8 + 1 + 6 = 15.
לעומת זאת, אם תשתמשו בmb_strlen תקבלו את האורך הנכון.
בעיה נוספת היא בעיה של חיתוך מחרוזות UTF-8.
אם נשתמש בפונקציה wordwrap לחיתוך מחרוזות UTF8, היא עלולה לחתוך אות בין שני הבתים שלה, ובעצם להעלים אותה. לא נעים.
הפתרון שלי היה לכתוב גרסא של wordwrap שעובדת על מחרוזות UTF-8.
אפשר להבין למה מפתחי PHP מתבלבלים כשהם מתעסקים עם מחרוזות בUTF-8.
המרות וקיבועים
למרות שרוב אתרי האינטרנט בימינו השכילו לעבור לUTF-8 לקידוד של מחרוזות, עדיין יש אתרים מסויימים שמשתמשים בקידודים מבוססי Code page. למשל – מנוע החיפוש של Walla מקודד לפעמים את מילות החיפוש בכתובת בקידוד עברית 1255 (עברית חלונות), ולפעמים בקידוד UTF-8. מאוד נחמד מצידם של המפתחים לפחות להעביר את הקידוד כחלק מהכתובת (e=hew לעברית 1255 וe=utf לutf8).
לא חסרות דוגמאות אחרות, בעיקר במנועי חיפוש מקומיים (yandex.ru, mail.ru שמשתמשים בקידוד קירילי 1251) ועוד.
מכיון שאני רוצה שמילות החיפוש יוצגו כמו שצריך בFireStats, צריך להמיר את הקידודים האלו לUTF-8.
הבעיה היא שכאמור – אין תמיכה מובטחת בiconv שמאפשר המרות כאלו, ולכן נאלצתי לכתוב בעצמי ספריית המרות קטנה מקידודי codepage כלשהם לקידוד UTF8. הספריה מסתמכת על טבלאות המרה שאפשר להשיג באתר הראשי של יוניקוד.
הרעיון של הספריה הוא להמיר באמצעות הטבלא את המחרוזת ליוניקוד, ואז לקודד אותה לUTF8.
וזו האגדה על אסקי יוניקוד וUTF-8.
Loading ... Loading ...קריאה נוספת
Joel on software במאמר מצויין על יוניקוד
מצגת על השרדות עם UTF-8
שאלות נפוצות על יוניקוד וUTF-8 בלינוקס ויוניקס
Unicode Introduction and Resources
במסגרת מקצה אופטימיזציות לFireStats מימשתי מנגנון נוסף לקליטת כניסות.
המנגנון הרגיל בו כולם משתמשים היום בודק שהכניסה לא צריכה להיות מסוננת (כניסה של רובוט ידוע או IP מסונן למשל), ומכניס את הנתונים בצורה מנורמלת.
נירמול בסיס נתונים נועד למנוע כפילויות, מה שעוזר במניעת אנומליות ובחיסכון במקום. בFireStats הנרמול מתבטא בכך שכל כתובת נשמרת פעם אחת בטבלאת הURLים, כל UserAgent בטבלאת הUserAgents וכדומה. כאשר מכניסים את הנתון העיקרי של כל הכניסה, משתמשים במזהה של כל נתון מנורמל.
המשמעות של זה בזמן הכנסת הנתונים היא כזו:
הגיעה כניסה עם כתובת מסויימת, מפנה מסויים ודפדפן (UserAgent) מסויים. לכל אחד מהנתונים האלו מבצעים פחות או יותר את סדרת הפעולות הבאה:
הכנס לטבלא הרלוונטית עם INSERT IGNORE, מה שמונע שגיאה במקרה שהנתון כבר נמצא שם (הטבלאות מוגדרות לא לקבל רשומות כפולות).
בדוק מה המזהה של הנתון שהכנסנו (אם הוא נכנס, אז זה יהיה מזהה חדש, אם לא זה יהיה המזהה שנבחר בפעם הראשונה שהכנסנו את הנתון לטבלא).
לבסוף, הכנס שורה לטבלאת הכניסות תוך שימוש במזהים שמצאנו בצעדים הקודמים.
זה קצת יותר מורכב מזה כי גם צריך לזהות ולסנן כניסות מסויימות כאמור.
כל התהליך הוא איטי למדי.
יצרתי קובץ CSV עם 100,000 כניסות (מfirestats.cc) והשתמשתי בו למדידת הביצועים:
בשיטה של הכנסה מנורמלת של כל כניסה, הקצב מתחיל די לא רע עם 80 כניסות לשניה, אבל ככל שבסיס הנתונים מתמלא הוא יורד עד שמתייצב על 7-8 כניסות לשניה.
למרות שקצב כזה בהחלט מספיק לכל בלוג מצוי, הוא ממש לא מספק לאתרים רציניים יותר או לבלוגיות עתירות בלוגים.
כשהוספתי תמיכה בWPMU בFireStats 1.4, חזיתי (חודשים לפני שביצעתי את המדידות) שקצב הכניסות יכול להיות בעיה בבלוגיות והוספתי שיטה חדשה לקליטת נתונים.
במקום לקלוט את הנתונים בצורה מנורמלת, הנתונים נקלטים לטבלאת כניסות ממתינות בצורה לא מנורמלת עם INSERT DELAYED. המשמעות של הDELAYED היא שבסיס הנתונים מכניס את הנתונים בזמנו הפנוי, ולא מחזיק את הקורא עד שהנתון הוכנס ממש.
עדיין צריך לנרמל את הנתונים, ולכל כתבתי סקריפט PHP פשוט שעובר על הכניסות הלא מנורמלות בטבלא אחת אחת, ולכל אחת קורא לפונקציה הרגילה שקולטת נתונים ומנרמלת אותם, ולבסוף מוחק את הכניסה מטבלאת הכניסות הממתינות. (מנהל המערכת אחראי לדאוג שהסריפט ירוץ בפרקי זמן סבירים, למשל באמצעות cron).
אני שומע אתכם צועקים: כן, אבל זה יהיה איטי לפחות כמו קודם, אם לא יותר!
זה נכון, אבל לפחות זה מאפשר לתזמן את העיבוד של הכניסות לזמנים פחות עמוסים כמו הלילה.
חיסרון נוסף הוא שהמשתמשים כבר לא מקבלים את הנתונים בזמן אמת, אלא נתונים שנכונים נכון לזמן העיבוד האחרון של הכניסות בטבלאת הממתינים.
אחרי שמדדתי את הזמן שדרוש כדי להכניס 100,000 כניסות בשיטה הרגילה, כמובן שמדדתי את הזמן שדרוש בשיטה המעוכבת, שנועדה לשפר ביצועים.
מסתבר שבשיטה המעוכבת, FireStats קולט בסביבות ה1000 כניסות לשניה, אבל המילכוד הוא שהנתונים עדיין דורשים עיבוד כדי שיהיו שימושיים, והעיבוד יקר בדיוק כמו הטיפול הרגיל.
הצעד הבא הוא כמובן לשפר את הביצועים של העיבוד הנ"ל.
כבר מהרגע הראשון שכתבתי אותו, היה לי ברור שדרושה פה אופטימיזציה רצינית, והיה לי גם ברור שהיא תהיה מסובכת.
האופטימיזציה מתבססת על התובנה הבאה:
בתוך קבוצת כניסות שנקלטו בפרק זמן מסויים, יהיו חזרות רבות מאוד של כתובות, מפנים ודפדפנים.
מה אם במקום לטפל בהם אחד אחד, נטפל בהם בקבוצות? נניח 1000 כניסות בכל קבוצה?
במקום 1000 כתובות ו1000 מפנים, יהיו לנו משהו כמו 300 כתובות (שכוללים מפנים).
במקום משהו כמו 1000 דפדפנים יהיו לנו משהו כמו 50 או 100 דפדפנים.
עכשיו נצטרך להכניס את כל מה שחדש לבסיס הנתונים, לחלץ את המזהים שלהם, ולבסוף להכניס את הכניסות עצמן תוך שאנחנו משתמשים במזהים מקודם, רק שהפעם נכניס 1000 כניסות במכה במקום כניסה אחת.
המשמעות של זה היא בעצם לממש את הפונקציה שמכניסה כניסה בודדת – אבל לרוחב, כך שתהיה ברוחב של k כניסות (קבוע כלשהו).
המימוש של זה מורכב, ולמעשה לקח יותר מפי עשר שורות קוד מהמימוש התמים הקודם, אבל הביצועים סוכר:
מעיבוד של 8 כניסות בשניה, עליתי לעיבוד של 600 כניסות לשניה.
שיפור של פי 75!
עכשיו נשאר רק לבדוק נכונות.
אם אני לוקח חבילת כניסות נתונה, ומכניס אותה השיטה המיידית אך האיטית, או מכניס אותה בשיטה המעוכבת אך המהירה התוצאה בבסיס הנתונים צריכה להיות זהה.
לא דומה, זהה.
בהתחלה השתמשתי בmysqldump (תוכנית שמגיעה עם mysql כדי לגבות את בסיס הנתונים) כדי לשמור שני קבצים, מתוך כוונה להשוות אותם.
מסתבר שזה לא היה רעיון כל כך מוצלח, כי היא הפיקה שורות ארוכות מאוד מאוד, שגרמו לרוב תוכנות ההשוואה שניסיתי להתבלבל או פשוט להיות לא שימושיות.
הצלחתי לדעת שיש בעיות, אבל לא הצלחתי לזהות אותן.
אחרי חיפוש קצר מצאתי את phpsqldiff, תוכנת קוד פתוח שמאפשרת השוואה של טבלאות.
phpmysqldiff מסוגלת לומר בדיוק מה נוסף, מה ירד ומה השתנה בין שתי טבלאות, ובעזרתה מצאתי בדיוק מה שגוי ומשם הדרך לפתרון היא די קצרה.
אני שוקל ברצינות להפוך את שיטת קליטת הכניסות הזו לשיטה היחידה, אבל בשביל שזה יקרה היא תצטרך להיות יותר ידידותית למשתמש הפשוט:
למשל אם תהליך העיבוד יתבצע אוטומטית פעם ב10 דקות, ואולי אפילו בכל פעם שמנהל האתר בודק את הסטטיסטיקות.
מימוש כזה יגרום לעסק להיות שקוף, תוך הורדה משמעותית מהעומס על השרת.
זה עדיין לא הסוף של מקצה שיפור הביצועים: אני עדיין צריך לשפר את הביצועים של השאילתות, אבל זה בהחלט צעד חשוב בכיוון.