مقایسه جامع Eventlet و Gevent در پایتون

اگر در دنیای پایتون با برنامه‌های شبکه‌ای، وب‌سرورها، WebSocket، Socket.IO، Scraping، API Gateway یا سرویس‌هایی که همزمان باید با تعداد زیادی اتصال کار کنند سروکار داشته باشید، احتمالاً نام‌های Eventlet و Gevent را شنیده‌اید.

هر دو کتابخانه برای حل یک مسئله مهم به وجود آمده‌اند:

چگونه بتوانیم در پایتون تعداد زیادی کار ورودی/خروجی، مثل درخواست شبکه، خواندن و نوشتن سوکت، ارتباط با API، WebSocket و موارد مشابه را به شکل همزمان مدیریت کنیم، بدون اینکه برای هر اتصال یک Thread سنگین جداگانه بسازیم؟

ابزارهای Eventlet و Gevent هر دو از مفهومی به نام Green Thread یا Greenlet استفاده می‌کنند. یعنی چیزی شبیه Thread، اما بسیار سبک‌تر و مدیریت‌شده در سطح برنامه، نه سیستم‌عامل.

اما با وجود شباهت‌های زیاد، تفاوت‌های مهمی در طراحی، کارایی، اکوسیستم، میزان نگهداری، سازگاری و آینده این دو وجود دارد.

در این مقاله ابتدا ماهیت این دو ابزار و مفاهیم مرتبط را توضیح می‌دهیم، سپس تفاوت‌هایشان را به زبان ساده و مناسب افراد مبتدی بررسی می‌کنیم و در پایان یک جدول مقایسه خلاصه ارائه می‌کنیم.

قبل از Eventlet و Gevent: مشکل اصلی چیست؟

در برنامه‌نویسی معمولی پایتون، وقتی کدی مثل این می‌نویسیم:

response = requests.get("https://example.com")
print(response.text)

برنامه تا زمانی که پاسخ از سرور برگردد، منتظر می‌ماند. به این حالت می‌گوییم Blocking.

یعنی اجرای برنامه در آن نقطه متوقف می‌شود تا عملیات کامل شود.

حالا فرض کنید یک سرور دارید که باید همزمان به ۱۰ هزار کاربر پاسخ دهد. اگر برای هر کاربر یک Thread جداگانه بسازید، مصرف حافظه زیاد می‌شود، مدیریت Threadها سخت می‌شود و برنامه به‌تدریج کند یا ناپایدار خواهد شد.

برای حل این مشکل چند راه وجود دارد:

1. استفاده از Threadها
2. استفاده از Processها
3. استفاده از async/await و asyncio
4. استفاده از Greenletها، مثل Eventlet و Gevent

دقیقا Eventlet و Gevent مربوط به گزینه چهارم هستند.

در پایتون Greenlet چیست؟

برای فهم Eventlet و Gevent، اول باید مفهوم Greenlet را بفهمیم.

Greenletها شبیه Thread هستند، اما با یک تفاوت مهم:

Threadهای معمولی توسط سیستم‌عامل مدیریت می‌شوند، اما Greenletها توسط خود برنامه و کتابخانه‌هایی مثل Eventlet یا Gevent مدیریت می‌شوند.

به Threadهای معمولی می‌گوییم:

OS-level Thread

اما به Greenletها می‌توان گفت:

User-level Lightweight Thread

یعنی یک نوع نخ اجرایی سبک که در سطح خود برنامه مدیریت می‌شود.

تفاوت Greenlet با Thread معمولی

در Thread معمولی، سیستم‌عامل تصمیم می‌گیرد کدام Thread اجرا شود و چه زمانی اجرای آن را متوقف کند. اما در Greenletها معمولاً جابه‌جایی بین وظایف زمانی رخ می‌دهد که عملیات ورودی/خروجی انجام شود؛ مثلاً خواندن از شبکه یا نوشتن در سوکت.

این نوع همزمانی را معمولاً می‌نامند:

Cooperative Concurrency

یعنی همزمانی مشارکتی.

در این مدل، وظایف باید در زمان مناسب کنترل را آزاد کنند تا بقیه وظایف هم اجرا شوند.

پردازه Blocking و Non-blocking یعنی چه؟

فرض کنید در یک رستوران، یک گارسون سفارش مشتری را می‌گیرد و منتظر می‌ماند تا غذا آماده شود. تا زمانی که غذا آماده نشده، گارسون هیچ کار دیگری نمی‌کند. این شبیه مدل Blocking است.

اما در مدل بهتر، گارسون سفارش را می‌گیرد، آن را به آشپزخانه می‌دهد و تا وقتی غذا آماده شود، سراغ مشتری بعدی می‌رود. این شبیه مدل Non-blocking یا همزمانی بهتر است.

بعبارتی Eventlet و Gevent تلاش می‌کنند همین کار یعنی Non Blocking را در برنامه‌های پایتونی انجام دهند. وقتی یک Greenlet منتظر شبکه، فایل یا سوکت است، Greenletهای دیگر می‌توانند اجرا شوند. در نتیجه برنامه معطل یک فعالیت یا تسک نخواهد ماند و به کار خود بدون وقفه ادامه میدهد.

در پایتون Monkey Patching چیست؟

یکی از مفاهیم بسیار مهم در Eventlet و Gevent، Monkey Patching است.

واژه Monkey Patching یعنی تغییر دادن رفتار برخی از کتابخانه‌ها یا ماژول‌های استاندارد پایتون در زمان اجرا. مثلاً ماژول‌های استاندارد پایتون مثل socket یا threading به شکل عادی blocking هستند. Eventlet و Gevent می‌توانند این ماژول‌ها را patch کنند تا نسخه غیرمسدودکننده یا cooperative آن‌ها استفاده شود.

مثلاً در Gevent معمولاً این کار را می‌بینید:

from gevent import monkey
monkey.patch_all()

و در Eventlet:

import eventlet
eventlet.monkey_patch()

بعد از این کار، بسیاری از عملیات شبکه‌ای که قبلاً blocking بودند، با مدل greenlet-friendly اجرا می‌شوند. اما این کار هم مزیت دارد، هم خطر.

مزیتش این است که می‌توانید کدهای نسبتاً معمولی و synchronous بنویسید، اما پشت صحنه رفتارشان cooperative شود.

خطرش این است که گاهی با بعضی کتابخانه‌ها ناسازگاری ایجاد می‌کند، مخصوصاً اگر کتابخانه‌ای انتظار رفتار دقیق ماژول‌های استاندارد پایتون را داشته باشد.

در پایتون Event Loop یا Hub چیست؟

ابزارهای Eventlet و Gevent هر دو نوعی هسته مرکزی برای مدیریت رویدادها دارند. به آن معمولاً Event Loop یا گاهی Hub گفته می‌شود.

درواقع Event Loop بررسی می‌کند:

• کدام اتصال شبکه‌ای آماده خواندن است؟
• کدام سوکت آماده نوشتن است؟
• کدام Greenlet باید ادامه پیدا کند؟
• کدام وظیفه باید منتظر بماند؟
• تایمرها چه زمانی باید اجرا شوند؟

در واقع Event Loop مثل مدیر ترافیک است که تعیین می‌کند کدام Greenlet چه زمانی اجرا شود.

کتابخانه Eventlet چیست؟

کتابخانه Eventlet یک کتابخانه پایتونی برای برنامه‌نویسی شبکه‌ای همزمان با استفاده از Green Threadها است که پیش از این راجب آنها یاد گرفتیم.

هدف Eventlet این است که نوشتن برنامه‌های همزمان را شبیه نوشتن برنامه‌های عادی و ساده کند. یعنی شما به جای اینکه مستقیماً درگیر callback، event loop یا async/await شوید، بتوانید کدهایی نزدیک به سبک synchronous بنویسید.

مثلاً:

import eventlet

def fetch_url(url):
    # عملیات شبکه‌ای
    pass

