🚫عجیب اما واقعی...

با افتخار اعلام میکنیم که در طرح "اول آورد 2" توانستیم 100 میلیون تومان اعتبار حمایتی از Avalai.ir عزیز کسب کنیم.
این طرح برای کسب و کارهای بزرگ است که اولین کسب و کار اسنپ فود بود که در این طرح قرار گرفت، اما با حمایت و لطف تیم خوب avalai ، رفهاب هم شامل این طرح شد، این برای ما تجربه ی شگفت آور و با ارزشی ست که گام بزرگی برای رشد Refhub.ir خواهد بود.

𝗧𝗼𝗽 𝟲 𝗚𝗮𝗺𝗲 𝗖𝗵𝗮𝗻𝗴𝗶𝗻𝗴 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 🚀

𝟭. 𝗥𝗲𝗰𝗿𝗲𝗮𝘁𝗲:
All existing instances are terminated at once, and new instances with the updated version are created

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: Yes
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Non-critical applications or during initial development stages

𝟮. 𝗥𝗼𝗹𝗹𝗶𝗻𝗴 𝗨𝗽𝗱𝗮𝘁𝗲:
Application instances are updated one by one, ensuring high availability during the process

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Periodic releases

𝟯. 𝗦𝗵𝗮𝗱𝗼𝘄:
A copy of the live traffic is redirected to the new version for testing without affecting production users

This is the most complex deployment strategy and involves establishing mock services to interact with the new version of the deployment

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Validating new version performance and behavior in a real environment

𝟰. 𝗖𝗮𝗻𝗮𝗿𝘆:
The new version is released to a subset of users or servers for testing before broader deployment

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Impact validation on a subset of users

𝟱. 𝗕𝗹𝘂𝗲-𝗚𝗿𝗲𝗲𝗻:
- Two identical environments are maintained: one with the current version (blue) and the other with the updated version (green)
- Traffic starts with blue, then switches to the prepared green environment for the updated version

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: No
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: High-stake updates

𝟲. 𝗔/𝗕 𝗧𝗲𝘀𝘁𝗶𝗻𝗴:
Multiple versions are concurrently tested on different users to compare performance or user experience

𝘋𝘰𝘸𝘯𝘵𝘪𝘮𝘦: Not directly applicable
𝘜𝘴𝘦 𝘤𝘢𝘴𝘦: Optimizing user experience

وقتی این پست رو داخل یکی از گروه های زیرساخت و شبکه ارسال کردم ، یکی از اعضای گروه نظر جالبی داشت که همینجا هم ارسالش میکنم تا شما هم بتونید مطالعه کنید .
در واقع این پست رو استارت گفتن موضوعی کرد که تامل برانگیز بود برای من ، به نوبه ی خودش نظری داد که درستی و یا غلط بودن اون نیاز به تجربه و درک عمیقی از این حوزه داره .
اما آیا راستی آزمایی اینچنین اظهار نظرات کار راحتی هست؟ آیا یک استاندارد واحد یا یک مدل ثابت یا به نقل از اساتید حوزه ی فیزیک ، "یک نظریه ی همه چیز" برای مباحث زیرساخت و دواپس وجود دارد؟
طرز بیان و دیدگاه ایشان گواه از ید طولا و دست و پنجه نرم کردن در این فیلد دارد ، شماهم وقت کردید مطالعه بفرمایید ، نظری یا نقدی و یا حتی تصدیقی داشتید بفرمایید .
مشارکت در فروم های فنی خیلی راه ساز و چاره ساز خواهد بود .

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

به طور کلی تکنولوژی ها میکروسرویس فقط به درد کمپانی های های تچ میخوره و سودش اینه که تیم های مختلف میتونن روش همزمان کار کنن و اختلالی روی هم ایجاد نکنن و اصلا بدرد شرکت های کوچیک متوسط و بزرگ نمیخوره سربار پردازشی و شبکه و مانیتورینگ و مدیریت میکرو سرویس ها فقط روی سرویس هایی که بیشتر از صد هزار ریکوست کانکارنت در لحظه دارن و تیمشون بیشتر از چند هزار نفر هست میتونه توجیح داشته باشه! وگرنه هزینه و پیچیدگی هاش بیشتر از منافعش هست

ارتباط بین میکرو سرویس ها سربار شبکه ایجاد میکنه
که همزمان باعث سربار پردازشی و مصرف منابع پردازشی میشه
همچنین باعث بوجود اومدن لتنسی میشه
تکرار داده ها و کشینگ های داخلی سربار پردازشی ایجاد میکنه
ساگا پترن ها سربار پردازشی دارن
اجرای جداگونه کانتینر ها منابع بیشتر مصرف میکنه تا یه سیستم مونولیتی
هرسرویس منابع مجزا نیاز داره و از همه مهم تر پورت جداگونه نیاز داره که استک داخلی کرنل رو فلود میکنه
امکانات مدیریت کانتینرها سربار پردازشی و شبکه ایجاد میکنه
عیب یابی زمانی که سرویس ها متعدد باشن به صورت منوال به شدت سخته و باید از زیپکین یا جی گر استفاده کنن که باز سربار پردازشی و شبکه ایجاد میکنه
مانیتورینگ و لاگ گزاری پیشرفته تری نیاز هست که باز سربار پردازشی و شبکه اضافی ایجاد میکنه

