הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
C++/C, עיבוד טקסט ומה שביניהם...
כחלק מהעבודה על CppCMS רציתי להוסיף מודול פשוט שיאפשר להכין תוכן מאמרים. לפני עמדו שתי אפשרויות:
- להכניס איזשהו מודול שצד הלקוח -- אחד מעורכי JavaScript הנפוצים שנותנים סביבת WYSIWYG "הנוחה".
- להכניס רכיב שיודע לתרגם איזשהו סוג של markdown ל-html.
הפתרון הראשון מביא מספר בעיות:
- אני לא סובל WYSIWYG באופן כללי ומתעצבן בכל פעם מחדש שאני עורך כתבות בבלוג הזה. כי יש תמיד משהו שמתנהג לא כמצופה.
- מעטים מעורכי WYSIWYG תומכים בעברית כראוי.
- מעטים מהם תומכים בכל הדפדפנים כולל Konqueror. (למשל, אני לא יכול לעבוד איתו ב-WordPress וזה די מעצבן).
אז התחלתי לבדוק את נושא markdown, כי הסימנים שלו נייטרליים לכיווניות, מה שהופך אותו לכלי מאוד אטרקטיבי לכתיבה בעברית; ובאופן כללי הוא די נוח לעבודה. כאן הציפתה לי הפתעה: לפי ויקיפדיה, ל-markdown יש מימוש ב-13 שפות החל מהנפוצות כמו PHP/Python/Perl/C#/Java ועד ליחסית אקזוטיות כמו Haskell או Lisp, אבל מה... אין C++/C. זה היה די מאכזב, אפילו שקלתי לבדוק כיצד לקרוא ל-Haskell מתוך C על מנת להתממשק עם ספריה מוכנה.
אז התחלתי לחשוב: "מה הגורם לכך ש-markdown עדיין לא מומש בשתי השפות הנפוצות האלה. ואז הבנתי שההבדל בין כתיבת parser כלשהו בשפות *P למיניהם לבין כתיבת parser כזה ב-C++/C הוא קודם כל דרך החשיבה.
המשך...המחיר של IO.
בעקבות העבודה של על CppCMS החלטתי לבדוק מס' פתרונות שיאפשרו גישה מהירה לנתונים נפוצים, למשל, פרופילים של משתמשים, ניהול sessions ועוד. נתונים שהגישה אליהם מבצעת בד"כ באופן אקראי ולא סדרתי, כמו למשל, 10 הודעות ראשונות בדיון בפורום. לפני עמדו מספר אפשרויות:
- להשתמש בבסיס נתונים רגיל כמאגר איכסון ולכתוב מערכת caching פנימית המשותפת ל־threads שונים (למשל מבוססת על STL map).
- להשתמש בפתרונות קיימים -- SQL עם memcached.
- להשתמש ב־Berkeley DB.
הפתרון הראשון נראה כמעניין ביותר אבל הוא בעייתי ברגע שצטרך לחשוב על scaling -- אז תמיד צריכה להיות אופציית "גיבוי" של SQL+memcache. בנוסף הוא נוטה להפוך ליותר מורכב אם נרצה לשתף את המידע בין תהליכים דרך זכרון משותף, מפני ש־map רגיל לא יעבוד.
הפתרון השלישי דורש שימוש בספרייה חיצונים עם רישיון דמוי GPL, ושוב, ברגע שנדבר על scaling נצטרך לבצע DB Replication וזה גם לא כל־כך פשוט.
אז עשיתי השוואת ביצועים קצרה בין שלושת הפתרונות השונים מבחינת המחיר שלהן.
המשך...CppCMS -- הצצה הראשונה.
כפי שסיפרתי בפורום ב־WhatsUp, בזמן האחרון אני מפתח Web Development Framework ב־++C. הפרויקט מתארח ב־cppcms.sf.net. לאחר מספר שבועות של עבודה בערבים, הגעתי לאיזשהו בסיס הראשוני שמאפשר לצלול לכתיבת מערכות התוכן עצמן ב־++C בצורה מהירה. רבים מהרעיונות שנכנסות למערכת למעשה נלקחו מ־Django (כמו למשל טיפול ב־URL).
הרכיבים שנכתבו הם:
- תשתית הפעלה.
- תשתית ליצירת תבניות (templates).
- תשתית לעבודה עם nice urls.
- עבודה מול MySQL ב־++C שמשתלבת עם CppCMS. מתוכנן ממשק אחיד למספר בסיסי הנתונים חופשיים -- PostgreSQL, Sqlite3, MySQL בעתיד.
- ניהול הגדרות מרוכז.
אני אספר כאן על כל הרכיבים האלה ועל מפת הדרכים של הפרויקט.
המשך...צוואר בקבוק של מערכת תוכן הוא בסיס נתונים, האומנם?
עודכן 02/11/2007.
לאחר סדרת הפוסטים בנושא ביצועים (כתיבה ב-++C, וורדפרס, מדידות) הכנתי חומר שמסכם את נושא הביצועים ומביא סדרת מדידות שמכינות בסיס קצת יותר מוצק לכל הנאמר וממחישות שלא כל מה שמקובל לחשוב עליו כבעיית הביצועים היא באמת בעיה. בנוסף, כנראה גם אני נפלתי לאותה המלכודת כשהתייחסתי לבסיסי נתונים בצורה לא לגמרי נכונה.
המשך...ביצועים של מערכת תוכן... מה נדרש באמת.
בזמן אחרון כתבתי לא מעט פוסטים בנושא ביצועים של מערכת תוכן. השאלה היא כמה שאילתות בשניה מערכת תוכן אמורה לדעת לספק על מנת שהיא תחזיק מעמד תחת עומסים שהוגדרו מראש.
התשובה הנאיבית היא: אם אני מצפה 5000 ביקורים בשעה, אז היא צריכה לעמוד בכ-1.4 שאילתות בשניה. אבל התשובה הזו מטעה. הרי לא כולם מבקרים בצורה אחידה. בהחלט יכול לקרות שבאותה שניה כעשרה מבקרים ינסו לגשת לאותו הדף ו... לקבל זמן תגובה בלתי סביר. מצד שני, אם 1000 מבקרים ילחצו על אותו הקישור באותו רגע אז סביר להניח שגם מערכות תוכן חזקות במיוחד לא יעמדו בעומס. אפילו שההסתברו שזה יקרה היא מאוד נמוכה צריך לקחת אותה בחשבון. לכן, אנחנו צריכים להתבונן במספר פרמטרים:
- מספר המבקרים המצופה בפרק זמן מסויים.
- מה האי זמינות (downtime) הגבוהה ביותר שאנחנו יכולים להרשות לעצמנו עבור האתר. למשל, אני רוצה שלכל היותר במשך 30 שניות מקסימום במהלך אותו פרק זמן לא יהיו עיכובים.