pool = eventlet.GreenPool()

for url in urls:
    pool.spawn(fetch_url, url)

pool.waitall()

در اینجا GreenPool تعدادی Green Thread ایجاد می‌کند و وظایف را بین آن‌ها مدیریت می‌کند.

کتابخانه Eventlet بیشتر در پروژه‌هایی دیده می‌شود که نیاز به ارتباطات شبکه‌ای همزمان، WebSocket یا سرورهای real-time دارند. برای مثال، در گذشته در برخی پروژه‌های مبتنی بر Flask-SocketIO استفاده از Eventlet رایج بود.

ویژگی‌های مهم Eventlet

Eventlet چند مفهوم و ابزار مهم دارد:

1. GreenThread

رشته های GreenThread همان واحد اجرایی سبک Eventlet است.

gt = eventlet.spawn(function)

با این دستور یک تابع در یک GreenThread اجرا می‌شود.

2. GreenPool

برای مدیریت تعداد زیادی GreenThread استفاده می‌شود.

pool = eventlet.GreenPool(size=100)

یعنی حداکثر ۱۰۰ کار به شکل همزمان اجرا شوند.

3. monkey_patch

برای patch کردن ماژول‌های استاندارد پایتون استفاده می‌شود.

eventlet.monkey_patch()

4. sleep

در Eventlet نباید همیشه از time.sleep() معمولی استفاده کنید، چون ممکن است کل اجرای برنامه را متوقف کند. بهتر است از کد زیر استفاده شود تا کنترل به Greenletهای دیگر داده شود.

eventlet.sleep(1)

البته اگر monkey patch انجام شده باشد، ممکن است time.sleep هم patch شده باشد و مشکلی ایجاد نشود.

کتابخانه Gevent چیست؟

کتابخانه Gevent هم یک کتابخانه پایتونی برای همزمانی مبتنی بر Greenlet است. Gevent از کتابخانه معروف greenlet استفاده می‌کند و برای event loop معمولاً از libev یا در برخی حالت‌ها libuv استفاده می‌کند.

کتابخانه Gevent در بسیاری از پروژه‌ها به عنوان گزینه‌ای سریع، پایدار و نسبتاً mature برای برنامه‌های شبکه‌ای شناخته می‌شود.

مثال ساده:

import gevent

def task(name):
    print("Start", name)
    gevent.sleep(1)
    print("End", name)

jobs = [
    gevent.spawn(task, "A"),
    gevent.spawn(task, "B"),
    gevent.spawn(task, "C")
]

gevent.joinall(jobs)

در این مثال سه کار تقریباً همزمان اجرا می‌شوند، چون gevent.sleep باعث می‌شود Greenlet فعلی منتظر بماند و کنترل به بقیه داده شود.

ویژگی‌های مهم Gevent

1. Greenlet

واحد اجرایی اصلی در Gevent، همان Greenlet است.

g = gevent.spawn(function)

2. joinall

برای صبر کردن تا پایان چند Greenlet استفاده می‌شود.

gevent.joinall([g1, g2, g3])

3. monkey.patch_all

برای patch کردن ماژول‌های استاندارد:

from gevent import monkey
monkey.patch_all()

4. Pool

برای کنترل تعداد Greenletهای همزمان در gevent:

from gevent.pool import Pool

pool = Pool(100)
pool.spawn(function)
pool.join()

شباهت‌های Eventlet و Gevent

قبل از اینکه سراغ تفاوت‌ها برویم، بهتر است شباهت‌ها را بشناسیم.

هر دو:

• برای همزمانی در عملیات I/O مناسب هستند.
• از Greenlet یا Green Thread استفاده می‌کنند.
• با monkey patching می‌توانند کدهای blocking را cooperative کنند.
• برای کارهای شبکه‌ای مناسب‌تر از کارهای CPU-heavy هستند.
• می‌توانند جایگزین سبک‌تری نسبت به Threadهای زیاد باشند.
• معمولاً برای WebSocket، Socket.IO، سرورهای real-time و کارهای شبکه‌ای استفاده شده‌اند.
• با مدل async/await متفاوت هستند.
• اگر کد blocking واقعی در آن‌ها اجرا شود، ممکن است کل سیستم کند یا متوقف شود.

تفاوت اصلی: فلسفه و طراحی

Eventlet بیشتر روی سادگی و فراهم کردن یک لایه ساده برای برنامه‌نویسی شبکه‌ای تمرکز داشته است. در Eventlet مفاهیمی مثل GreenPool و APIهای ساده باعث می‌شوند برای شروع، کار کمی راحت‌تر به نظر برسد.

از طرف دیگر، Gevent بیشتر به عنوان یک ابزار قدرتمندتر، سریع‌تر و نزدیک‌تر به زیرساخت‌های event loop شناخته می‌شود. Gevent معمولاً در پروژه‌هایی که به performance و پایداری بیشتری نیاز دارند، انتخاب جدی‌تری بوده است.

البته این تفاوت همیشه مطلق نیست، اما در نگاه عمومی، Gevent انتخاب حرفه‌ای‌تر و پخته‌تر محسوب می‌شود.

تفاوت در وضعیت نگهداری و آینده پروژه

یکی از مهم‌ترین تفاوت‌های امروزی Eventlet و Gevent مربوط به وضعیت نگهداری آن‌هاست.

Eventlet در سال‌های اخیر نسبت به گذشته کمتر توصیه می‌شود. حتی در مستندات و فضای توسعه آن، استفاده جدید از Eventlet چندان تشویق نمی‌شود و معمولاً پیشنهاد می‌شود اگر پروژه جدیدی شروع می‌کنید، به گزینه‌های مدرن‌تر مثل asyncio فکر کنید.

در مقابل، Gevent هنوز در بسیاری از پروژه‌ها استفاده می‌شود و از نظر فنی و اکوسیستم وضعیت فعال‌تری نسبت به Eventlet دارد.

بنابراین اگر امروز، یعنی در پروژه‌های جدید، بین Eventlet و Gevent انتخاب می‌کنید، معمولاً Gevent انتخاب قابل دفاع‌تری است. هرچند حتی درباره Gevent هم باید بررسی کنید که آیا واقعاً به آن نیاز دارید یا بهتر است مستقیماً از asyncio، FastAPI، aiohttp یا ابزارهای async مدرن استفاده کنید.

تفاوت در کارایی

در بسیاری از سناریوهای I/O-bound، Gevent معمولاً کارایی خوبی دارد و به خاطر استفاده از event loopهای قوی مثل libev/libuv مشهور است. البته Eventlet هم می‌تواند عملکرد مناسبی داشته باشد، اما در مقایسه‌های عمومی و تجربه بسیاری از توسعه‌دهندگان، Gevent اغلب سریع‌تر و بهینه‌تر در نظر گرفته می‌شود. البته gevent با ساختار ویندوز همسو نیست و ممکن است برنامه اجرا نشود یا هنگ کند پس در محیط ویندوز الزام به استفاده از Eventlet است. در یک کلام میتوان گفت عملکرد Gevent بهتر است ولی این گزاره مطلق نیست.

البته باید دقت کرد که performance همیشه وابسته به نوع پروژه است. مثلاً:

• تعداد اتصال‌ها چقدر است؟
• عملیات بیشتر شبکه‌ای است یا پردازشی؟
• از چه کتابخانه‌هایی استفاده می‌کنید؟
• monkey patch درست انجام شده؟
• DNS resolution چگونه انجام می‌شود؟
• آیا کدی دارید که CPU را اشغال کند؟

اگر برنامه شما CPU-heavy باشد، نه Eventlet و نه Gevent انتخاب اصلی نیستند. چون هر دو برای I/O concurrency طراحی شده‌اند، نه پردازش سنگین.

برای کارهای CPU-heavy بهتر است ازموارد زیر استفاده کنید:

• multiprocessing
• Celery workers
• ProcessPoolExecutor
• زبان یا سرویس جداگانه
• C extensions

تفاوت در سازگاری با کتابخانه‌ها

هر دو کتابخانه برای اینکه خوب کار کنند، معمولاً نیاز به monkey patching دارند. اما monkey patching همیشه بی‌خطر نیست.

در Gevent، رفتار monkey patching بسیار شناخته‌شده و گسترده است و بسیاری از کتابخانه‌ها و فریم‌ورک‌ها در طول زمان با آن تست شده‌اند.

Eventlet هم monkey patching دارد، اما به دلیل کاهش محبوبیت و کاهش استفاده در پروژه‌های جدید، ممکن است در آینده مشکلات سازگاری بیشتری نسبت به Gevent داشته باشد.

نکته مهم برای مبتدیان:

اگر از کتابخانه‌ای استفاده می‌کنید که خودش event loop، thread، socket یا time را به شکل خاصی مدیریت می‌کند، باید بررسی کنید که با Eventlet یا Gevent سازگار است یا نه.

مثلاً کتابخانه‌هایی مثل:

• requests
• urllib3
• psycopg2
• redis clients
• socket libraries
• database drivers

ممکن است بسته به نحوه استفاده، نیاز به تنظیمات خاص داشته باشند.

تفاوت با asyncio

خیلی از مبتدی‌ها می‌پرسند:

اگر Eventlet و Gevent برای همزمانی هستند، پس فرقشان با asyncio چیست؟

asyncio کتابخانه استاندارد پایتون برای برنامه‌نویسی asynchronous است. در asyncio شما معمولاً کد را با async و await می‌نویسید:

async def main():
    await some_io()

اما در Eventlet و Gevent می‌توانید کدی شبیه کد synchronous بنویسید و با monkey patching آن را cooperative کنید.

تفاوت اصلی:

• asyncio explicit است؛ یعنی در کد مشخص می‌کنید کجا await دارید. دقیقا همان موردی که await کردید فقط بصورت async ران میشود.
• کتابخانه های gevent و eventlet دقیقا implicitتر هستند؛ یعنی با patch کردن، خیلی چیزها پشت صحنه cooperative می‌شوند.

برای پروژه‌های جدید، مخصوصاً اگر از FastAPI، aiohttp، httpx async، async SQLAlchemy و WebSocketهای مدرن استفاده می‌کنید، asyncio معمولاً انتخاب طبیعی‌تر است.

اما اگر پروژه قدیمی دارید که synchronous نوشته شده و می‌خواهید بدون بازنویسی کامل، همزمانی I/O بیشتری بگیرید، Gevent یا Eventlet می‌توانند مفید باشند.

تفاوت در استفاده با Flask و Socket.IO

یکی از جاهایی که Eventlet و Gevent زیاد دیده می‌شوند، پروژه‌های Flask-SocketIO است.

در Flask-SocketIO، برای پشتیبانی بهتر از WebSocket و long-polling، معمولاً async modeهای مختلفی وجود دارد، مثل:

• eventlet
• gevent
• threading
• asyncio/asgi در معماری‌های دیگر

در گذشته Eventlet گزینه بسیار رایجی برای Flask-SocketIO بود، چون راه‌اندازی ساده‌ای داشت و عملکرد مناسبی ارائه می‌داد. اما امروزه، با توجه به وضعیت نگهداری Eventlet، بسیاری از توسعه‌دهندگان ترجیح می‌دهند سراغ Gevent یا راهکارهای مبتنی بر ASGI بروند.

اگر پروژه ساده و آموزشی دارید، Eventlet ممکن است هنوز قابل استفاده باشد، اما برای پروژه جدی و بلندمدت، بهتر است با دقت بیشتری انتخاب کنید.

تفاوت در API و تجربه برنامه‌نویسی

از نظر تجربه کدنویسی، Eventlet معمولاً API ساده و مستقیم‌تری برای مبتدی‌ها ارائه می‌دهد.

مثلاً:

