--load: notification fan-out load (resources/subscribe across many sessions)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
Hướng nghiên cứu
Start by reading the --load and --load-connections implementations to understand request timing and multi-connection handling; the issue does not name file paths. Then trace how resources/subscribe and notification delivery are represented, and decide how to measure subscribe cost, per-subscriber latency, and missed notifications across sessions. Done means a fan-out load mode reports those measurements for many sessions.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The problem
--load measures request/response latency only. A server's cost of fanning out notifications/resources/updated (or other notifications) to many subscribers, and the delivery latency each subscriber sees, is not measured.
Proposal
A fan-out mode: open N sessions, resources/subscribe each to a URI, then trigger updates (or wait for the server's own) and report per-notification delivery latency (from the trigger, or from the first subscriber's receipt), missed notifications per session, and the subscribe cost. It builds on the multi-connection machinery from --load-connections.
Split out of #2838 (item 9, "further ideas"), which covered items 1–8. Filed as follow-up work rather than built there, at the maintainer's request.
- Ngôn ngữ chính
- TypeScript
- Star
- 11.2k
- Fork
- 1.6k
- Merge trung bình
- 3 giờ 52 phút
- Pull request đã merge (30 ngày)
- 142
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của modelcontextprotocol/inspector
-
chore dependabot v2
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 76/100
modelcontextprotocol/inspector#2899 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
chore dependabot v2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
modelcontextprotocol/inspector#2898 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
chore dependabot v2
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 82/100
modelcontextprotocol/inspector#2897 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
chore dependencies v2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
modelcontextprotocol/inspector#2889 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement v2
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 42/100
modelcontextprotocol/inspector#2914 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của modelcontextprotocol/inspector
Issue tương tự
-
Chip source filter and denial markers miss Storage rows when a Storage activity source is pickedĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
omdsh-dev/DSH-better-sidebar#1141 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
desktop linux photos
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Cleanup SetupCó thể đã có người làm @AlexanderKaran đã nhận hôm nay. Đang mởdocumentation enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
e18e/framework-tracker#769 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
fix(docker): correct stale --db-path comments in fetch/git Dockerfiles and clarify git READMEĐang mởbug v2
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
modelcontextprotocol/servers#5483 ·
Maintainer thường phản hồi trong vòng 1 ngày