کشینگ سرور MCP: آنچه پس از ۸۷ بار قطعی آموختم

فکر می‌کردم سرور MCP من نیازی به کشینگ (Caching) ندارد.

پایگاه دانش من تنها چند هزار ورودی داشت. پرس‌وجوها (Queries) سریع بودند. اما اشتباه می‌کردم.

پس از ۸۷ بار قطعی در محیط عملیاتی و سه روز عیب‌یابی زمان‌های انتظار (timeouts)، درس سختی گرفتم. هر سرور MCP به کشینگ نیاز دارد. حتی سرورهای کوچک.

ماجرا از این قرار بود.

سرور برای یافتن یادداشت‌ها از جستجوی معنایی (semantic search) استفاده می‌کرد. بیشتر اوقات درست کار می‌کرد، اما ناگهان همه چیز از هم پاشید.

  • اتصالات در میانه درخواست قطع می‌شدند.
  • Claude Desktop پس از ۶۰ ثانیه با خطای timeout مواجه می‌شد.
  • Nginx خطای 504 Gateway Timeout برمی‌گرداند.

بدترین بخش؟ این اتفاق فقط هنگام پرس‌وجوهای تکراری رخ می‌داد.

وقتی کاربر یک سوال را دو بار می‌پرسد، ممکن است در حالی که هوش مصنوعی در حال فکر کردن است، اتصال در حالت بیکاری (idle) باقی بماند. سپس یک پروکسی اتصال را قطع می‌کند. Claude به‌طور خودکار درخواست را دوباره ارسال می‌کند. حالا شما دو جستجوی کاملاً یکسان دارید که همزمان در حال اجرا هستند.

وقتی چندین تلاش مجدد (retry) رخ می‌دهد، استخر اتصالات (connection pool) پایگاه داده شما تمام می‌شود. و همه چیز از کار می‌افتد.

متوجه شدم که نباید پاسخ نهایی هوش مصنوعی را کش کنم؛ این کار برای MCP بیش از حد پیچیده است. در عوض، باید بخش سنگین را کش می‌کردم: جستجوی معنایی و واکشی محتوا (content fetching).

من به یک استراتژی کشینگ دو سطحی روی آوردم:

• سطح ۱: کش درون‌حافظه‌ای (In-memory cache) برای پرس‌وجوهای مکرر. این روش بسیار سریع است. • سطح ۲: کش Redis برای داده‌های مشترک در طول بازراه‌اندازی‌ها.

همچنین برای اینکه این سیستم به درستی کار کند، این قوانین را رعایت کردم:

  • نرمال‌سازی پرس‌وجوها: من پرس‌وجوها را به حروف کوچک تبدیل کرده و فضاهای خالی اضافی را حذف می‌کنم. این کار نرخ برخورد با کش (cache hits) را افزایش می‌دهد.
  • کش کردن نتایج، نه استریم‌ها: من فقط نتایج جستجو را کش می‌کنم. جستجو ۹۵٪ از زمان را می‌گیرد.
  • کاهش تدریجی عملکرد (Graceful degradation): اگر Redis از کار بیفتد، سرور همچنان کار می‌کند؛ فقط مستقیماً به سراغ پایگاه داده می‌رود. کشینگ یک بهینه‌سازی است، نه الزامی برای موفقیت درخواست.

نتایج خیره‌کننده بود.

میانگین زمان جستجوی من از ۳۲۰ میلی‌ثانیه به ۱۲ میلی‌ثانیه رسید. یعنی ۲۷ برابر سریع‌تر. نرخ کل برخورد با کش (cache hit rate) من ۷۳٪ است. بیشتر پرس‌وجوها اصلاً به پایگاه داده من نمی‌رسند.

اگر یک سرور MCP می‌سازید، این کار را انجام دهید:

  • برای استفاده شخصی: از یک کش درون‌حافظه‌ای استفاده کنید. این کار از تایم‌اوت‌های تصادفی جلوگیری می‌کند.
  • برای سرویس‌های عمومی: از رویکرد دو سطحی با Redis استفاده کنید. این کار از کرش کردن جلوگیری کرده و سرعت را بهبود می‌بخشد.

کشینگ درباره قابلیت اطمینان است. این کار چرخه تلاش‌های مجدد و شکست‌های اتصال را متوقف می‌کند.

Source: https://dev.to/kevinten10/mcp-server-caching-what-i-learned-adding-caching-to-my-mcp-knowledge-base-after-87-production-261b

Optional learning community: https://t.me/GyaanSetuAi