pool = eventlet.GreenPool()
pool.spawn(func)
pool.waitall()

در Gevent هم مشابه آن وجود دارد:

pool = Pool(100)
pool.spawn(func)
pool.join()

اما Gevent در سطح پیشرفته امکانات بیشتری دارد و کنترل دقیق‌تری روی Greenletها، Poolها، تایمرها، socketها، queueها و eventها فراهم می‌کند.

به زبان ساده:

• Eventlet برای شروع ممکن است دوستانه‌تر به نظر برسد.
• Gevent برای پروژه‌های جدی‌تر و کنترل بیشتر مناسب‌تر است.

تفاوت در Event Loop زیرساختی

Gevent معمولاً از libev یا libuv برای event loop استفاده می‌کند. این‌ها کتابخانه‌های سطح پایین و قدرتمندی برای مدیریت رویدادهای I/O هستند.

Eventlet معماری متفاوتی دارد و از hubهای خودش برای مدیریت رویدادها استفاده می‌کند.

برای یک مبتدی، شاید این تفاوت خیلی مهم به نظر نرسد، اما در پروژه‌های بزرگ روی مواردی مثل performance، پایداری و سازگاری اثر دارد.

Gevent معمولاً از این نظر شهرت بهتری دارد.

تفاوت در خطایابی و Debugging

یکی از چالش‌های هر دو کتابخانه، debugging است.

چون اجرای کدها cooperative است و monkey patching می‌تواند رفتار کتابخانه‌های استاندارد را تغییر دهد، گاهی پیدا کردن علت مشکل سخت‌تر از حالت معمولی است.

اما چون Gevent استفاده گسترده‌تری در پروژه‌های performance-oriented داشته، منابع، تجربه‌ها و راهنماهای بیشتری برای حل مشکلات آن وجود دارد.

در Eventlet نیز منابع وجود دارد، ولی در مقایسه با Gevent و asyncio، کمتر به‌روز و فعال به نظر می‌رسد.

تفاوت در ریسک استفاده در پروژه‌های جدید

اگر بخواهیم خیلی عملی نگاه کنیم:

برای پروژه جدید

بهتر است اول بررسی کنید آیا واقعاً به Eventlet یا Gevent نیاز دارید یا نه.

اگر پروژه از ابتدا نوشته می‌شود، معمولاً گزینه‌های زیر مدرن‌تر هستند:

• asyncio
• FastAPI
• Starlette
• aiohttp
• Sanic
• ASGI servers مثل Uvicorn و Hypercorn

اگر با Flask کار می‌کنید و نیاز به WebSocket دارید، شاید بهتر باشد بررسی کنید آیا معماری ASGI برای شما مناسب‌تر است یا نه.

برای پروژه قدیمی

اگر پروژه synchronous دارید و نمی‌خواهید آن را کامل async کنید، Gevent می‌تواند گزینه خوبی باشد.

کتابخانه Eventlet هم اگر قبلاً در پروژه استفاده شده، می‌تواند ادامه پیدا کند، اما برای شروع پروژه جدید انتخاب اول محسوب نمی‌شود.

یک مثال ساده برای مقایسه

Eventlet

import eventlet
eventlet.monkey_patch()

def task(name):
    print("Start", name)
    eventlet.sleep(1)
    print("End", name)

pool = eventlet.GreenPool()

for name in ["A", "B", "C"]:
    pool.spawn(task, name)

pool.waitall()

Gevent

from gevent import monkey
monkey.patch_all()

import gevent

def task(name):
    print("Start", name)
    gevent.sleep(1)
    print("End", name)

jobs = [
    gevent.spawn(task, "A"),
    gevent.spawn(task, "B"),
    gevent.spawn(task, "C")
]

gevent.joinall(jobs)

از نظر ظاهری، هر دو شبیه هم هستند. هر دو سه کار را تقریباً همزمان اجرا می‌کنند. تفاوت اصلی در زیرساخت، نگهداری، سازگاری، اکوسیستم و performance خودش را نشان می‌دهد.

