MCP Server Caching: Czego nauczyłem się po 87 awariach

Myślałem, że mój serwer MCP nie potrzebuje buforowania.

Moja baza wiedzy miała tylko kilka tysięcy wpisów. Zapytania były szybkie. Myliłem się.

Po 87 awariach na produkcji i trzech dniach debugowania timeoutów, wyciągnąłem bolesną lekcję. Każdy serwer MCP potrzebuje buforowania. Nawet te małe.

Oto co się stało.

Serwer używał wyszukiwania semantycznego do znajdowania notatek. Większość czasu działało to poprawnie. Ale potem zaczęły się problemy.

  • Połączenia były zrywane w trakcie zapytania.
  • Claude Desktop przekraczał limit czasu (timeout) po 60 sekundach.
  • Nginx zwracał błędy 504 Gateway Timeout.

Najgorsze? Działo się to tylko przy powtarzających się zapytaniach.

Gdy użytkownik zadaje to samo pytanie dwa razy, połączenie może pozostawać bezczynne, podczas gdy AI „myśli”. Wtedy proxy zrywa połączenie. Claude automatycznie ponawia próbę zapytania. W efekcie masz dwa identyczne wyszukiwania uruchomione jednocześnie.

Gdy dochodzi do wielu ponowień, pula połączeń do bazy danych zostaje wyczerpana. Wszystko pada.

Zdałem sobie sprawę, że nie powinienem buforować końcowej odpowiedzi AI. Jest to zbyt skomplikowane dla MCP. Zamiast tego musiałem buforować najbardziej obciążającą część: wyszukiwanie semantyczne i pobieranie treści.

Przeszedłem na dwupoziomową strategię buforowania:

• Poziom 1: Buforowanie w pamięci (in-memory) dla częstych zapytań. Jest niezwykle szybkie. • Poziom 2: Bufor Redis dla współdzielonych danych między restartami.

Aby to działało, stosowałem również te zasady:

  • Normalizacja zapytań: Zamieniam zapytania na małe litery i usuwam zbędne spacje. Zwiększa to liczbę trafień w buforze (cache hits).
  • Buforowanie wyników, a nie strumieni: Buforuję tylko wyniki wyszukiwania. Wyszukiwanie zajmuje 95% czasu.
  • Łagodne wygasanie (graceful degradation): Jeśli Redis przestanie działać, serwer nadal pracuje. Po prostu łączy się bezpośrednio z bazą danych. Buforowanie to optymalizacja, a nie wymóg konieczny do powodzenia zapytania.

Wyniki były ogromne.

Mój średni czas wyszukiwania spadł z 320 ms do 12 ms. To 27-krotne przyspieszenie. Całkowity współczynnik trafień w bufor (cache hit rate) wynosi 73%. Większość zapytań w ogóle nie trafia do mojej bazy danych.

Jeśli budujesz serwer MCP, zrób to:

  • Do użytku osobistego: Użyj buforowania w pamięci (in-memory). Zapobiega to losowym timeoutom.
  • Dla usług publicznych: Zastosuj podejście dwupoziomowe z Redisem. Zapobiega to awariom i zwiększa prędkość.

Buforowanie to kwestia niezawodności. Zatrzymuje ono cykl ponowień i awarii połączeń.

Źródło: https://dev.to/kevinten10/mcp-server-caching-what-i-learned-adding-caching-to-my-mcp-knowledge-base-after-87-production-261b

Opcjonalna społeczność edukacyjna: https://t.me/GyaanSetuAi