async FastAPI endpoint के अंदर पड़ी blocking लाइब्रेरी कॉल को आप कैसे संभालेंगे?

उसे event loop से हटा दें। blocking call को asyncio.to_thread में लपेटें, या thread pool के साथ run_in_executor इस्तेमाल करें, ताकि लूप बाकी requests के लिए खाली रहे। अगर काम CPU bound है तो उसे process pool या Celery जैसे background worker पर भेजें। वहीं छोड़ देने पर एक धीमी कॉल उस वर्कर की हर दूसरी request रोक देती है।

यह इसलिए मायने रखता है कि asyncio cooperative और सिंगल थ्रेडेड है, तो coroutine लूप को तब तक पकड़े रहता है जब तक वह किसी चीज पर await न करे। async handler में बैठी blocking driver कॉल उस वर्कर की बाकी हर चालू request जमा देती है, और कम ट्रैफिक में आपको पता ही नहीं चलेगा। FastAPI में सबसे सस्ता हल यह है कि endpoint को async def की जगह सादा def बनाया जाए, और framework उसे अपने threadpool में चला देता है। अगर मुझे इसे किसी async फंक्शन के अंदर चाहिए तो asyncio.to_thread कॉल को लपेटकर नतीजे का await कर लेता है। जहां मैं सावधान रहता हूं वह है thread pool का साइज, क्योंकि डिफॉल्ट छोटा है और कोई धीमी dependency उसके पीछे कतार लगा देगी, तो मैं उसे अपेक्षित concurrency के हिसाब से रखता हूं और timeout जोड़ता हूं। CPU के भारी काम में डिफॉल्ट build पर थ्रेड्स मदद नहीं करते, तो वह process pool या Celery वर्कर पर जाता है। ऐसा एक मामला हमें एक पुरानी SOAP client से मिला जो आठ सेकंड लेती थी, और पूरी सर्विस की p99 latency उसी एक कॉल के पीछे चल रही थी।