מאמרים בנושא ‏תכנה ומחשבים‏.

האם בסיס הנתונים הוא צוואר הבקבוק של המערכת?

ב־יום שישי, 10 באפריל 2009, מאת ארתיום; פורסם תחת: תכנה חופשית, אינטרנט, פיתוח, תכנה ומחשבים; ‏17 תגובות

אחת הדעות המקובלות בקרב מפתח Web היא שבסיס הנתונים הוא צוואר בקבוק של המערכות. בסופו של דבר, אם יש המון נתונים והחיפוש לוקח O(\log n) אז אין מה לעשות. ברמה תיאורתית זה נכון.

אם יש לך בסיס נתונים של 1,000,000‎Gb (שזה 2^{15}‏‎) אז כנראה החזקה מספיק גדולה ואין משמעות לטכנולוגיות אחרות... השאלה היא האם זה נכון?

כידוע, מודל הסיבוכיות הוא עובד יפה כשמדובר במספרים גדולים מספיק ונוהג להתעלם מקבועים. מסתבר שהקבועים הם מספיק חשובים.

כדי להבין את זה, נקח כדוגמה את אחד הפרוייקטי ה־web הגדולים --- wikipedia או ליתר דיוק את חוות השרתים של wikimedia‏.

נתונים גולמיים:

  • בחוות השרתים נמצאים כ־300 שרתים שונים.
  • מתוכם במסלול הראשי‏:
    • 95 שרתי Squid -- מה שנקרא Upstream cache שנותנים מענה לכ־78% מכל הבקשות (hit ratio שלהם).
    • 144 שרתי Apache+PHP. שנותנים מענה ל־25% הנותרים.
    • 20 שרתי MySQL שונים הרצים בתצורות Master Slave השונות.
  • השרתים האחרים נותנים מענה לחיפוש, טיפול בקבצים סטטיים ועוד.
  • מנגנון memcached משפרים ב‏־7% הנוספים את היעילות של יצירת התוכן ע"י שרתי Apache.

לכן כיצד שרתי SQL יכולים להוות צוואר בקבוק של המערכת אם הם מהווים פחות מ־10% מכל השרתים הקיימים בחווה? בהנחה שהמערכת שנבנתה ע"י media wiki היא מאוזנת, ברור לנו שרוב העומס החישובי נופל דווקא על שרתי apache המריצים את PHP.

אז האם באמת בסיס הנתונים הוא צוואר הבקבוק?

יותר מחשבים יותר ביצועים?

ב־יום שישי, 10 באפריל 2009, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, פיתוח, תכנה ומחשבים, CppCMS; ‏0 תגובות

כשבניתי CppCMS תמיד לקחתי בחשבון ששרת יחיד לא תמיד יוכל להבטיח ביצועים מספיק טובים של שירות web עמוס. לכן, תמיד בתכנון המערכת, לקחתי בחשבון את האפשרויות של scale up.

בהחלט, הרבה יותר קל לתכנן מערכת שרצה על מחשב בודד עם זכרון משותף עם cache נגיש בצורה יעילה ועוד. אבל, במציאות זה לא יכול להיות. מערכות שמסוגלות לעמוד בעומסים גובהים הן בסופו של דבר חייבות להיות מוכנות לפעול בצורה מבוזרת.

לאחרונה הצלחתי להשיג גישה זמנית לרשת מחשבים חזקים במיוחד: Intel עם 4 ליבות שרצים ב־2.4GHz ו־4GB של זכרון. כך יכולתי לבדוק את מנגנון ה־cache המבוזר בעובד מעל TCP/IP ולהבין כמה אני מפסיק כתוצאה מביזור:

#   Local  Distributed
1   5,500   5,500
2  11,500   9,500
3  15,200  13,500

הטבלה מציגה את מספר הדפים בשניה שהמערכת wiki שבניתי מסוגלת לספק תחת הנחה של פגיעה 100% ב־cache (בגלל אילוצי הגישה לא יכולתי לשנות את הפרמטר). מספר השרתים הוא בין 1 ל־3 ומנגנוני ה־cache הם: cache המקומי הלא־מסונכון ו־cache המבוזר המסונכרן באופן מלא.

אפשר לראות, מחשב בודד מסוגל לייצר כ5 וחצי אלפי עמודים בשניה והמספר הזה הולך וגדל בצורה קרובה ללינארית עם שימוש ב־cache מקומי (כצפוי). שימוש ב־cache המבוזר מעל TCP/IP מקטין את מהירות הכוללת של המערכת אך עדיין שיפור ביצועים נשאר קרוב ללינארי.

יש לציין שהצלחתי למלא כמחצית מרוחב הפס של רשת 1GBit.

