זהו benchmark עבור 3 שיטות שונות לשליפת configs המאוחסנים בצורה שונה.

שיטה הראשונה, היא איחסון ה-configs בקבצים בתוך מערך, כאשר המפתח של האיבר מציין את שם הקונפיגורציה, והערך של המערך מציין את הערך המתאים עבור הקונפיגורציה הזו.
בשיטה זו, לכל קבוצת קונפיגורציה (או configuration group) יש קובץ נפרד שבו היא מאוחסנת.
יתרון שיטה זו הוא שניתן לאחסן כמות בלתי מוגבלת (תיאורטית) של ערכים מסוגים שונים, וזה כולל את הסוגים של PHP שהם: boolean, null, string, numbers. וכל זה עוד מבלי שאצטרך להגדיר באופן ספציפי את סוג הערך (כמו שמבצעים בהגדרת טורים במסד נתונים). יתרון נוסף (ואולי קטן) זה שלא צריך לפתוח חיבור למסד הנתונים בשביל להשיג את המידע.
החיסרון הוא, ובכן אני לא מצליח לחשוב על אחד כזה כרגע. בעצם אולי החסרון היחיד זה שכאשר מבצעים גיבוי ל-DB, המידע שבקבצים (כלומר קונפיגורציה, במקרה שלנו) לא ייכלל בגיבוי. אבל זה שטויות כיוון שאפשר לגבות את הקבצים בקלות...

שיטה שנייה, זה איחסון הנתונים בטבלה ב-DB, כאשר השם של הטור הוא השם של הקונפיג, והערך שבשדה זה הערך המתאים.
בשיטה זו, כל קבוצת קונפיגורציה היא רשומה נפרדת בטבלה.
יתרון - אין משהו ניכר.
חסרון - יש הגבלה עבור סוג המידע (צריך להגדיר את סוג הערך שבטורים ואנו מוגבלים אליו, אלא אם נשנה אותו). יש הגבלה עבור גודלו של המידע, בהתאם לסוג הטור שהגדרנו. צריך לפתוח חיבור למסד הנתונים כדי להשיג מידע.

שיטה שלישית, זה איחסון הנתונים בטבלה ב-DB, כאשר יש רק 4 טורים של: cfg_key, cfg_id, cfg_name, cfg_value. קבוצות הקונפיגורציה נבדלות אחת מהשנייה לפי הערך שבשדה cfg_key.
קבוצת קונפיגורציה אחת עלולה לכלול X שורות.
יתרון - אין משהו ניכר.
חסרון - כמו של השיטה השנייה... בעצם כאן אנו יותר מוגבלים כיוון שהטור cfg_value צריך להתאים לכל הערכים שיכולים להיות למידע של כל הקונפיגורציות שנשים. לא מסובך להסתדר עם זה, אבל עדיין זאת מגבלה...

תוצאות הבדיקות בקובץ הבא:
results.txt

הקובץ שאיתו ביצעתי את הבדיקה הוא:
fetching_rows_VS_include.php

יש לציין שהפעם עשיתי את הבדיקות בדיוק הגבוהה ביותר האפשרי: עבור כל סוג של שיטה, גרמתי לשאר השיטות להיחשב כהערה (php note) על מנת שלא יעמיסו על הבדיקה של השיטה הספציפית, ווידאתי שה-CPU מיוצב על 99% פנוי. כמובן שיצאתי מתוכנות מיותרות שלא יפריעו...
בנוסף הרצתי את הלולאה (שבודקת את הזמן) פעם אחת בלבד. כל תוצאה רשמתי בקובץ results.txt ובסופו של דבר עשיתי ממוצע. 12 בדיקות לדעתי מספיקות...

המסקנה היא שהשיטה של הקבצים מהירה ב-160% (כאשר גודל המידע סטנדרטי) ולמעשה טובה יותר ונוחה הרבה יותר, מהסיבות שאין מגבלה לגודל המידע ואפשר להכניס מידע מגוון (כל סוגי ה-scalar ו- null). בנוסף יש גישה למידע דרך הקבצים, שזו עוד נוחות אקסטרא. הבעיה היחידה היא כאמור, הגיבוי...

המקרה היחידי שבו שיטת הקבצים הייתה איטית יותר, זה כאשר גודל המידע היה עצום (לדוגמא, 60,000 תוים עבור קונפיג\אלמנט\אובייקט\איבר אחד!), ואז האיטיות הייתה ממש בולטת., יחסית ל-2 השיטות האחרות. אבל מכיוון שמידע שהוא קונפיגורציה לא אמור להיות כל כך גדול, המקרה הזה זניח ולדעתי אין להתחשב בו.

בקובץ הבדיקה התייחסתי ל- configuration groups בתור מידע הקונפיגורציה שהוגדר עבור אלמנט מסויים. לדוגמא, להגדרות החיבור של מסד נתונים יש קבוצת קונפיגורציה אחת, ובקבוצה זו יש כמה אלמנטים של mysql_user, mysql_server, mysql_password וכו'...

אני מצרף פונקציה מ- Framework שלי שמקבלת קובץ config:

קוד PHP:

 // Configuration vendor
function getConfig($filename, $lib = 'core', $global = array()) {
    static $libs    = array('core' => 'core/', 'module' => 'modules/');
    
    if(isset($libs[$lib])) 
        require($libs[$lib].$filename.'.ini.php');
    else 
        require($libs['module'].$lib.'/'.$filename.'.ini.php');
        
    return $config;
} 


