RSS

עקב אכילס של מערכות שו”ב ואלפלקציות גדולות

12 אוג

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

1. מפה עם מספר רב של מטרות, שמתעדכנות בקצב גבוהה, למעלה מ-ms100.

2. מספר רב של חלונות של וידיאו באפליקציה.

3. תקשורת עם מספר שרתים בקצב גבוה.

4. מספר רב של Monitors להצגת המידע, בדרך כלל לפחות 3.

5. כמויות קוד ענקיות, המון שנות אדם.

6. האפליקציה צריכה להיות מודולרית.

7. אסור שהאפליקציה תקרוס וזמן העלייה שלה חייב להיות קצר, במידה והיא קרסה.

כל מי שבונה סוג כזה של אפליקציות מגיעה מהר מאוד למסקנה שאסור שהאפליקציה תרוץ על Process אחד.

מה רע ב- Process אחד?

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

איפה אפשר לראות גישה זו?

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

דוגמא נוספת היא אופיס 2013 הדרך שבה כותבים Office Web App's, ואני מצטט:

"Apps run in a separate, isolated process. If the app crashes, Office will not be impacted, and you can just restart the app if you want. Performance issues in the app won’t impact the performance of Office. Apps are even isolated from a UI point of view. They aren’t allowed to overwrite the Office UI, or even block events, which means you can have a number of apps in your document and not worry about them all conflicting with each other and turning the Office UI into a Frankenstein experience. This is a break from past models where add-ins could block events and overwrite the ribbon, which meant that if you had more than one add-in running you could get some fairly unpredictable experiences. "

סיכום:

פירוק אפליקציות UI גדולות ל- Processesהוא בלתי נמנע. הבעיה היחידה היא שזה מסבך את הפיתוח, למשל : איך עושים Drag & Drop בין מסכים שרצים על Processes שונים. אני חושב שהגרסה הבאה של WPF צריכה להתמודד עם אתגרים אלו ולהקל על הפיתוח, כלומר שהפיתוח בין Processes באפליקציות UI יהיה כמה שיותר פשוט. כמו שעשו ל-Thread ע"י Task. כמובן שעד אז אתם צריכים לבנות סוג של תשתית שתעזור למפתחים לתקשר בין ה- Processes. אגב אם בוחנים את החידושים בחלונות 8 ,יש שם את היכולת לתקשר בין אפליקציות, אנחנו צריכים את זה בדוט-נט, כך שזה ירוץ גם על חלונות 7.

מודעות פרסומת
 
השארת תגובה

פורסם ע"י ב- אוגוסט 12, 2012 ב- Uncategorized

 

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s

 
%d בלוגרים אהבו את זה: