MCP Server Caching: 87 தடங்கல்களுக்குப் பிறகு நான் கற்றுக்கொண்டது
எனது MCP server-க்கு caching தேவையில்லை என்று நான் நினைத்தேன்.
எனது knowledge base-இல் சில ஆயிரம் பதிவுகள் மட்டுமே இருந்தன. Queries வேகமாக இருந்தன. ஆனால் நான் தவறாக இருந்தேன்.
87 production outages மற்றும் மூன்று நாட்கள் debugging செய்த பிறகு, நான் ஒரு கடினமான பாடத்தைக் கற்றுக்கொண்டேன். ஒவ்வொரு MCP server-க்கும் caching தேவை. சிறியவை கூடத் தேவை.
என்ன நடந்தது என்பது இதோ.
குறிப்புகளைக் கண்டறிய server semantic search முறையைப் பயன்படுத்தியது. பெரும்பாலான நேரங்களில் அது சரியாக வேலை செய்தது. ஆனால், பிறகு பிரச்சனைகள் ஏற்பட்டன.
- கோரிக்கை (request) நடந்து கொண்டிருக்கும்போதே இணைப்புகள் துண்டிக்கப்பட்டன.
- Claude Desktop 60 வினாடிகளுக்குப் பிறகு timeout ஆனது.
- Nginx 504 Gateway Timeouts-ஐத் திருப்பியளித்தது.
மிக மோசமான விஷயம் என்னவென்றால்? இது மீண்டும் மீண்டும் கேட்கப்படும் queries-களில் மட்டுமே நடந்தது.
ஒரு பயனர் ஒரே கேள்வியை இரண்டு முறை கேட்கும்போது, AI சிந்திக்கும் நேரத்தில் இணைப்பு idle ஆக இருக்கலாம். அப்போது ஒரு proxy அந்த இணைப்பைத் துண்டித்துவிடும். Claude தானாகவே அந்த request-ஐ மீண்டும் முயற்சிக்கும் (retry). இப்போது, ஒரே மாதிரியான இரண்டு தேடல்கள் ஒரே நேரத்தில் இயங்கும்.
பலமுறை retries நடக்கும்போது, உங்கள் database connection pool தீர்ந்துவிடும். அனைத்தும் செயலிழந்துவிடும்.
இறுதி AI பதிலைத் (final AI response) cache செய்யக்கூடாது என்பதை நான் உணர்ந்தேன். அது MCP-க்கு மிகவும் சிக்கலானது. அதற்குப் பதிலாக, அதிக நேரமெடுக்கும் பகுதியை நான் cache செய்ய வேண்டியிருந்தது: அதாவது semantic search மற்றும் content fetching.
நான் இரண்டு நிலைகளைக் கொண்ட caching உத்தியைப் (two-level caching strategy) பின்பற்றினேன்:
• Level 1: அடிக்கடி கேட்கப்படும் queries-களுக்கான In-memory cache. இது மிகவும் வேகமானது. • Level 2: restarts-களுக்கு இடையிலான பகிரப்பட்ட தரவுகளுக்கான Redis cache.
இது சரியாகச் செயல்பட நான் இந்த விதிகளையும் பின்பற்றினேன்:
- Normalize queries: நான் queries-களை lowercase-க்கு மாற்றி, கூடுதல் இடைவெளிகளை (extra spaces) நீக்குகிறேன். இது cache hits-ஐ அதிகரிக்கும்.
- Cache results, not streams: நான் search results-களை மட்டுமே cache செய்கிறேன். தேடலே 95% நேரத்தை எடுத்துக்கொள்கிறது.
- Graceful degradation: Redis செயலிழந்தாலும், server தொடர்ந்து இயங்கும். அது நேரடியாக database-ஐ அணுகும். Caching என்பது ஒரு optimization மட்டுமே, கோரிக்கை வெற்றி பெறுவதற்கு அது கட்டாயமானத் தேவை அல்ல.
இதன் முடிவுகள் பிரம்மாண்டமாக இருந்தன.
எனது சராசரி search time 320ms-லிருந்து 12ms ஆகக் குறைந்தது. இது 27 மடங்கு வேகமானது. எனது மொத்த cache hit rate 73% ஆகும். பெரும்பாலான queries எனது database-ஐ அணுகுவதே இல்லை.
நீங்கள் ஒரு MCP server-ஐ உருவாக்குகிறீர்கள் என்றால், இதைச் செய்யுங்கள்:
- தனிப்பட்ட பயன்பாட்டிற்கு: In-memory cache-ஐப் பயன்படுத்தவும். இது எதிர்பாராத timeout-களைத் தடுக்கும்.
- பொதுச் சேவைகளுக்கு: Redis உடன் கூடிய இரண்டு நிலைகளைக் கொண்ட அணுகுமுறையைப் பயன்படுத்தவும். இது crashes-ஐத் தடுத்து வேகத்தை மேம்படுத்தும்.
Caching என்பது நம்பகத்தன்மையைப் பற்றியது. இது retries மற்றும் இணைப்புத் தோல்விகளின் சுழற்சியைத் தடுக்கிறது.
Optional learning community: https://t.me/GyaanSetuAi