ב-Edge, ברירת המחדל היא שעומס העבודה של בקשות HTTP ותשובות מאוחסן במאגר בזיכרון לפני שהוא מעובד על ידי כללי המדיניות ב-API Proxy.
אם ההעברה בזמן אמת מופעלת, עומסי העבודה של הבקשות והתשובות מועברים בזמן אמת ללא שינוי לאפליקציית הלקוח (לתשובות) ולנקודת הקצה היעד (לבקשות). סטרימינג שימושי במיוחד אם האפליקציה מקבלת או מחזירה עומסי נתונים גדולים, או אם יש אפליקציה שמחזירה נתונים בחלקים לאורך זמן.
דפוס שלילי
גישה לעומס העבודה של הבקשה/התשובה כשהסטרימינג מופעל גורמת ל-Edge לחזור למצב האחסון במטמון שמוגדר כברירת מחדל.
איור 1: גישה לעומס הנתונים של בקשה/תגובה כשהסטרימינג מופעל
באיור שלמעלה מוצגת הניסיון לחלץ משתנים מתוכן הבקשה, ולהמיר את תוכן התגובה בפורמט JSON ל-XML באמצעות המדיניות JSONToXML. הפעולה הזו תשבית את הסטרימינג ב-Edge.
השפעה
הסטרימינג יושבת, מה שעלול להוביל לזמני אחזור ארוכים יותר בעיבוד הנתונים
יכול להיות שתבחינו בעלייה בשימוש בזיכרון האשפה או בשגיאות OutOfMemory במעבדי ההודעות, בגלל השימוש במאגרים בזיכרון, במיוחד אם יש לנו עומסי נתונים גדולים של בקשות/תגובות.
שיטה מומלצת
לא לגשת לעומס התעבורה של הבקשה/התשובה כשהסטרימינג מופעל.
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2026-02-03 (שעון UTC)."],[],[]]