Why face_recognition.face_encodings() cause request timeout in concurrent django requests?

I am integrating a real-time computer vision pipeline into a Django view backend to process webcam frames. The frame analysis logic runs when a request hits the endpoint. My code is within a view like this:

import cv2
import numpy as np
import face_recognition
from django.http import JsonResponse
def process_attendance_frame(request):
    #set for first in otp.py - DONE
    #
    #frame=get_frame_from_request(request)    
    #downsamoptz
    small_frame=cv2.resize(frame, (0, 0), fx=0.25, fy=0.25)
    rgb_small_frame=cv2.cvtColor(small_frame, cv2.COLOR_BGR2RGB)
    face_locations=face_recognition.face_locations(rgb_small_frame)

    # HERE in concurrency, worker hangs indefinitely on below line
    face_encoding=face_recognition.face_encodings(rgb_small_frame, face_locations)
    return JsonResponse({'detected_faces': len(face_encodings)})

When I test with single user, me, the view returns a response in avg ~150ms. But in concurrent testing (say using ApacheBench with 5 concurrent requests), the WSGI workers running via Gunicorn freeze everytime. The system stops responding to unrelated lightweight JSON views (like my OTP fetch or say for my database queries) until the Gunicorn master kills the worker via timeout. But face_recognition utilizes dlib, shouldn't it bypass Python's GIL? Why does executing face_encodings() inside a synchronous django request loop deadlock/starve other active threads in the same process group, how can I isolate the process space?

Вернуться на верх