سلام دوستان من توی سرویس خودم از uwsgi استفاده میکنم و میخواستم بدونم برای سرویسی که مثلا روزانه به 100 کاربر سرویس میده چه کانفینگی پیشنهاد میدین
مثلا
processes
threads
مقدارشون چقدر باشه
سلام دوستان من توی سرویس خودم از uwsgi استفاده میکنم و میخواستم بدونم برای سرویسی که مثلا روزانه به 100 کاربر سرویس میده چه کانفینگی پیشنهاد میدین
مثلا
processes
threads
مقدارشون چقدر باشه
ببینید پایتون یه چیزی داره به نام GIL و این باعث میشه که واقعا فقط یک پراسس در هر لحظه بتونه روی cpu کار کنه.
و اینکه چه عددی باید ثبت بشه بستگی به نرمافزار و تعداد هستههای cpu داره ولی فکر میکنم اگه process به تعداد هستههای پردازنده و threads دوبرابر این باشه، خوب عمل کنه.
توی کانفیگهای قدیمیمو که نگاه میکردم دیدم process رو دوبرابر تعداد هستهها گذاشتم و threads رو اصلا ست نکردم.
و این مربوط به پروژههایی میشه که چندسال روی سرور داشتن کار میکردن.
من سرورم رام 4 هستش بعد نگاه که میکنم بیشترین رامی که استفاده میشه از uwsgi هستش
دلیلش چی میتونه باشه
بدون این که query ها سنگینی بزنم تو پنل ادمینش فقط میرم همین
اول بگم که «رام» صحیح نیست. باید بگیم «رَم».
من الآن سروری ندارم که روش پایتون ران کرده باشم ولی تا جایی که یادم میاد باید همینطوری باشه. چون وقتی uwsgi رو کانفیگ میکنید و براش daemon میسازید، دیگه پروژهی شما رو uwsgi داره ران میکنه! پس توی نرمافزارهای مانیتورینگ اسم python نمیاد.
حالا اینکه چرا اینقدر زیاد رم مصرف کرده، بخشیش میتونه به فضای رزرو شدهی رم باشه (دقیقا نمیدونم چیه) که نرمافزار مانیتورینگ شما اونم جزء «مصرف شده» نمایش میده. یا میتونه مربوط به راندمان پایین کد باشه یا چیزیه که پایتون نمیتونه GC کنه (کلا پایتون توی GC افتضاح عمل میکنه)
فکر میکنم نیازی نباشه که نگران مصرف رم باشید. به احتمال زیاد ریکوئستها که زیاد بشه هم مصرف رم همینقدر باقی میمونه و بیشتر نمیشه.
یعنی نمودار نسبت بازدیدها به مصرف رم، به احتمال زیاد یه نمودار لوگاریتمی باشه، یعنی صرف ران شدن برنامه باعث مصرف زیاد رم بشه ولی هر ریکوئست به تنهایی رم خاصی مصرف نکنه.
نظر شما در استفاده از gunicorn چیه؟؟
تزش استفاده کردین؟
به نظرم ارتباطی با مشکل شما نداره.
نه استفاده نکردم.
سلام عزیز
لطفا کمی بیشتر توضیح میدین . این سرویس چه سرویسی هست ؟ برای سرویس هایی که نیاز به پردازش دارن میتونید از Celery استفاده کنید . ۱۰۰ کاربر عدده کوچیکی هست . اطمینان خاطر داشته باشین تا چندین هزار پروگرس هم به سادگی میتونید هندل کنید
چند تا لینک به اشتراک میزارم چک کنید حتما کمک میکنه
client > massage broker >worker
مثال :
Celery.py
from celery import task
# this decorator is all that's needed to tell celery this is a worker task
@task
def do_work(self, list_of_work):
for work_item in list_of_work:
do_work_item(work_item)
return 'work is complete'
views.py
def my_view(request):
# the .delay() call here is all that's needed
# to convert the function to be called asynchronously
do_work.delay()
# we can't say 'work done' here anymore because all we did was kick it off
return HttpResponse('work kicked off!')
یه مورد دیگه هم هست من به شخص اصلا uwsgi
رو دوست ندارم و اکثرا از gunicorn
استفاده میکنم
ممنون میشم دلیلتون استفاده از gunicorn
را نسبت به uwsgi بگین
یکی از دلیل ها آسون بودن کانفیگ ، لاگ ، ورکر
gunicorn --workers=3 --threads=3 main:app
در این حد آسون
gunicorn --workers=3 --threads=3 main:app
توی این دستور process ها رو هم میتونم به همین صورت براش پاس بدم درسته
و این که برای رم 4 و cpu 2 چه کانفینگی پیشنهاد میدین
خوب یه چی بگم . اگه دیدی کارتو هندل میکنه استفادش کنید ، منم معمولا یه چیزی پیدا میکنم که کار کنه میتونید تست کیس بنویسید برای شبیه سازی
https://docs.djangoproject.com/en/3.0/topics/testing/overview/
نسبت به نیازتون متغیره . ۲ هسته ۴ رم کفایت میکنه ، استفاده کنید ، مانیتور کنید متوجه مصرف منابع میشین . الان که چیزی نیست
الان به این صورت درسته process رو اضافه کردم به کامندش
نگفتین؟؟
چی بگم ❊ این کامند ۳ تا ورکر ، ۳ تا threads سرو میکنه برای اپتون
۱۰ ، ۱۰۰ هرچند که ست کنید
CELERY_DEFAULT_QUEUE = 'default'
CELERY_QUEUES = (
Queue('default'),
Queue('priority_high'),
)
Run two daemon.
[email protected]:/$ celery worker -Q priority_high
[email protected]:/$ celery worker -Q default,priority_high
And route task.
your_task.apply_async(args=['...'], queue='priority_high')
+ google - celery-support-task-priorities
https://docs.celeryproject.org/en/latest/userguide/routing.html