ഒരു ഫയലിൽ വരുത്തിയ മാറ്റത്തിലൂടെ 31.8x വേഗത വർദ്ധിപ്പിച്ചു
ഞാൻ ഒരു RAG ingestion pipeline പരീക്ഷിച്ചു, അവിടെ ഒരു തടസ്സം (bottleneck) നേരിട്ടു: ഒരു ഡോക്യുമെന്റ് പ്രോസസ്സ് ചെയ്യാൻ 50 സെക്കൻഡ് സമയം എടുത്തു.
എന്റെ CPU വെറുതെ ഇരിക്കുകയായിരുന്നു. ആപ്പ് കണക്കുകൂട്ടലുകളോ ലോജിക്കോ ഒന്നും ചെയ്യുന്നില്ലായിരുന്നു; അടുത്തത് തുടങ്ങുന്നതിന് മുൻപ് ഒരു HTTP റിക്വസ്റ്റ് പൂർത്തിയാകാൻ വേണ്ടി അത് കാത്തുനിൽക്കുകയായിരുന്നു.
ഞാൻ embedding module അസിൻക്രണസ് (asynchronously) ആയി പ്രവർത്തിക്കാൻ പാകത്തിൽ മാറ്റിയെഴുതി. ഇൻഫ്രാസ്ട്രക്ചറിൽ മാറ്റങ്ങളൊന്നും വരുത്താതെ തന്നെ റൺടൈം 49.61 സെക്കൻഡിൽ നിന്ന് 1.56 സെക്കൻഡായി കുറഞ്ഞു.
Test Details
- Model: Amazon Titan Text Embeddings V2 (AWS Bedrock)
- Dataset: 33 text chunks
- Region: us-east-1
Results
- Sequential: 49.61 s
- Concurrent: 1.56 s
- Speedup: 31.8×
എന്തുകൊണ്ട് ഇത് പ്രവർത്തിക്കുന്നു Sequential കോഡ് ഒരു റിക്വസ്റ്റ് അയക്കുകയും അത് തിരികെ വരുന്നത് വരെ ബ്ലോക്ക് ചെയ്യപ്പെടുകയും ചെയ്യുന്നു, ഇത് ഓരോ chunk-നും ആവർത്തിക്കുന്നു. ഓരോന്നിനും 1.5 സെക്കൻഡ് വീതം 33 chunks ഉണ്ടെങ്കിൽ, ഏകദേശം 50 സെക്കൻഡ് സമയം പാഴാകുന്നു.
Async കോഡ് എല്ലാ റിക്വസ്റ്റുകളും ഒരേസമയം അയക്കുന്നു; ആകെ എടുക്കുന്ന സമയം ഏറ്റവും കൂടുതൽ സമയം എടുക്കുന്ന ഒരു റിക്വസ്റ്റിന് തുല്യമായിരിക്കും.
Scaling impact
- 31 chunks: 49.61 s → 1.56 s
- 100 chunks: ~160 s → ~3 s
- 500 chunks: ~800 s → ~5 s
- 1,000 chunks: ~1,600 s → ~10 s
നിങ്ങളുടെ പൈപ്പ്ലൈനിനായുള്ള ടിപ്പുകൾ
- Idle time ശ്രദ്ധിക്കുക. നിങ്ങളുടെ കോഡ് വെറുതെ നെറ്റ്വർക്കിനായി കാത്തുനിൽക്കുകയാണെങ്കിൽ ഹാർഡ്വെയർ കൂട്ടിച്ചേർക്കരുത്.
- AWS Bedrock-ന്റെ rate limits പാലിക്കുക. Concurrent റിക്വസ്റ്റുകൾ നിയന്ത്രിക്കാൻ
asyncio.Semaphoreഉപയോഗിക്കുക. - Non-blocking ലൈബ്രറികൾ ഉപയോഗിക്കാൻ മുൻഗണന നൽകുക.
boto3-ൽ നിന്ന്aioboto3-ലേക്ക് മാറുന്നതോ അല്ലെങ്കിൽ കോൾസ്asyncio.to_thread()ഉപയോഗിച്ച് റാപ്പ് ചെയ്യുന്നതോ ആണ് നല്ലത്.
ഒരു ഫയലിൽ വരുത്തിയ മാറ്റം തന്നെ ആ തടസ്സം നീക്കം ചെയ്തു. കുറഞ്ഞ പരിശ്രമം. വലിയ ഫലം.
Source: https://dev.to/edwardyun/318x-speedup-by-changing-one-file-async-embedding-calls-on-aws-bedrock-4l61
Optional learning community: https://t.me/GyaanSetuAi