כמובן הניסוי הוא די מלאכותי, אבל הוא נועד בעיקר לבדוק עד כמה מנגון ה־cache המבוזר הוא יעיל. אני לא מביא לכאן פרטים מדויקים של ניסוי מפני שהוא היה יותר ניסוי פנימי, אבל בסה"כ הוא נותן הבנה של סדרי הגודל של מה שהמערכת מסוגלת לספק.

הכרות עם Java.

ב־יום רביעי, 1 באפריל 2009, מאת ארתיום; פורסם תחת: פיתוח, תכנה ומחשבים, C++‎‏; ‏12 תגובות

למרות שכבר יצא לי לדבג קוד שכתוב ב־Java לא הייתה לי התנסות מעמיקה עם שפת התכנות הזו. כלומר, אני מכיר את עקרונות הפעולה שלה... אבל לא עבדתי אתה הרבה.

לאחרונה, התחלתי לכתוב יישומים ויישומונים ב־Java ביניהם רכיבי GUI קטנים. הסיבות לכך היו שניים:

  1. דרישת הקורס -- הגשת תרגילים ב־Java.‏
  2. צורך לכתוב רכיבי GUI בלתי תלויים בפלטפורמה גם למערכות אקזוטיות ביותר כמו OpenVMS.

אז התחלתי להשתמש בה קצת יותר לעומק ו־... התחלתי להפנים כמה דברים מעניינים:

  1. יש דור מתכנתים שמקולקלים ע"י Java וחושבים במושגים שלה גם בשפות תכנות אחרות.
  2. Java היא בהחלט שפה יפה... יפה בפשוטתה המוחלטת הגובלת באמירה --- "כל המתכנתים מטומטמים"

עכשיו נסכם בקצרה

המשך...

שדרוג ל־Lenny

ב־יום רביעי, 25 בפברואר 2009, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, תכנה ומחשבים; ‏3 תגובות

הגיע זמן לשדרג ל־Lenny, אומנם הוא הגיע כבר לפני הרבה זמן אבל Lenny עוד לא הגיע ;). אקדים ואומר, זה היה אחד השדרוגים הפשוטים ביותר שיצא לי לעשות אי פעם.

  • כששדרגתי Breezy ל־Dapper השדרוג נתקע באמצע ומצאתי מערכת לא שמישה, בלי חיבור לאינטרנט, אם כי בסוף הצלחתי להחלץ מזה.
  • כששדרגתי Sarge ל־Etch בגלל התנגשויות חצי מהחבילות הוסרו כולל Office ו־Gnome והייתי צריך להחזירם באופן ידני, שלא לדבר על כמה פעולות אחרות שהיה צריך לעשות.
  • שדרוג ל־Lenny היה לפי הכתוב... פשוט לשדרג.

קודם כל עברתי על הוראות שדרוג. מי שחושב ש־apt-get dist-upgrade ועושה את העבודה טועה!

תהליך שאפשר לסכם אותו בקצרה בשני שלבים:

  • שדרוג aptitude לחדש.
  • ביצוע aptitude dist-upgrade.

אם לא תלכו כך לא תצליחו, חייבים קודם את ה־aptitude החדש.

בנוסף לבעיות הרגילות בשדרוג, היו לי עוד כמה נקודות לציון:

  1. היה לי רק 1G פנוי במחיצת / שלא הקל על התהליך
  2. אני משתמש גרסת vserver של הקרנל, כך שעבורו אין דרייבר nvidia כחבילה.

נתחיל בסיפור

המשך...

לא רק GCC, או הניסיון הקצר עם קומפיילר של Intel.

ב־יום ראשון, 22 בפברואר 2009, מאת ארתיום; פורסם תחת: לינוקס, תכנה ומחשבים, C++‎‏; ‏0 תגובות

בד"כ אני לא נוהג לכתוב כאן הרבה על טכנולוגיות סגורות, במיוחד לכתוב דברים טובים. אבל הפעם יהיה קצת שונה. אעשה סקירה קצרה של קומפיילר של אינטל.

רקע

אף אחד לא אוהב Vendor Lock In אפילו עם מדובר במשהו טוב כמו GCC או Linux. לכן, אני מוודא כי CppCMS ירוץ גם על BSD וגם על Solaris. אבל עם קומפיילר היו לי קצת יותר בעיות. יש מעט מאוד קומפיילרים טובים והנפוץ בין כולם הוא כמובן GCC.

הרבה זמן היו לי תהיות לגבי זה, אפילו ניסיתי להתקין SUN Studio על OpenSolaris ב־Virtual Box, אבל... בינתיים Solaris לא מתנהג יפה אפילו עם GCC.

אז בסופו של דבר אחרי הרבה ייסורים והתקלויות החלטתי לעשות בדיקה ל־icc. התהליך היה מייגע, אבל בסופו של דבר קיבלתי כמה דברים ממש נחמדים שאספר עליהם כאן.

המשך...

העמוד הבא

העמוד הבא

דפים

נושאים