Media is too big
VIEW IN TELEGRAM
پشت صحنه دستور pip install django چیه؟
یا غوداااا اینو تقریبا 4 سال و نیم پیش ضبط کردم.
خودم تا آخرش دیدم، یادم نبود چی میشه.
✔️ کاربرد فایل های setup.py و setup.cfg چیه؟
✔️ دستور pip install چطور متوجه وابستگی یا همون dependency های پکیج ها میشه؟
✔️ چطور میتونیم django-admin رو عوض کنیم و به جای اون از milad-admin استفاده کنیم؟ 😂
✅ جواب همه سوال های بالا رو توی یه ویدئو ۱۲ دقیقه ای بهتون میگم.
لینک آپارات:
https://www.aparat.com/v/ofjc5
لینک یوتیوب:
https://youtu.be/DUP9YU7_6jo
یا غوداااا اینو تقریبا 4 سال و نیم پیش ضبط کردم.
خودم تا آخرش دیدم، یادم نبود چی میشه.
✔️ کاربرد فایل های setup.py و setup.cfg چیه؟
✔️ دستور pip install چطور متوجه وابستگی یا همون dependency های پکیج ها میشه؟
✔️ چطور میتونیم django-admin رو عوض کنیم و به جای اون از milad-admin استفاده کنیم؟ 😂
✅ جواب همه سوال های بالا رو توی یه ویدئو ۱۲ دقیقه ای بهتون میگم.
لینک آپارات:
https://www.aparat.com/v/ofjc5
لینک یوتیوب:
https://youtu.be/DUP9YU7_6jo
🔥12❤4👍3🆒1
Forwarded from سید فرندز / برنامه نویسی / هک و امنیت / تکنولوژی (Mohammad Khoshnava)
پست محسن باقری CTO شرکت irantic در لینکدین :
فروش ۲۸ هزار صندلی در کمتر از ۱۵ دقیقه!!!
یکی از نفس‌گیرترین لحظه‌ها در صنعت تیکتینگ، شروع فروش یک ایونت بزرگ هستش.
روی صفحه همه‌چیز ساده به نظر میاد: یک دکمه‌ی "خرید بلیت" و تمام.
ولی پشت صحنه چه اتفاق‌هایی باعث میشه فروشی در این مقیاس به درستی انجام بشه؟ هزاران درخواست در یک لحظه به سرورها هجوم میارن و هر ثانیه‌اش می‌تونه تعیین‌کننده باشه.
ما سال‌ها در Irantic روی تیکتینگ سینما کار کردیم؛ جایی که بار روی سامانه به‌صورت یکنواخت و تدریجی پخش میشه.
اما وقتی رسیدیم به کنسرت علیرضا قربانی در پارکینگ ورزشگاه آزادی، همه‌چیز فرق کرد.
استقبال عجیب کاربرها، محدود بودن صندلی‌ها و رقابت شدید باعث شد تجربه‌ای کاملاً متفاوت رو پشت سر بذاریم.
اینجا همه‌چیز به چند ثانیه بستگی داشت. باید اپلیکیشن رو برای خرید بیش از صد هزار کاربر همزمان مدیریت می‌کردیم و در عین حال جلوی Race Conditionهایی رو می‌گرفتیم که می‌تونستن کل خرید رو به هم بریزن.
برای رسیدن به این هدف، تغییرات مهمی در سیستم دادیم:
- درخواست‌ها رو با لیست‌ها و کلیدهای مختلف در Redis بازطراحی کردیم تا هر لیست مستقل مدیریت بشه.
-بهینه‌سازی حجم داده‌های اپلیکیشن یکی از سخت‌ترین چالش‌ها بود. ما باید حجم ریسپانس را طوری کاهش می‌دادیم که بدون از دست دادن اطلاعات حیاتی، به اندازه‌ای کوچک بشه که معمولاً در یک سگمنت TCP منتقل بشه. وقتی داده در حجم پایین ارسال میشه، سرعت دریافت بالاتر، تأخیر کمتر و احتمال خطا نیز کمتر خواهد بود .البته در بعضی لحظات، حجم داده بیشتر از چند بایت میشد، ولی همون بهینه‌سازی برای چند ثانیه‌ی طلایی فروش، تفاوت بزرگی ایجاد کرد.
- کش رو طوری تنظیم کردیم که هر لیست با سیاست خودش پاک بشه.
- یک مرحله‌ی میانی به رزرو اضافه کردیم تا متد اصلی سبک‌تر بمونه.
- در فرانت‌اند، مهمترین دغدغه نمایش درست و استفاده بهینه از ریسورس ها در دستگاه‌ها بود. وقتی کاربر روی موبایل یا دسکتاپ وارد میشه، انتظار داره تجربه‌ای روان و بی‌نقص داشته باشه. این یعنی رندر شدن سریع صندلی‌ها، الگوریتم‌های دقیق برای جایگذاری صندلی‌ها در حالت‌های مختلف صفحه، و جلوگیری از افت کیفیت یا کندی. کوچک‌ترین باگ در این بخش می‌تونست کل تجربه خرید رو خراب کنه
- در زیرساخت (DevOps)، پایداری و مانیتورینگ مهمترین بخش برای ما بود. آماده‌سازی برای پیک ترافیک و مانیتورینگ لحظه‌ای باعث شد حتی در اوج فشار، سامانه بدون مشکل کارش رو انجام بده.
- بخش مهم دیگه، انجام استرس‌تست‌های واقعی بود؛ جایی که با شبیه‌سازی بار سنگین روی سامانه، قبل از روز رویداد تمام نقاط ضعف احتمالی رو شناسایی و رفع کردیم. همین تست‌ها باعث شد لحظه‌ی اصلی، غافلگیر نشیم.
نتیجه؟
تمام ۲۸ هزار صندلی در کمتر از ۱۵ دقیقه سولد اوت شد، بدون اینکه تجربه‌ی خرید کاربرها خدشه‌دار بشه.
✅ @SEYED_BAX
فروش ۲۸ هزار صندلی در کمتر از ۱۵ دقیقه!!!
یکی از نفس‌گیرترین لحظه‌ها در صنعت تیکتینگ، شروع فروش یک ایونت بزرگ هستش.
روی صفحه همه‌چیز ساده به نظر میاد: یک دکمه‌ی "خرید بلیت" و تمام.
ولی پشت صحنه چه اتفاق‌هایی باعث میشه فروشی در این مقیاس به درستی انجام بشه؟ هزاران درخواست در یک لحظه به سرورها هجوم میارن و هر ثانیه‌اش می‌تونه تعیین‌کننده باشه.
ما سال‌ها در Irantic روی تیکتینگ سینما کار کردیم؛ جایی که بار روی سامانه به‌صورت یکنواخت و تدریجی پخش میشه.
اما وقتی رسیدیم به کنسرت علیرضا قربانی در پارکینگ ورزشگاه آزادی، همه‌چیز فرق کرد.
استقبال عجیب کاربرها، محدود بودن صندلی‌ها و رقابت شدید باعث شد تجربه‌ای کاملاً متفاوت رو پشت سر بذاریم.
اینجا همه‌چیز به چند ثانیه بستگی داشت. باید اپلیکیشن رو برای خرید بیش از صد هزار کاربر همزمان مدیریت می‌کردیم و در عین حال جلوی Race Conditionهایی رو می‌گرفتیم که می‌تونستن کل خرید رو به هم بریزن.
برای رسیدن به این هدف، تغییرات مهمی در سیستم دادیم:
- درخواست‌ها رو با لیست‌ها و کلیدهای مختلف در Redis بازطراحی کردیم تا هر لیست مستقل مدیریت بشه.
-بهینه‌سازی حجم داده‌های اپلیکیشن یکی از سخت‌ترین چالش‌ها بود. ما باید حجم ریسپانس را طوری کاهش می‌دادیم که بدون از دست دادن اطلاعات حیاتی، به اندازه‌ای کوچک بشه که معمولاً در یک سگمنت TCP منتقل بشه. وقتی داده در حجم پایین ارسال میشه، سرعت دریافت بالاتر، تأخیر کمتر و احتمال خطا نیز کمتر خواهد بود .البته در بعضی لحظات، حجم داده بیشتر از چند بایت میشد، ولی همون بهینه‌سازی برای چند ثانیه‌ی طلایی فروش، تفاوت بزرگی ایجاد کرد.
- کش رو طوری تنظیم کردیم که هر لیست با سیاست خودش پاک بشه.
- یک مرحله‌ی میانی به رزرو اضافه کردیم تا متد اصلی سبک‌تر بمونه.
- در فرانت‌اند، مهمترین دغدغه نمایش درست و استفاده بهینه از ریسورس ها در دستگاه‌ها بود. وقتی کاربر روی موبایل یا دسکتاپ وارد میشه، انتظار داره تجربه‌ای روان و بی‌نقص داشته باشه. این یعنی رندر شدن سریع صندلی‌ها، الگوریتم‌های دقیق برای جایگذاری صندلی‌ها در حالت‌های مختلف صفحه، و جلوگیری از افت کیفیت یا کندی. کوچک‌ترین باگ در این بخش می‌تونست کل تجربه خرید رو خراب کنه
- در زیرساخت (DevOps)، پایداری و مانیتورینگ مهمترین بخش برای ما بود. آماده‌سازی برای پیک ترافیک و مانیتورینگ لحظه‌ای باعث شد حتی در اوج فشار، سامانه بدون مشکل کارش رو انجام بده.
- بخش مهم دیگه، انجام استرس‌تست‌های واقعی بود؛ جایی که با شبیه‌سازی بار سنگین روی سامانه، قبل از روز رویداد تمام نقاط ضعف احتمالی رو شناسایی و رفع کردیم. همین تست‌ها باعث شد لحظه‌ی اصلی، غافلگیر نشیم.
نتیجه؟
تمام ۲۸ هزار صندلی در کمتر از ۱۵ دقیقه سولد اوت شد، بدون اینکه تجربه‌ی خرید کاربرها خدشه‌دار بشه.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13❤4👍1