برنامه نویس های مبتدی معمولا درکی از شبکه و سخت افزارو نحوه اجرای کد ندارن یا اگر هم دارن خیلی سطحی هست ! برنامه نویس های حرفه ای معمولا هر ریکوست شبکه هر سویچ کانتکس روی سی پی رو حساب میکنن زمانی که دارن یه پروژه ای رو طراحی میکنن تا بتونن حداکثر توان پردازشی و شبکه رو از سخت افزار بگیرن و هزینه و منابع استفاده شده رو در سطح مناسب نگه دارن مثلا به زبون ساده بگم روی یه معماری درست مونولیتی که محاسبات فنی دقیق داشته باشه شما میتونید روی یه سرور با چهار هسته سی پی یو و دو گیگ رم تا حدود 500 هزار ریکوست همزمان رو ریسپانس بدین بدون لتنسی ! ولی وقتی از میکرو سرویس ها استفاده کنید و تمامی موارد بهینه سازی رو در نظر بگیرید حداکثر میتونید روی همون ماشین تا 1500 ریکوست همزمان رو پاسخ بدید و عملا منابع سیستم رو کامل مصرف کردید!

به طور مثال وقتی از پورت مپینگ استفاده میکنین اون پشت چه اتفاقی میوفته ؟ :
داکر مجبور میشه از NAT برای ترجمه آدرس ها و پورتهای بین شبکه هاست و کانتینر استفاده کنه که باعث سربار اضافی روی سی پی یو میشه
این باعث بوجود اومدن لتنسی میشه چون بسته ها باید از لایه نت عبور کنن
درخواست ها اول به پورت هاست میرسن و بعد به پورت کانتینر فوروارد میشن که این باعث فلود استک شبکه در سطح کرنل میشه و همچنین مسیر طولانی تری به نسبت ارتباط مستقیم هست
هر بسته داده از طریق بریدج شبکه داخلی داکر باید عبور کنه که باز سربار پردازشی اضافی وفلود استک شبکه میشه که باعث بروز لتنسی میشه
وقتی از پورت مپینگ استفاده کنین باز مجبورین از رول های iptables استفاده کنید که باز هم سربار پردازشی اضافی ایجاد میشه

برای درک موضوع :

هر کور سی پی یو در اصل یه حلقه است که با سرعت ثابت ( فرکانس سی پی یو ) داره اجرا میشه و هی کد های نرم افزار رو اجرا میکنه
وقتی شما مثلا 4 تا کور سی پی یو دارین یعنی در اصل چهار تا حلقه برای اجرای کد های نرم افزار دارین
حالا وقتی از ترد استفاده میکنید یا تعداد پروسس ها بیشتر از تعداد کور های سی پی یو هست تسک اسکجولر با استفاده از کانتکس سویچینگ بین اینها هی سویچ میکنه که بتونه همه رو همزمان اجرا کنه ! که خب این سویچ کردن خودش یک زمانی رو مصرف میکنه ! و بقیه باید توی صف منتظر بمونن تا سویچ روشون اتفاق بوفته!
اینکه میگیم سربار پردازشی یعنی این کار اضافه میره توی صف پردازش و تسک های قابل اجرا برای سی پی یو هی اضافه میشه ! و اینجوریه که سی پی یو مصرف میشه و شما توی مانیتورینگ میبینید مصرف سی پیو بالا رفته ! و اون لتنسی که اتفاق میوفته اینه یعنی تسک ها باید منتظر اجرا بمونن ! البته خیلی پیچیده تره و من سعی کردم به زبان ساده و مختصر توضیح بدم!

"We are like books"

اگر سایتی دارید که محتوای پارسی یا عربی داخلش قرارداره ، اما به صورت چپ به راست نمایش داده میشه ،
مثل همین ایرادی که من توی این پکیج Onlyoffice داشتم ، و براتون آزاردهنده هست ، میتونید از افزونه مناسبی استفاده کنید که براتون تمام محتویات رو به صورت راست به چپ بچینه .

محدودیت هایی داره ، مثلا گاهی ممکنه با ChatGPT مکاتبات پارسی داشته باشید ، خب همه چیز نرمال به نظر میرسه تا وقتی که ChatGPT تصمیم میگیره که اولین کلمه ی جمله رو با یک کلمه ی انگلیسی شروع کنه ، اون موقع هست که کارو خراب میکنه و همه ی جملات اون بخش رو به صورت چپ به راست نمایش میده .
این اکسنتشن اینجا اصلا بدرد بخور نیست ، و دردی رو دوا نمیکنه .

اما درکل بودنش خوبه ، مثل وقتایی که یک سایت خارجی زبان رو مطالعه میکنید ، و تصمیم عجیب غریبی میگیرد که تمام متن های سایت رو با کمک گوگل به پارسی ترجمه کنید ، اینجا با کمک این افزونه ، میتونید همه چیز رو راست به چپ کنید و از خواندن متون پارسی لذت ببرید.
آدرس نصب افزونه :
https://chromewebstore.google.com/detail/rtl-all/eilpimgcclncpehhmnnplnfokcmdiefa

RTL = Right To Left
LTR = Left To Right

Busy week

مشکل کند بودن سرعت انتقال فایل بر بستر شبکه ی لوکال !

گاهی پیش میاد که شما زیرساخت ارتباطی خودتون رو بالا بستید ، مثلا فیبر نوری زدید و به لحاظ تئوری سرعتی برابر با 10 گیگابیت بر ثانیه توان انتقال فایل دارید ، اما موضوعی که پیش میاد ، میبینید که در عمل این اتفاق نمیوفته و انتقال فایل با سرعت مثلا 100 مگابایت حالا با تلرانس بالا یا پایین تر داره انجام میشه ، چه علت هایی میتونه وجود داشته باشه؟

1- محدودیت‌های I/O دیسک:
اگر دیسک‌های هر دو ماشین مجازی (یا حتی دیسک‌های سرور میزبان) سرعت بالایی نداشته باشند، این می‌تواند باعث کاهش سرعت انتقال شود. به عنوان مثال، اگر دیسک‌های استفاده شده HDD هستند یا SSD با سرعت پایین دارند، ممکن است حتی با وجود اتصال شبکه سریع، محدودیت در سرعت خواندن یا نوشتن داده‌ها ایجاد شود.

2- حجم فایل و کش (Cache):
هنگام انتقال یک فایل بزرگ، ممکن است سیستم از کش برای پردازش داده‌ها استفاده کند. ابتدا ممکن است کش به سرعت پر شود و بعد از آن، انتقال داده‌ها به دلیل استفاده از دیسک‌های اصلی کاهش یابد.

3- محدودیت‌های نرم‌افزاری یا پروتکل انتقال:
اگر از پروتکل‌هایی مانند SMB یا FTP برای انتقال استفاده می‌کنید، ممکن است این پروتکل‌ها خود محدودیت‌هایی در سرعت انتقال داشته باشند. همچنین ممکن است نرم‌افزارهای امنیتی یا دیوار آتش به نوعی بر سرعت انتقال تاثیر بگذارند.

4- محدودیت‌های شبکه:
اگرچه اتصال شبکه 10 گیگابیت است، اما ترافیک شبکه ممکن است به دلایل مختلفی از جمله تداخل با سایر ترافیک‌ها، تنظیمات اشتباه در سوئیچ‌ها یا روترها، یا وجود مشکلات شبکه‌ای دیگر کاهش یابد. به عنوان مثال، MTU نامناسب (Maximum Transmission Unit) می‌تواند باعث قطعه قطعه شدن بسته‌ها و کاهش کارایی انتقال شود.

5- بار پردازشی و سیستم عامل:
بار زیاد پردازشی روی ماشین‌ها می‌تواند به کاهش سرعت انتقال داده‌ها منجر شود. اگر ماشین‌ها در حال انجام وظایف دیگر یا استفاده از منابع پردازشی باشند، انتقال فایل ممکن است کند شود.

6- پیکربندی VM و محدودیت‌های منابع:
گاهی اوقات محدودیت‌هایی که در پیکربندی ماشین‌های مجازی (مثل تخصیص RAM یا CPU) اعمال می‌شود می‌تواند سرعت انتقال داده را کاهش دهد.

برای حل یا بررسی این مشکل راه های مختلفی وجود دارد که ضمنی و گاهن خیلی کلی هستند :

استفاده از منابع سیستم (CPU، RAM، و دیسک) روی هر دو ماشین مجازی را بررسی کنید.
پیکربندی شبکه را بررسی کرده و مطمئن شوید که تنظیمات MTU مناسب است.
پروتکل‌های انتقال فایل را تغییر داده و از ابزارهای کم‌بارتر مانند rsync یا scp استفاده کنید.
بررسی کنید که آیا سایر برنامه‌ها در حال مصرف پهنای باند شبکه هستند یا خیر.

باید تمام المان های موجود برای رسیدن به نتیجه ی مورد نظرتون رو دقیق و اصولی محاسبه و بررسی و در نهایت هم کانفیگ کنید ،
توی این حوزه ، الابختکی تنظیم کردن و غیر اصولی ، سرویسی رو پیاده کردن ( که خیلی جاها این اتفاق میوفته ، چون اینطور جا افتاده که " اگه بلد نیستی اشکال نداره ، تو کار یاد میگیری" ) نه تنها به نتیجه ی مورد نظرتون نمیرسید ، بلکه باعث میشید منابع بلا استفاده بمونن و از حداثر توان خودشون استفاده نکنن ، این رو هم اضافه کنید که کلی منابع مالی هم این وسط از دست رفته است .

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

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

تفاوت GPT با MBR در یک قاب

#GPT
#MBR