המערך שבקובץ חייב להיות config אבל לי אישית לא אכפת.
ייתרון נוסף זה שאפשר ליצור ככה קובץ config דינאמי, ובשביל זה הארגומנט global$
ניתן להעביר לפונקציה איזה משתנה שבא לך

תודה על הקוד

לא הבנתי איך משתמשים בארגומנט global ?

זה פשוט מערך שאתה יכול לשים בו מה שאתה רוצה.. למשל אם אתה רוצה להעביר את המערך של השפה אז אתה עושה ככה:

קוד PHP:

 $data = getConfig('main', 'core', array($lang)); 


אבל למה להעביר אותו אם לא משתמשים בו בפונקציה..?
יש לך מקרים שבהם הקובץ שאתה מאנקלד צריך את המשתנה global?

הפונקציה אולי לא צריכה, אבל הדף שהפונקציה מוסיפה יכול להשתמש בה, במקרה הצורך..

שמירה של נתונים ב-DB גוררת הרבה OVERHEAD, ובחיים לא תיהיה מהירה כמו גישה לקבצים.
אבל, וזה אבל גדול,
DATABASE נותן לך הרבה דברים שגישה לקבצים לא, כמו למשל אפשרויות סינון, חיבור ובכלל הפעלת לוגיקה על המידע. נניח ואתה בונה עכשיו מערכת ממש גדולה, אתה לא חייב לטעון את כל הקונפיגורציות כל הזמן, כי כל פעם רק חלק מהן פעילות, זה משהו שתוכל לבצע בקלות ב-DB, בעוד שבקבצים זה ייקח לך יותר זמן תכנות, וייתן לך הרבה פחות גמישות.

דברים נוספים שכדאי לחשוב עליהם כשבוחרים אם להכניס מידע לקובץ או ל-db (כל מידע, לא רק קונפיגורציה) זה ש-DB נותן לך עוד הרבה דברים שבתחילה לא נראים חשובים אבל הם כן:
מקביליות (גישה של הרבה קודים לאותו מידע) ,
ביזוריות (תמיד אפשר להשתמש במספר שרתים, או למשל, שהמידע שאתה מעוניין יישב על שרת אחר מאשר זה שמריץ את קוד ה-PHP שלך),
אמינות (מה קורה אם סקריפט שלך מעדכן את המידע והשרת מת באמצע?),
ניהול cache (כשיש לך קובץ קטן זה לא משנה, כשיש לך מאות מגה של נתונים אתה מסתמך על ניהול הcaching של מערכת ההפעלה, שלא מותאם לסוג הפעילות שלך במידע, לעומת DB שיש לו כל מיני אופטימיזציות ויכול לספק לך אפשרויות אופטימיזציה מתקדמות)
ועוד כל מיני פיצ'רים שיש למערכות DB שונות...

נכון, תודה על ההוספות והפירוט

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

ציטוט:

אתה לא חייב לטעון את כל הקונפיגורציות כל הזמן, כי כל פעם רק חלק מהן פעילות, זה משהו שתוכל לבצע בקלות ב-DB

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

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

סתם לידע כללי :-)

כמה פעמים במהלך הריצה של המערכת שלך אתה מתכוון לקרוא מחדש את הקונפיגורציה?

אם אתה משתמש ב CACHE נורמאלי עבור הקונפיגורציה
ובמנגנון שמיידע את המערכת שיש צורך לטעון את הקונפיגורציה מחדש כי בוצע שינוי

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

_________________________________________________

אזהרה: משרד הבריאות קובע כי העישון מזיק לבריאות !
תראו, אפילו החייזר נהיה ירוק מזה

מנהל פורום מדע בדיוני ופנטסיה ופורום מדע טכנולוגיה וטבע בפרש

אהלן המממ
הרבה זמן לא היית בפורום

למה הכוונה cache לקונפיגורציה?
מידע הקונפיג נטען למשתנה שנגיש דרך כל חלקי המערכת. --> האם לזה הכוונה?

בהתאם לעמוד הספציפי שאני מריץ, העמוד ישלף את הקונפיגורציה המתאימה לו (ממערך) וישמור את המידע במשתנה הגלובאלי. דרך המשתנה הזה המידע יהיה זמין, לכן אני חייב בכל ריצה\טעינה של עמוד לבצע טעינה של הקונפיג המתאים לו... אחרת איך אגש למידע...?

או בקיצור class object

קרא קצת על אלגוריתמים של cache כאן:
http://en.wikipedia.org/wiki/Cache_algorithms

אני מתכוון לאובייקט גלובאלי של מחלקת cache שייתן לכל מי שיפנה אליו את הנתונים המבוקשים.

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

אתה גם יכול לממש אלגוריתם "עצלן" (lazy) שיקרא את הנתונים רק בפעם הראשונה שמישהו מבקש אותם
ויוריד נתונים שלא נדרשים זמן רב.

אם המערכת שלך מבוזרת על מספר שרתים, ישנם גם פתרונות צד שלישי כמו אלה שבקישור הבא (במקרה זה בג'אוה - אבל זה לא ממש משנה)
http://www.manageability.org/blog/s...uted-cache-java

_________________________________________________

אזהרה: משרד הבריאות קובע כי העישון מזיק לבריאות !
תראו, אפילו החייזר נהיה ירוק מזה

מנהל פורום מדע בדיוני ופנטסיה ופורום מדע טכנולוגיה וטבע בפרש