שאלה על cache

שאלה על cache

שלום אני בונה ספרייה שארצה להשתמש בה בהמשך גם ב- web וגם ב- windows. בין היתר מתבצעות שם שליפות ממסד נתונים. עבור חלק מהנתונים יש היגיון לשמור אותם ב- cache כלשהו כי הם מתעדכנים באופן נדיר. כפי שאני רואה יש לי 3 אופציות מרכזיות: 1. להשתמש ב- cache של asp.net. באופן מפתיע ניתן לגשת אליו גם דרך אפליקציות windows דרך HttpRunTime.Cache. השאלה היא האם נכון לעשות דבר כזה. בפרט קראתי איפשהו שגישה ל- cache הזה שלא דרך אפליקציית ווב איטית. 2. להשתמש ב- caching blocks. הבעיה כאן היא שכפי שאני מבין השיטה הנפוצה ביותר היא להשתמש ב- storage של מסד נתונים. אבל כאן בעצם עולה השאלה מה אני מרוויח, הרי כל המטרה היתה למנוע גישה למסד נתונים. (השאילתות שאני רוצה לשים במטמון גם לא כבדות) . האם יש דרך להגדיר storage מהיר יותר? 3. לבנות cahce משלי שישתמש במשתנה סטטי של המחלקה ויחזיק את המילון. מה דעתכם?
 

Justin Angel

New member
קה פרובלמה מואי צ'יקיטה?

1. גם אם ניתן לגשת ל-Cache מאפליקציה חלונאית, במחשב בלי IIS סביר מאוד להניח שסידור כזה לא ירוץ. מה שכמובן יוצר תלות מאוד רצינית על רכיב שדורש התקנה חיצונית וקנפוג. באפליקציה חלונאית, מאוד לא נהוג לגשת ל-Cache ה-Webי. 2. שימוש ב-Caching Application Block הוא אכן הפתרון הברירת מחדל. ביחס לצרכים שלך (נפח, חיפושים, חתכים) והמדיניות עבודה עם מידע שלך (מדיניות עדכונים מהלקוח לשרת ומהשרת ללקוח) יתכן וכי צריך לעבוד עם מסד נתונים לוקאלי. 3. אני מייעץ נגד זה. כמי שמעורב לעומק ב-Caching Application Block וכתב כמה DataBanks משלו, רמת הבעיות שנפתרת עבורך מהרבה מאוד בחינות היא עצומה. אישית, אני לא רואה את הטעם בלהמציא מחדש את הגלגל כדי לקבל יכולת שכבר קיימת. אני בדיוק הולך לכסות את הנושא של "Caching Application Blocks vs. Local Databases" באפליקציות Smart Client בקורס שאני מעביר כחלק מ-MVP Week. Real World Application Development By Example
 
Nil ref error

1/ אין קשר בין System.Web.Caching ל IIS. ניתן בהחלט לעשות שימוש ב Cache מאפליקציה חלונאית. ב 1.1 הדבר אינו נתמך ע"י MS אבל ב 2.0 הוא נתמך. בשניהם הוא עובד באופן מלא. 2/ באופן כללי אני לא הייתי הולך על זה אלא אם מדובר באפליקציה בה אתה רוצה לשמור על ה cache גם אחרי שסגרו את האפליקציה שלך. במקרה הזה, זה בהחלט דבר טוב. ניתן לעשות שימוש ב Local db או ב embedded db לצורך זה. 3/ ממש ממש לא ממולץ. מסובך, כואב, וסתם לא רציני בטווח ארוך (חכה לרגע בו תרצה לעשות invalidation)...
 

Justin Angel

New member
../images/Emo26.gif

זכרתי שב-1.1 זה לא היה אפשרי. חידשת לי שבדוט נט 2.0 זה אפשרי, אז דבר ראשון תודה. עוד לא ראיתי פרוייקטים שמיישמים את זה ובלי לחקור לעומק זה נשמע כמו מקום שאפשר להיכנס עליו לחור של ביצועים.
 
Nil ref error

חור של ביצועים? אני עושה הרבה מאוד עבודה על caching לאחרונה, ואני לא רואה שום סיבה לכך. ה cache של ASP.NET הינו in process - live - ככה שרוב הזמן שם עובר בחיפוש ב cache (מספר hash seeks ובדיקת ולידציה). אם כבר מדברים על זה, גם שמה מישהו פיזר internal בלי הכרה, גררר...
 

MoranOnSoftware

New member
"ישמתי" בהצלחה מרובה...

את ה- Cache של ASP.Net, מדובר בדיוק על שורה ורבע של קוד. יש איזה משהו שזכור לי בנוגע להבדל הדקיק וחסר המשמעות בין HttpRuntime ל- HttpContext, אכן סיפור מרתק. נ.ב - ג'סטין... החלטתי לבוא להרגיז את באי הפורום בהומור המשעשע שלי...מי אמר נחתום? מורן.
 

Justin Angel

New member
../images/Emo26.gif

