ایک فائل کی تبدیلی سے 31.8x رفتار میں اضافہ

میں نے ایک RAG ingestion pipeline کا تجربہ کیا اور ایک bottleneck کا سامنا کیا: ایک دستاویز کو پروسیس کرنے میں 50 سیکنڈ لگ رہے تھے۔

میرا CPU فارغ بیٹھا رہتا تھا۔ ایپ کوئی ریاضی یا منطق (logic) نہیں کر رہی تھی؛ یہ بس اگلی درخواست شروع کرنے سے پہلے ایک HTTP request کے مکمل ہونے کا انتظار کر رہی تھی۔

میں نے embedding module کو asynchronously چلانے کے لیے دوبارہ لکھا۔ Runtime 49.61 سیکنڈ سے کم ہو کر 1.56 سیکنڈ رہ گیا—اور انفراسٹرکچر میں کوئی تبدیلی نہیں کی گئی۔

ٹیسٹ کی تفصیلات

  • Model: Amazon Titan Text Embeddings V2 (AWS Bedrock)
  • Dataset: 33 text chunks
  • Region: us-east-1

نتائج

  • Sequential: 49.61 s
  • Concurrent: 1.56 s
  • Speedup: 31.8×

یہ کیسے کام کرتا ہے Sequential code ایک درخواست بھیجتا ہے اور اس کے واپس آنے تک رک جاتا ہے، اور یہی عمل ہر chunk کے لیے دہرایا جاتا ہے۔ اگر 33 chunks ہوں اور ہر ایک میں 1.5 سیکنڈ لگے، تو آپ تقریباً 50 سیکنڈ ضائع کر دیتے ہیں۔

Async code تمام درخواستیں ایک ساتھ بھیجتا ہے؛ کل وقت سب سے سست (slowest) واحد درخواست کے برابر ہوتا ہے۔

اسکیلنگ کا اثر (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 requests کو محدود کرنے کے لیے asyncio.Semaphore کا استعمال کریں۔
  • Non-blocking libraries کو ترجیح دیں۔ boto3 سے aioboto3 پر منتقل ہو جائیں یا calls کو asyncio.to_thread() کے ساتھ wrap کریں۔

صرف ایک فائل تبدیل کرنے سے bottleneck ختم ہو گیا۔ کم محنت۔ بڑا اثر۔

ماخذ: https://dev.to/edwardyun/318x-speedup-by-changing-one-file-async-embedding-calls-on-aws-bedrock-4l61

اختیاری لرننگ کمیونٹی: https://t.me/GyaanSetuAi