עבדנו בבדיקות קבלה של המשתמש (UAT) הסביבה אשר, לעומת פיתוח, הוא מת איטי.

זה סביבה מורכבת באמצעות FBA, SQL 2008, ברית המועצות, יישומי אינטרנט מורחב נגיש באינטרנט באמצעות https, אז זה היה קשה לאתר את הבעיה.

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

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

תהליך של עובד עם מזהה תהליך של ' XXX’ המשמש את מאגר היישומים ' הביתה – 80’ שלח בקשת מיחזור כי זה הגיע למגבלה שלו עבור הזיכרון הווירטואלי.

לקחתי את זה. כי הבריכה app היה מיחזור רחוק, לעתים קרובות מדי, זה יסביר את בעיית ביצועים.

הסתכלתי על המאפיינים של הבריכה app ומיחזור שלה "" דף הראה כי המאפיין "מקסימום זיכרון וירטואלי (במגה-בתים)" נקבעו true ו כדי 5000. . זה נראה מספיק, אבל אני החלטתי בטל קביעת שהערך וכי היתה השפעה חיובית מיידית. אין בריכה app עוד מיחזור. אין יותר מסתורי slow-downs ואת ההפסקות.

אני לא ממש מבינה את החומר"כבסיס" זה קורה שם, אבל ברור איזו סיבה/תוצאה הדבר קורה עכשיו, הסביבה UAT הוא שמיש.

</קצה>

מנוי על הבלוג שלי.