הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא פיתוח.
Sqlite - עבודה עם WAL.
אומנם גרסה 3.7 של Sqlite שוחררה יותר מלפני שנה, לא רבים שמו לב לשורה הקצרה ברשימת השינויים:
Added support for write-ahead logging.
זאת שיטת עבודה שכל בסיס נתונים מודרני עובד איתה, לעומת שיטת העבודה הרגילה של Sqlite3 והיא ניהול "לוג לשחזור לאחור" - Rollback.
כיצד קובץ Rollback עובד. בכל פעם שרוצים לעשות שינויים בדף של קובץ בסיס הנתונים, רושמים את הערכים בקודמים בקובץ במיוחד. כך שאם ניפול, נדע בדיוק איך לשחזר את המצב הקודם. אז בכל טרנזקציה Sqlite3 מבצע את הפעולות הבאות: רושם את הכל המחיקות לקובץ rollback ומבצע fsync עליו, לאחר מכן מעדכן את בסיס הנתונים הראשי ומוודא כי הנתונים הגיעו לדיסק עם fsync נוסף ובסוף מוחק את קובץ ה־rollback. מה שחשוב כאן זה שקריאת מערכת הפעלה fsync, מתבצעת פעמיים: פעם על קובץ לוג ופעם על הקובץ הראשי. הקריאה הזו מבטיחה שהמידע הגיע לדיסק פיזי והיא כמובן מאוד יקרה מבחינת הזמן.
השיטה החדשה שמומשה בגרסה 3.7, עובדת עם קובץ WAL - Write Ahead Log. כל שינוי נרשם לקובץ הלוג והקובץ המקורי נשמר ללא שינויים. מה שחשוב כאן שכדי להבטיח שרידות מספיק לקרוא fsync - פעם אחת בלבד עבור קובץ WAL. הטרנזקציות הבאות יוסיפו עוד מידע לסוף הקובץ. אחת לכמה זמן sqlite3 מעביר את כל השינויים לקובץ בסיס הנתונים המקורי ומאפס את קובץ הלוג. יותר מזה, כיוון שהקובץ המקורי נשאר ללא שינויים אז טרנזקציות קריאה יכולות לרוץ במקביל לטרנזקציות כתיבה.
השיטה החדש מבטיחה מהירות ביצוע טרנזקציה גבוהה יותר בגלל ש־fsync נקרא רק פעם אחת. בנוסף וגם עדכונים לא מעכבים את טרנזקציות השליפה.
כך שאם אתם משתמשים פעילים של Sqlite3 - תבדקו את האופציה
PRAGMA journal_mode=WAL;
היא יכול לשפר משמעותית את היישומים שלכם.
בנוסף עם תמיכה ב־WAL, התווספה עוד אופציה מעניינת שמאפשרת להאיץ פעולות עדכון של בסיס נתונים בצורה משמעותית בלי לפגוע בקונסיסטינטיות שלו. כלומר לוותר על ה־D של ACID.
אם מגדירים
PARAGMA synchronous=NORMAL
אז במצב של WAL ה־fsyncים שמבטיחים את ה־D - Durability ייקראו רק פעם ב־checkpoint ולא כל טרזקציה. אם המחשב קורס (חשמל/חומרה) אז אנחנו נאבד מספר טרנזקציות אחרונות אבל בסיס הנתונים יישאר תקין, במילים אחרות, אנחנו ניפול בגבול טרנזקציה, אבל לאו דווקא הטרנזקציה האחרונה. שיטה זו מאפשר להגדיל מספר עדכונים מכמה עשרות בשנייה לכמה אלפים.
גם חלק מבסיסי הנתונים הגדולים תומכים באפשרות העבודה ב־ACI ללא D.
למשל, ב־PostgreSQL ניתן להגדיר אופציה synchonous_commits=off ברמת הקשר. אז עדכון הלוג יתבצע ללא fsync ורק פעם בשניה יתבצע עדכון מלא. בבסיס הנתונים MySQL אפשר להגדיר את זה בעזרת אופציה innodb_flush_log_at_trx_commit=2, אבל ההגדרה הזו תעבוד ברמת שרת MySQL כולו ולא רק ברמת הקשר או בסיס הנתונים הספציפי.
שימוש באופציות כאלה מאוד משפר ביצועי העדכונים. אפשר וכדאי להשתמש בהן כשיש חשיבות לטרנזקטיביות, אבל זה ממש לא קריטי לאבד מספר טרנזקציות אחרונות במקרה של קריסה.
שוחררה גרסת 1.48 של Boost שמכילה Boost.Locale
סוף סוף שוחררה גרסה 1.48 של Boost. אחד הדברים המשמעותיים בה היא שילוב של Boost.Locale - ספריית הלוקליזציה שאני פיתחתי.
קישורים:
- אתר הפרויקט: http://www.boost.org
- הודעת שחרור: http://www.boost.org/users/history/version_1_48_0.html
- תיעוד Boost.Locale: http://www.boost.org/libs/locale/index.html
להזכירכם, Boost.Locale פותחה כחלק מפרויקט CppCMS
כמה מטומטם ה־API יכול להיות
היום בניה לילית נתקעה... מכונה וירטואלית של חלונות לא ירדה.
תוך כדי בירור נכנסתי למכונה וגיליתי חלונית עם הודעה בסגנון:
The library e:\mingw\lib\libsqlite3.dll is not valid windows library. Reinstalling
application may solve the problem
אני מכיר את הבעיה שאם אתה מריץ תוכנה שחסר לה dll אז קופצת חלונית. אפשר להבין התנהגות כזו. רק שבמקרה הספציפי הזה: מדובר בטעינה דינאמית של dll עם LoadLibrary...
אני מצפה שפונקציה תחזיר שגיאה ולא תציג חלון! אחרי חיפוש קצר הגעתי לפונקציה SetErrorMode... שמאפשרת "לפתור" את הבעיה. אבל באמת... אם אין dll אז LoadLibrary יחזיר שגיאה אבל אם ה־dll לא ניתן לטעינה תקפיץ חלון?!?!
מי האידיוט שתכנן את ה־API הזה... בחלום הרע שלי לא הייתי מצפה להתנהגות כזו!
בקיצור: אם אתם לא חייבים אל תפתחו לחלונות!
למה אצלם זה אף פעם לא עובד? או מדוע IIS+FastCGI לא מה שחשבתם...
זה כבר לא בפעם הראש שואלים אותי אם ניתן להריץ את CppCMS עם IIS.
לכאורה, IIS תומך ב־FastCGI וזה הממשק העיקרי של CppCMS, אז לא אמורה להיות כאן בעיה.
אז מה צריך? להגדיר לעבוד בממשק TCP, להגדיר את הפורט שעליו השרת שלי מאזין? נשמע פשוט, אבל זה לא בדיוק עובד.
IIS לא מאפשר להגדיר פורט! הוא לא רק לא תומך בשרתי FastCGI חיצוניים הוא מחייב את השרת להשתמש ב-Socket שהועבר דרך StdIn, רק שבחלונות Stdin הוא לא בדיוק file descriptor וצריך לעשות שמיניות באוויר כדי לקבל ממנו את ה-socket שעליו עושים accept.
אבל, נגיד לא נורא, אז נשתמש ב-socket שקיבלתי מהשרת כמו שזה נעשה בד"כ גם עם שרתים ב-Linux.
זה עדיין לא יעזור! הוא לא יעביר בקשרות לשרת במקביל, הוא פשוט מניח שכל תהליך FastCGI, הוא Single-Threaded ומיועד לטפל בבקשה אחת בו זמנית, כמו ש-PHP עושה.
ראה: http://forums.iis.net/t/1155551.aspx
במילים אחרות גם אם אני אפתור את הבעיה הראשונה (הלא מסובכת) המערכת שלי לא תוכל להנות ממקביליות, משמע אין שיתוף cache, אין תמיכה ב-Comet ועוד.
בקיצור... IIS+FastCGI זה זבל שנכתב במטרה אחת בלבד: להגיד ש־PHP רץ על IIS.
אני הולך לבדוק את ההרחבה isapi_scgi, אם כי אני כבר יודע שהיא לא ממש תומכת ב־SCGI בצורה נכונה כי לא מטפלת ב־Status כראוי.
הפוסטר והמצגת מאוגוסט פינגווין
אני מפרסם כמו שהבטחתי את המצגת והפוסטר מהכנס:
