שרת ה-MCP: אין תקרת גודל לגוף בקשה ואין הגבלת קצב — חל על כל הכלים

[amirbiron]

מה חסר

נמדד על הקוד של היום: ב-mcp_server/ אין שום מידלוור שמגביל גודל גוף בקשה ואין שום הגבלת קצב. המידלוור היחיד שרשום הוא PATAuthMiddleware (mcp_server/server.py), שמאמת טוקן ותו לא. כלומר כל משתמש מאומת יכול לשלוח בקשות בכל גודל ובכל תדירות.

grep "add_middleware|Middleware(" mcp_server/   -> רק PATAuthMiddleware
grep "rate.limit|RateLimit|slowapi|limiter"     -> אפס תוצאות

למה זה עולה עכשיו

PR #3428 הוסיף תקרת אורך ל-path בכלי codekeeper_docs_get_section, אחרי שנמדד שנתיב של 400KB עלה 608ms של מעבד — הגברה של פי 246 לעומת המצב לפני שסינון הסודות התחיל לסרוק כל רכיב בנתיב.

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

מה כדאי שיהיה

1. תקרת גודל לגוף בקשה ברמת האפליקציה, כך שאף כלי לא יקבל ארגומנט שגדול מסדר גודל סביר.
2. הגבלת קצב לפי זהות — הטוקן כבר מזוהה במידלוור הקיים, כלומר המפתח לספירה קיים.

מה לשים לב אליו במימוש

blanket-policy-silent-block §7 מתאר את המלכודת הקלאסית: מגבלת קצב גורפת שחלה גם על נתיבי בדיקת דופק. / ו-/health נדגמים על ידי מוניטור חיצוני בתדירות קבועה, ובלי פטור מפורש הם יקבלו 429 — והמוניטור יכריז על שירות בריא כמנותק. אותו היגיון חל על כל תעבורה לגיטימית בתדירות גבוהה.

ובאותה רוח, ומאותה סיבה שבגללה path_too_long קיבל קוד משלו ב-PR #3428: הסירוב צריך לנקוב בסיבתו. בקשה שנחסמה בגלל גודל או בגלל קצב צריכה לומר את זה, ולא להיראות מבחוץ כמו תקלה.

הקשר

התגלה בסקירת הקוד על PR #3428. הדוח המלא: code-review-3428-docs-path-policy.md ב-CodeKeeper.

[amirbiron]

עדכון מ-PR #3429 — מה השתנה במה שהגבלת הקצב צריכה להגן עליו

שני הפערים כאן עדיין פתוחים (נבדק על הענף של #3429: המידלוור היחיד הוא PATAuthMiddleware, אין הגבלת קצב ואין תקרת גוף בקשה). ה-PR לא סוגר אותם, אבל הוא משנה את התמונה בשלוש נקודות:

1. אחרי מיזוג #3429 יש תקציב זיכרון למסלול הפרסור, לא חסם. השרת לא מודד זיכרון בזמן ריצה. הוא גוזר פעם אחת בעלייה את רוחב המאגר (10 חוטים) ממגבלת הקונטיינר, ומקצה לכל חוט 35.2MiB לפי הפרסור הגדול ביותר האפשרי; החשבון מחזיק רק על מה שנמדד — RST עוין 20.1MiB אחרי תקרת הסקשנים, המסמך הצפוף ביותר 34.5MiB — ולא על קריאות הטווח של האדמין (61–77MiB, #3433) ולא על Markdown עוין (141MiB, עד תקרת טוקנים). כלום מזה לא פרוס עדיין. מה שהתקציב כן קובע: הוא לא תלוי בקצב, ולכן הגבלת הקצב אינה מה שמונע OOM. תפקידה הוא הוגנות: מאגר קבוע בלי מגבלה לפי זהות פירושו שטוקן אחד יכול לתפוס את כל עשרת החוטים, וכל השאר ממתינים בלי שום סימן (SUGG-006 ב-#3433).

2. מספרים לתמחור המגבלה — זמן מעבד לבקשה בודדת, חוט אחד, חציון של 3 הרצות (2026-09-20):

בקשה	שניות
docs_get_section, RST עוין 500KB, עם התקרה (היום)	0.24
אותו קובץ בלי התקרה (לפני 3d18b416)	0.45
docs_get_section, העמוד הצפוף האמיתי משוכפל ל-500KB	0.035
תצוגה מקדימה ל-PR 5: Markdown עוין 500KB (שורות-תבליט)	2.3
PR 5: המסמך הצפוף האמיתי (CLOUD.md) ל-500KB	0.47

השורה המודגשת היא הסיבה: MAX_SECTIONS של md_parser סופר כותרות, ולשורות-תבליט אין אף אחת, ולכן תקרת הטוקנים (#3391) היא רק חצי מהתשובה — עשר בקשות כאלה במקביל על מכסה של חצי מעבד הן כ-46 שניות המתנה לכולם. הגבלה לפי זהות היא תנאי ל-PR 5, לא שיפור אחריו.

3. too_many_sections עומד בכלל שכתוב כאן — סירוב שנוקב בסיבתו — כמו path_too_long.

תקרת גוף הבקשה אינה מושפעת מה-PR: קלט הפרסור מגיע מהמראה ולא מגוף הבקשה, והתקרה עדיין נדרשת לגודל הארגומנטים כפי שכתוב למעלה. וכלל §7 של blanket-policy-silent-block נשאר כמות שהוא: הפטור לנתיבי הדופק חייב להיות מפורש במגביל.

---

Generated by Claude Code