۲۱:۴۱
ᴡɪsᴘʏ | ویزپی
حرف دلت رو ناشناس به ویزپی برسون! کافیه پیامتو به @RazbanBot بدی. ما میرسونیم، تو فقط بزن 
اینم آیدیش برا دسترسی راحت تر به ربات اگه میخواید استفاده کنید (اگه نمیخواید به تیممون پیام ناشناس بدید) قراره یسری آپدیت ها هم داده بشه...@RazbanBot
۲۱:۴۷
ᴡɪsᴘʏ | ویزپی
حرف دلت رو ناشناس به ویزپی برسون! کافیه پیامتو به @RazbanBot بدی. ما میرسونیم، تو فقط بزن
یه چنل بزنیم هرکی ناشناس میده توش جوابشو بدیم؟
۲۱:۴۸
یه مشکل جالب توی رباتم داشتم که باعث شده بود سرورم شبیه گوگل کروم رم بخوره!
من دولوپر ربات @selfprobot هستم (از تیم ویزپی) و یه مدت متوجه شدم رباتم حدود ۱۵ گیگابایت رم مصرف میکنه. وقتی بررسی کردم دیدم حدود ۱۱۰۰ پروسس پایتون روی سرور در حال اجراست. طبیعتاً بازنویسی کامل همچین ربات بزرگی هم کار منطقیای نبود.
پس شروع کردم دنبال دلیل گشتن.
اولین سوالها اینا بود:- آیا قابلیتهای ربات بیش از حد سنگین شدن؟- دیتابیس مشکل داره و کانکشنها زیادن؟- یا جای دیگهای گلوگاه سیستم ایجاد شده؟
بعد از بررسیها فهمیدم مشکل اصلی از جایی میاد که اطلاعات سلفبات کاربران رو داخل فایلهای JSON ذخیره میکردم و هر پروسس مرتب اون فایلها رو میخوند و مینوشت.
حالا تصور کن ۱۰۰۰ نفر داخل یه کتابخونه کوچیک همزمان بخوان روی یه برگه چیزی بنویسن و بلند بخونن. طبیعتاً همهچیز به هم میریزه. دقیقاً همین اتفاق برای سرورم داشت میافتاد: تعداد زیادی پروسس همزمان داشتن فایل میخوندن، مینوشتن و کپی از اطلاعات نگه میداشتن.
حدود ۳ ساعت تحقیق کردم ببینم رباتهای بزرگ مثل رباتهای دیسکورد چطور این مشکل رو حل میکنن. اونجا با دو مفهوم مهم آشنا شدم:
Sharding و Worker Management
ایده سادهست:
به جای اینکه برای هر کاربر یک پروسس جدا اجرا بشه، کاربران بین چند ورکر تقسیم میشن. هر ورکر مسئول مدیریت تعداد مشخصی کاربره و عملیاتها رو برای اونها انجام میده.
مثلاً به جای:۱۱۰۰ پروسس جداًمیتونیم داشته باشیم:۱۲ ورکر که هر کدوم حدود ۱۰۰ کاربر رو مدیریت میکنن.
این کار چند تا مزیت مهم داره:- تعداد پروسسها به شدت کم میشه - دادههای تکراری کمتر در حافظه نگهداری میشن - عملیات خواندن/نوشتن متمرکزتر و کنترلشدهتر انجام میشه - فشار روی CPU و RAM خیلی کمتر میشه
نتیجه؟
مصرف رم ربات از حدود ۱۵ گیگابایت رسید به حدود ۱.۵ گیگابایت.
یعنی تقریباً ۱۰ برابر بهینهتر فقط با تغییر معماری پردازش.
گاهی وقتها مشکل از قدرت سرور نیست؛ از مدل طراحی سیستمه.و وقتی معماری درست بشه، هم سرور نفس میکشه هم ربات پایدارتر میشه.
نویسنده دارای کوه تجربه: @exactslash
#انتقال_تجربه #برنامه_نویسی@wispy
من دولوپر ربات @selfprobot هستم (از تیم ویزپی) و یه مدت متوجه شدم رباتم حدود ۱۵ گیگابایت رم مصرف میکنه. وقتی بررسی کردم دیدم حدود ۱۱۰۰ پروسس پایتون روی سرور در حال اجراست. طبیعتاً بازنویسی کامل همچین ربات بزرگی هم کار منطقیای نبود.
پس شروع کردم دنبال دلیل گشتن.
اولین سوالها اینا بود:- آیا قابلیتهای ربات بیش از حد سنگین شدن؟- دیتابیس مشکل داره و کانکشنها زیادن؟- یا جای دیگهای گلوگاه سیستم ایجاد شده؟
بعد از بررسیها فهمیدم مشکل اصلی از جایی میاد که اطلاعات سلفبات کاربران رو داخل فایلهای JSON ذخیره میکردم و هر پروسس مرتب اون فایلها رو میخوند و مینوشت.
حالا تصور کن ۱۰۰۰ نفر داخل یه کتابخونه کوچیک همزمان بخوان روی یه برگه چیزی بنویسن و بلند بخونن. طبیعتاً همهچیز به هم میریزه. دقیقاً همین اتفاق برای سرورم داشت میافتاد: تعداد زیادی پروسس همزمان داشتن فایل میخوندن، مینوشتن و کپی از اطلاعات نگه میداشتن.
حدود ۳ ساعت تحقیق کردم ببینم رباتهای بزرگ مثل رباتهای دیسکورد چطور این مشکل رو حل میکنن. اونجا با دو مفهوم مهم آشنا شدم:
Sharding و Worker Management
ایده سادهست:
به جای اینکه برای هر کاربر یک پروسس جدا اجرا بشه، کاربران بین چند ورکر تقسیم میشن. هر ورکر مسئول مدیریت تعداد مشخصی کاربره و عملیاتها رو برای اونها انجام میده.
مثلاً به جای:۱۱۰۰ پروسس جداًمیتونیم داشته باشیم:۱۲ ورکر که هر کدوم حدود ۱۰۰ کاربر رو مدیریت میکنن.
این کار چند تا مزیت مهم داره:- تعداد پروسسها به شدت کم میشه - دادههای تکراری کمتر در حافظه نگهداری میشن - عملیات خواندن/نوشتن متمرکزتر و کنترلشدهتر انجام میشه - فشار روی CPU و RAM خیلی کمتر میشه
نتیجه؟
مصرف رم ربات از حدود ۱۵ گیگابایت رسید به حدود ۱.۵ گیگابایت.
یعنی تقریباً ۱۰ برابر بهینهتر فقط با تغییر معماری پردازش.
گاهی وقتها مشکل از قدرت سرور نیست؛ از مدل طراحی سیستمه.و وقتی معماری درست بشه، هم سرور نفس میکشه هم ربات پایدارتر میشه.
نویسنده دارای کوه تجربه: @exactslash
#انتقال_تجربه #برنامه_نویسی@wispy
۱۳:۲۵
ᴡɪsᴘʏ | ویزپی
یه مشکل جالب توی رباتم داشتم که باعث شده بود سرورم شبیه گوگل کروم رم بخوره! من دولوپر ربات @selfprobot هستم (از تیم ویزپی) و یه مدت متوجه شدم رباتم حدود ۱۵ گیگابایت رم مصرف میکنه. وقتی بررسی کردم دیدم حدود ۱۱۰۰ پروسس پایتون روی سرور در حال اجراست. طبیعتاً بازنویسی کامل همچین ربات بزرگی هم کار منطقیای نبود. پس شروع کردم دنبال دلیل گشتن. اولین سوالها اینا بود: - آیا قابلیتهای ربات بیش از حد سنگین شدن؟ - دیتابیس مشکل داره و کانکشنها زیادن؟ - یا جای دیگهای گلوگاه سیستم ایجاد شده؟ بعد از بررسیها فهمیدم مشکل اصلی از جایی میاد که اطلاعات سلفبات کاربران رو داخل فایلهای JSON ذخیره میکردم و هر پروسس مرتب اون فایلها رو میخوند و مینوشت. حالا تصور کن ۱۰۰۰ نفر داخل یه کتابخونه کوچیک همزمان بخوان روی یه برگه چیزی بنویسن و بلند بخونن. طبیعتاً همهچیز به هم میریزه. دقیقاً همین اتفاق برای سرورم داشت میافتاد: تعداد زیادی پروسس همزمان داشتن فایل میخوندن، مینوشتن و کپی از اطلاعات نگه میداشتن. حدود ۳ ساعت تحقیق کردم ببینم رباتهای بزرگ مثل رباتهای دیسکورد چطور این مشکل رو حل میکنن. اونجا با دو مفهوم مهم آشنا شدم: Sharding و Worker Management ایده سادهست: به جای اینکه برای هر کاربر یک پروسس جدا اجرا بشه، کاربران بین چند ورکر تقسیم میشن. هر ورکر مسئول مدیریت تعداد مشخصی کاربره و عملیاتها رو برای اونها انجام میده. مثلاً به جای: ۱۱۰۰ پروسس جدا ً میتونیم داشته باشیم: ۱۲ ورکر که هر کدوم حدود ۱۰۰ کاربر رو مدیریت میکنن. این کار چند تا مزیت مهم داره: - تعداد پروسسها به شدت کم میشه - دادههای تکراری کمتر در حافظه نگهداری میشن - عملیات خواندن/نوشتن متمرکزتر و کنترلشدهتر انجام میشه - فشار روی CPU و RAM خیلی کمتر میشه نتیجه؟ مصرف رم ربات از حدود ۱۵ گیگابایت رسید به حدود ۱.۵ گیگابایت. یعنی تقریباً ۱۰ برابر بهینهتر فقط با تغییر معماری پردازش. گاهی وقتها مشکل از قدرت سرور نیست؛ از مدل طراحی سیستمه. و وقتی معماری درست بشه، هم سرور نفس میکشه هم ربات پایدارتر میشه. نویسنده دارای کوه تجربه: @exactslash #انتقال_تجربه #برنامه_نویسی @wispy
من دولوپر ربات @selfprobot هستم (از تیم ویزپی) و یه مدت متوجه شدم رباتم حدود ۱۵ گیگابایت رم مصرف میکنه. وقتی بررسی کردم دیدم حدود ۱۱۰۰ پروسس پایتون روی سرور در حال اجراست. طبیعتاً بازنویسی کامل همچین ربات بزرگی هم کار منطقیای نبود. پس شروع کردم دنبال دلیل گشتن. اولین سوالها اینا بود: - آیا قابلیتهای ربات بیش از حد سنگین شدن؟ - دیتابیس مشکل داره و کانکشنها زیادن؟ - یا جای دیگهای گلوگاه سیستم ایجاد شده؟ بعد از بررسیها فهمیدم مشکل اصلی از جایی میاد که اطلاعات سلفبات کاربران رو داخل فایلهای JSON ذخیره میکردم و هر پروسس مرتب اون فایلها رو میخوند و مینوشت. حالا تصور کن ۱۰۰۰ نفر داخل یه کتابخونه کوچیک همزمان بخوان روی یه برگه چیزی بنویسن و بلند بخونن. طبیعتاً همهچیز به هم میریزه. دقیقاً همین اتفاق برای سرورم داشت میافتاد: تعداد زیادی پروسس همزمان داشتن فایل میخوندن، مینوشتن و کپی از اطلاعات نگه میداشتن. حدود ۳ ساعت تحقیق کردم ببینم رباتهای بزرگ مثل رباتهای دیسکورد چطور این مشکل رو حل میکنن. اونجا با دو مفهوم مهم آشنا شدم: Sharding و Worker Management ایده سادهست: به جای اینکه برای هر کاربر یک پروسس جدا اجرا بشه، کاربران بین چند ورکر تقسیم میشن. هر ورکر مسئول مدیریت تعداد مشخصی کاربره و عملیاتها رو برای اونها انجام میده. مثلاً به جای: ۱۱۰۰ پروسس جدا ً میتونیم داشته باشیم: ۱۲ ورکر که هر کدوم حدود ۱۰۰ کاربر رو مدیریت میکنن. این کار چند تا مزیت مهم داره: - تعداد پروسسها به شدت کم میشه - دادههای تکراری کمتر در حافظه نگهداری میشن - عملیات خواندن/نوشتن متمرکزتر و کنترلشدهتر انجام میشه - فشار روی CPU و RAM خیلی کمتر میشه نتیجه؟ مصرف رم ربات از حدود ۱۵ گیگابایت رسید به حدود ۱.۵ گیگابایت. یعنی تقریباً ۱۰ برابر بهینهتر فقط با تغییر معماری پردازش. گاهی وقتها مشکل از قدرت سرور نیست؛ از مدل طراحی سیستمه. و وقتی معماری درست بشه، هم سرور نفس میکشه هم ربات پایدارتر میشه. نویسنده دارای کوه تجربه: @exactslash #انتقال_تجربه #برنامه_نویسی @wispyبرای این پست 900 مگ کانفیگ و کلی زمان صرف شده. با دکمه "پیشنهاد به مجله" از ما حمایت کن دایی جان!
۱۳:۲۶
اطلاعیه مهم ویزپیخبر خوب در راهه!
در آپدیت بعدی ربات همراز (@bchatbot) و رازبان (@razbanbot) که تا تاریخ ۳۱ اردیبهشت ۱۴۰۵ منتشر میشن، قابلیت ارسال مدیا دوباره فعال خواهد شد میدونیم منتظر بودید و قدردان صبوریتون هستیم
این چند وقت با حمایتهاتون بهمون انرژی دادید و باعث شدید با قدرت بیشتری ادامه بدیم از تکتک شما که کنار ما بودید صمیمانه و عمیقاً تشکر میکنیم
۱۳:۰۶
سرعت رازبان بهینه شد!الان پاسخها سریعتر، روانتر و بدون تأخیر انجام میشن. @razbanbot ویـزپی | @wispy
۱۶:۰۲
اطلاعیه مهمتغییرات قیمت در فروشگاه همراز انجام شده و قیمتها تا ۶ ماه آینده بدون تغییر باقی میمانند. خرید از فروشگاه همراز۲۱:۳۳
ᴡɪsᴘʏ | ویزپی اطلاعیه مهم تغییرات قیمت در فروشگاه همراز انجام شده و قیمتها تا ۶ ماه آینده بدون تغییر باقی میمانند. خرید از فروشگاه همراز
اطلاعیه مهم تغییرات قیمت در فروشگاه همراز انجام شده و قیمتها تا ۶ ماه آینده بدون تغییر باقی میمانند. خرید از فروشگاه همرازبخاطر روز پسر اولین اشتراکی که خریداری بشه بصورت پاکت تو چنل پخش میشه
۱۴:۵۵
ᴡɪsᴘʏ | ویزپی
بخاطر روز پسر اولین اشتراکی که خریداری بشه بصورت پاکت تو چنل پخش میشه
ایلیا ازینکارا از تو بعید بود
۱۴:۵۵
ᴡɪsᴘʏ | ویزپی
ایلیا ازینکارا از تو بعید بود
آقا ولش اصن بخاطر حمایت هاتون ۲۰۰ تمن پاکت میزارم نفری ۵ تمن خوبه دیگه
۱۴:۵۷
ᴡɪsᴘʏ | ویزپی
آقا ولش اصن بخاطر حمایت هاتون ۲۰۰ تمن پاکت میزارم نفری ۵ تمن خوبه دیگه
نا راضی ها هم ری اکشن گریه بزنن
۱۴:۵۹
پاکت هدیه
ᴡᴡɪsᴘʏ | ویزپی
روز پسر بر همگی مبارک
ᴡɪsᴘʏ | ویزپی
پاکت هدیه
حال میکنم همه سلف دارن
۱۵:۰۳
ᴡɪsᴘʏ | ویزپی
حال میکنم همه سلف دارن
دفعه بعدی لینک گپ میزارم سلف باتا نیان قبوله
۱۵:۰۵
آپدیت جدید همراز منتشر شد! آیدی ربات: @bchatbotهمونطور که قول داده بودیم، تا قبل از ۳۱ اردیبهشت آپدیت جدید منتشر شد و کلی ایراد برطرف شد )
همراهی شما باعث پیشرفت همرازه۱۴:۵۹