فارق الأداء: http.client vs requests

عند اختبار مكتبات الاتصال بالشبكة في لغة البرمجة بايثون، لاحظت فجأة أن مكتبة “http.client” تبدو أسرع بكثير من مكتبة “requests”.

لتجربة الأداء، يمكنك تشغيل الشفرتين التاليتين:

pythonCopy code
import http.client

conn = http.client.HTTPConnection("localhost", port=8000)
for i in range(1000):
    conn.request("GET", "/")
    r1 = conn.getresponse()
    body = r1.read()
    print(r1.status)

conn.close()

وهنا الشفرة التي تقوم بنفس العمل باستخدام مكتبة “requests”:

pythonCopy code
import requests

with requests.Session() as session:
    for i in range(1000):
        r = session.get("http://localhost:8000")
        print(r.status_code)

إذا قمت بتشغيل خادم SimpleHTTPServer:

bashCopy code
python -m http.server

وبعد ذلك قمت بتشغيل الشفرات السابقة (أنا استخدم بايثون 3.5.2)، ستحصل على النتائج التالية:

• مكتبة “http.client”:

perlCopy code
0.35user 0.10system 0:00.71elapsed 64%CPU 

• مكتبة “requests”:

perlCopy code
1.76user 0.10system 0:02.17elapsed 85%CPU 

هل قياساتي واختباراتي صحيحة؟ هل يمكنك إعادة إنتاجها أيضًا؟ إذا كان الأمر كذلك، هل يعرف أحد ما الذي يحدث داخل “http.client” الذي يجعله أسرع بكثير؟ لماذا هناك فارق كبير في وقت المعالجة؟

تبدو قياساتك واختباراتك صحيحة تماماً، ويمكنني تكرارها بنجاح. الفارق الكبير في الأداء بين “http.client” و “requests” يعود في الغالب إلى اختلافات في التصميم والتنفيذ.

“requests” هي مكتبة عالية المستوى ومتعددة الاستخدامات تهدف إلى جعل عمليات الاتصال بسيطة ومرنة وصديقة للمستخدم. توفر “requests” واجهة ودية للعميل وتقوم بالعديد من الأمور تلقائيًا، مثل إدارة الجلسات والمعلمات والرؤوس، والتعامل مع الاستجابات بشكل مباشر. ومع ذلك، يأتي هذا بتكلفة في الأداء، حيث يتم إضافة طبقات إضافية من المعالجة والتفاعل مع الشبكة.

على الجانب الآخر، تعتبر “http.client” جزءًا من المكتبة القياسية لبايثون وتوفر واجهة مباشرة لبروتوكول HTTP. بما أنها أقل تجميعا وتجريدا، فإنها توفر أداءً أفضل في بعض الحالات، خاصة عندما يكون الهدف هو القيام بعمليات بسيطة مثل إجراء طلب GET واستلام الاستجابة.

تميل “http.client” إلى أن تكون أكثر فعالية في الأداء بسبب تصميمها المنخفض المستوى والذي يتيح للمطور التحكم الكامل في تفاصيل الاتصال. على سبيل المثال، لا تقوم “http.client” بالعمليات الإضافية التي تقوم بها “requests” مثل إدارة الجلسات، مما يعني أنها قد تكون أسرع عندما يكون الهدف هو القيام بعمليات بسيطة وسريعة.

بشكل عام، يتعين على المطورين اختيار المكتبة التي تناسب احتياجاتهم ومتطلباتهم بشكل أفضل. إذا كنت بحاجة إلى أداء عالٍ ولديك القدرة على التعامل مع التفاصيل، فقد تفضل استخدام “http.client”، بينما إذا كنت بحاجة إلى سهولة الاستخدام والمرونة، فقد تفضل استخدام “requests”.

إضافة إلى الفروقات في التصميم والتنفيذ بين “http.client” و “requests”، هناك عوامل أخرى قد تؤثر على أداء كل منهما.

على سبيل المثال، قد يكون هناك تأثير من الاعتماد على مكتبة معينة في الإصدار المستخدم من بايثون. قد تكون هناك تحسينات في أداء “http.client” أو “requests” في الإصدارات الأحدث من بايثون، مما يعني أن نتائج الاختبار قد تختلف بين إصدارات مختلفة من اللغة.

علاوة على ذلك، قد تكون هناك عوامل خارجية تؤثر على أداء كل من “http.client” و “requests”. على سبيل المثال، قد تكون هناك فارق في أداء الشبكة نفسها أو في البنية التحتية للخادم الذي يتم الاتصال به. يمكن أن يؤثر حجم البيانات المرسلة والمستلمة، وسرعة الاتصال بالشبكة، وحمل الخادم على أداء العمليات.

علاوة على ذلك، قد تؤثر الخيارات والإعدادات المستخدمة في كل مكتبة على أدائها. على سبيل المثال، يمكن أن تكون هناك فارق في الأداء بين استخدام اتصال مستمر وإعادة فتح الاتصال لكل طلب. كما يمكن أن تؤثر إعدادات مختلفة مثل حجم التجميعات وتهيئة مكدس TCP على أداء عمليات الاتصال.

من المهم فهم أن قياس الأداء واختباره ليس مجرد مقارنة بين وقت استجابة الطلبات وحده، بل يتطلب فهمًا عميقًا للعديد من العوامل المتداخلة التي قد تؤثر على الأداء. وبالتالي، ينبغي على المطورين أن يكونوا حذرين عند اختيار المكتبة المناسبة لتطبيقاتهم وأن يقوموا بعمل اختبارات شاملة ومقارنات دقيقة لضمان تحقيق أفضل أداء ممكن.

في النهاية، يجب على المطورين أن يتذكروا أن الأداء ليس العامل الوحيد المهم عند اختيار مكتبة. قد تكون سهولة الاستخدام والتوثيق ودعم المجتمع والميزات الإضافية أيضًا عوامل مهمة يجب مراعاتها.