چه زمانی Eventlet مناسب است؟

Eventlet ممکن است مناسب باشد اگر:

• پروژه‌ای قدیمی دارید که از Eventlet استفاده می‌کند.
• نیاز دارید آن پروژه را نگهداری کنید، نه اینکه از صفر بسازید.
• با Flask-SocketIO یا ابزارهایی کار می‌کنید که در تنظیمات فعلی با Eventlet کار می‌کنند.
• کار شما بیشتر آموزشی یا آزمایشی است.
• performance و آینده بلندمدت پروژه برایتان مسئله اصلی نیست.
• نرم افزار حتما باید روی ویندوز اجرا شود.

اما برای پروژه جدید و جدی، بهتر است خیلی محتاط باشید.

چه زمانی Gevent مناسب است؟

Gevent مناسب است اگر:

• پروژه synchronous دارید و می‌خواهید I/O concurrency بهتری بگیرید.
• نمی‌خواهید کل پروژه را به asyncio تبدیل کنید.
• با تعداد زیادی اتصال شبکه‌ای سروکار دارید.
• نیاز به گزینه‌ای matureتر و پرکاربردتر از Eventlet دارید.
• با WSGI و ابزارهای سنتی پایتون کار می‌کنید.
• از Gunicorn با workerهای gevent استفاده می‌کنید.

مثلاً در Gunicorn می‌توانید از worker کلاس gevent استفاده کنید:

gunicorn -k gevent myapp:app

این روش برای بعضی برنامه‌های WSGI که I/O-bound هستند، می‌تواند مفید باشد.

نکته بسیار مهم: این‌ها برای CPU-heavy مناسب نیستند

یکی از اشتباهات رایج این است که فکر کنیم Eventlet یا Gevent باعث می‌شوند هر نوع برنامه‌ای سریع‌تر شود.

اگر تابع شما این کار را انجام دهد:

def heavy_calculation():
    for i in range(10**9):
        pass

در چنین سناریویی که پردازنده را درگیر میکنند یا اصلاحا CPU Bound هستند Eventlet و Gevent کمک خاصی نمی‌کنند. چون این تابع CPU را اشغال می‌کند و به Greenletهای دیگر فرصت اجرا نمی‌دهد، مگر اینکه خودتان کنترل را آزاد کنید.

این ابزارها بیشتر برای کارهایی مثل این مناسب‌اند:

• درخواست HTTP به سرویس‌های دیگر
• اتصال WebSocket
• خواندن و نوشتن شبکه
• ارتباط با Redis
• کار با APIهای خارجی
• long polling
• socket programming
• تعداد زیادی connection همزمان

جمع‌بندی

نهایتا Eventlet و Gevent هر دو برای حل مسئله همزمانی در عملیات I/O در پایتون ساخته شده‌اند. هر دو از Greenletها استفاده می‌کنند و با monkey patching می‌توانند کدهای blocking را به شکل cooperative اجرا کنند.

اما تفاوت مهم اینجاست که Gevent معمولاً matureتر، سریع‌تر، فعال‌تر و مناسب‌تر برای پروژه‌های جدی شناخته می‌شود. Eventlet در گذشته محبوب بوده، مخصوصاً در بعضی پروژه‌های real-time و Flask-SocketIO، اما امروزه برای پروژه‌های جدید کمتر توصیه می‌شود و بهتر است با احتیاط انتخاب شود.

اگر پروژه جدیدی شروع می‌کنید، ابتدا asyncio و فریم‌ورک‌های مدرن async را بررسی کنید. اگر پروژه قدیمی synchronous دارید و نمی‌خواهید آن را کامل بازنویسی کنید، Gevent معمولاً انتخاب بهتری نسبت به Eventlet است. اگر پروژه‌ای از قبل با Eventlet ساخته شده، می‌توانید آن را نگهداری کنید، اما بهتر است برای آینده برنامه مهاجرت داشته باشید.

جدول مقایسه Eventlet و Gevent در یک نگاه