כן. הגישה שלי בקורס היא להציג תמיד שתי אלטרנטיבות מנוגדות לכל נושא שאני נוגע בו. למשל דוגמה מהיום הראשון (ש-Caching זה דוגמה מהיום השני של ה-Smart Client) אני הולך להסביר Persistence Layers ולהדגים את DLinq ו-ActiveRecord.
 
תודה ובקשת הבהרה

למה שאני לא אשמור את ה- cache שלי בתוך משתנה סטטי באפליקציה (בצורת מילון)? ככה הכי מהיר לגשת אליו. לחילופין נדמה לי שישנו interface ב- caching blocks שדרכו ניתן להגדיר custom storage. האם מישהו מימש אותו בצורה כזו ששומרת את הנתונים בזיכרון ולא ב- DB? וגם - האם באמת יש הבדל בין שמירה בזיכרון ובין שמירה ב- DB - הרי בסופו של דבר גם זיכרון לפעמים נרשם על הדיסק, ככה שאולי אני סתם מסתבך פה...
 
Nil ref error

איך אתה הולך לטפל ב Invalidation ? האם יהיה יותר מ thread אחד שיגש לשם ? באופן כללי זה אפשרי, באופן מעשי מאוד מאוד לא מומלץ להתחיל להסתבך עם זה.
 
תשובה

תודה על ההתיחסות. יש פה כמה עניינים: 1. אני לא רוצה לבנות מחדש, היה לי נוח למעשה להשתמש ב- cache של asp.net. אני רק תוהה האם זה נכון באפליקציה וובית. 2. בנוסף יש פה שאלה עקרונית יותר לגבי caching blocks - אם השמירה שם נעשית במסד הנתונים, אז מה אני מרוויח, הרי החלפתי קריאה אחת (זולה) בקריאה אחרת (גם זולה)? 3. על פניו ה- caching של asp.net עשוי להיות יותר מהיר מ- application block כי הוא שומר בזיכרון ולא במסד נתונים (בהתאם להגדרות). אבל פה שוב אני תוהה אם זה באמת נכון, הרי גם הזיכרון לפעמים נכתב לדיסק, אז האם השמירה הזו בזיכרון באמת מהירה יותר משמירה במסד נתונים?
 

Justin Angel

New member
קה פרובלמה מואי צ'יקיטה?

Caching application block עובד בצורה שמגדירים לו DataBanks לתוכו הוא כותב ומולם הוא עובד. ברירת המחדל הוא IsolatedStorageDataBank שכותב לדיסק ב-IsolatedStorage (מקום שרק האפליקציה שלך יכולה לגשת). ניתן לכתוב Custom DataBank (עשיתי את זה מספר פעמים), אך זאת משימה עם עקומת למידה מאוד תלולה.
 
Nil ref error

1. באפליקציה לא וובית, נראה לי שאתה מתכוון. כן, זה אפשרי ובדר"כ רצוי. 2. ישנן שליפות מאוד מאוד יקרות, שאם אתה שומר את התוצאות שלהם, אתה חוסך הרבה מאוד עיבוד. מעבר לכך, לא כל ה DB נולדו שווים. יש DB לוקלי, יש מרוחק, יש מידע שאתה מקבל מ WS מרוחק, וכו'. קריאה למסד נתונים היא _לא_ זולה בשום אופן. 3. חד משמעית לשמור לזיכרון יותר מהיר ממסד נתונים או לדיסק. cache בנוי ככה שהוא לא קורא מדיסק בדרך כלל, וגם אם כן, זה קורה תחת עומסים מאוד כבדים. בכל מקרה, הרבה יותר מהר לבצע paging ע"י מערכת ההפעלה מאשר לקרוא ל DB או לדיסק. במקרה הראשון אתה משלם על קריאה מרוחקת, במקרה השני על הרבה מאוד IO שמערכת ההפעלה חוסכת.
 

MoranOnSoftware

New member
Cache זהירות...

לא לסמוך על אובייקטים שהכנסת ל- Cache, גם אם טרם עבר הזמן לו יעדת את האובייקט (בלי קשר ל- Sliding Expiration). למנגנון של ASP.Net יש יכולת לנקות אובייקטים שמבחינתו (בדגש על מבחינתו) הם לא חיוניים. מתי זה קורה? כשהזכרון במחשב מתחיל להיות משאב במחסור... ניתן לחזות בתופעת הטבע על ידי שיוך Delegate בעת ההכנסה ל- Cache נקרא (CacheItemRemovedCallback) כאשר זה נקרא בעת הניקוי של האובייקט, אחד מהפרמטרים שה- Delegate מקבל הוא הסיבה לניקוי (Enum). משעשעת במיוחד הסיבה שניתנת "Underused", מי הוא שהוא יחליט שאני לא משתמש בזה מספיק??
 

pintyo

New member
cache של asp.net. כאשר יש web farm

במקרה כזה העבודה לא תוכל להיות in process ואז בכל מקרה יישמר ב DB. האם אני צודק בעניין הזה? ואם כן, עם מה עדיף לעבוד במקרה זה
 
למעלה