استخدام برنامهنویس ارشد (Full-Stack (PHP
شرط بررسی رزومه:
حداقل ۵ سال سابقه کار حرفهای در حوزه توسعه نرمافزار و برنامهنویسی
حقوق:
+۵۰ میلیون تومان
* طبیعتا بسته به تخصص و رزومه میتونید عدد مدنظرتون رو پیشنهاد بدید و محدودیتی وجود نداره)
مهارتهای فنی مورد نیاز:
تسلط کامل به PHP
آشنایی عمیق با معماری نرمافزار (Software Architecture)
آشنایی با Redis
تجربه در طراحی و توسعه API
آشنایی با Docker
و ...
https://jobinja.ir/1370018
شرط بررسی رزومه:
حداقل ۵ سال سابقه کار حرفهای در حوزه توسعه نرمافزار و برنامهنویسی
حقوق:
+۵۰ میلیون تومان
* طبیعتا بسته به تخصص و رزومه میتونید عدد مدنظرتون رو پیشنهاد بدید و محدودیتی وجود نداره)
مهارتهای فنی مورد نیاز:
تسلط کامل به PHP
آشنایی عمیق با معماری نرمافزار (Software Architecture)
آشنایی با Redis
تجربه در طراحی و توسعه API
آشنایی با Docker
و ...
https://jobinja.ir/1370018
🔥3
دوستان کسی تاحالا کورس سافت اسکیل از جایی شرکت کرده؟ نتیجهش چی بوده؟
کلا چطوری سافت اسکیل هاتون رو بهبود میدید؟
کلا چطوری سافت اسکیل هاتون رو بهبود میدید؟
این سه تا وصله فعلا
https://news.1rj.ru/str/proxy?server=151.244.85.30&port=70&secret=eed77db43ee3721f0fcb40a4ff63b5cd276D656469612E737465616D706F77657265642E636F6D
https://news.1rj.ru/str/proxy?server=151.244.85.66&port=85&secret=ee00ff000fffff00fff5555ffffffffff56D656469612E737465616D706F77657265642E636F6D
https://news.1rj.ru/str/proxy?server=151.244.85.48&port=443&secret=eed77db43ee3721f0fcb40a4ff63b5cd276D656469612E737465616D706F77657265642E636F6D
https://news.1rj.ru/str/proxy?server=151.244.85.30&port=70&secret=eed77db43ee3721f0fcb40a4ff63b5cd276D656469612E737465616D706F77657265642E636F6D
https://news.1rj.ru/str/proxy?server=151.244.85.66&port=85&secret=ee00ff000fffff00fff5555ffffffffff56D656469612E737465616D706F77657265642E636F6D
https://news.1rj.ru/str/proxy?server=151.244.85.48&port=443&secret=eed77db43ee3721f0fcb40a4ff63b5cd276D656469612E737465616D706F77657265642E636F6D
❤🔥4👍1👌1🕊1
⚠️ Update: #Iran has now been disconnected from the global internet for 36 hours; live metrics show national connectivity remains in the low few percent of ordinary levels with only a handful of users able to connect via multi-hop VPNs 📉
🔗 NetBlocks (@netblocks)
🔗 NetBlocks (@netblocks)
داشتم تجربه کسی که داشته روی روش های توسعه نرم افزار ژاپنی ها مطالعه میکرده میخوندم
به قدری ارزشمند و پر محتوا و قابل تعمل هستش که فک کردم به اشتراک گذاریش خالی از لطف نباشه .
طولانی هست ولی ارزش داره ، سعی میکنم در طول روز چند تیکشو بزارم .
امیدوارم که روزی این روش ها در جاهای دیگه دنیا (غرب و ایران ) هم قابل پیاده سازی باشه .🥺
———————————————————————-
می فرماید که :
سه ساله دارم روی روشهای توسعه نرمافزار ژاپنی مطالعه میکنم و چیزی که کشف کردم، دیدم رو نسبت به کدنویسی کاملاً تغییر داد.
در حالی که برنامهنویسهای غربی دائم درگیر آخرین فریمورک جاوااسکریپت هستن یا سر اینکه تب بزنن یا اسپیس، بحث میکنن، برنامهنویسهای ژاپنی بیسروصدا دارن یکی از قابلاعتمادترین و قابلنگهداریترین نرمافزارهای دنیا رو میسازن
رمز کارشون چیه؟
اونا با کد مثل یه تویوتا کمری رفتار میکنن، نه یه تسلا.
به قدری ارزشمند و پر محتوا و قابل تعمل هستش که فک کردم به اشتراک گذاریش خالی از لطف نباشه .
طولانی هست ولی ارزش داره ، سعی میکنم در طول روز چند تیکشو بزارم .
امیدوارم که روزی این روش ها در جاهای دیگه دنیا (غرب و ایران ) هم قابل پیاده سازی باشه .
———————————————————————-
می فرماید که :
سه ساله دارم روی روشهای توسعه نرمافزار ژاپنی مطالعه میکنم و چیزی که کشف کردم، دیدم رو نسبت به کدنویسی کاملاً تغییر داد.
در حالی که برنامهنویسهای غربی دائم درگیر آخرین فریمورک جاوااسکریپت هستن یا سر اینکه تب بزنن یا اسپیس، بحث میکنن، برنامهنویسهای ژاپنی بیسروصدا دارن یکی از قابلاعتمادترین و قابلنگهداریترین نرمافزارهای دنیا رو میسازن
رمز کارشون چیه؟
اونا با کد مثل یه تویوتا کمری رفتار میکنن، نه یه تسلا.
Please open Telegram to view this post
VIEW IN TELEGRAM
Panic Dev
داشتم تجربه کسی که داشته روی روش های توسعه نرم افزار ژاپنی ها مطالعه میکرده میخوندم به قدری ارزشمند و پر محتوا و قابل تعمل هستش که فک کردم به اشتراک گذاریش خالی از لطف نباشه . طولانی هست ولی ارزش داره ، سعی میکنم در طول روز چند تیکشو بزارم . امیدوارم…
فلسفهای که همهچیز را تغییر میدهد
مونوزوکوری (Monozukuri): هنر ساختن
در ژاپن مفهومی وجود دارد به نام مونوزوکوری — یعنی "هنر ساختن".
اما این فقط دربارهی تولید محصولات فیزیکی نیست؛ بلکه یک فلسفه است. فلسفهای که روی مهارت، بهبود مداوم، و افتخار به خود فرآیند ساخت تأکید دارد.
برنامهنویسهای ژاپنی فقط کد نمینویسن، اونو میسازن.
وقتی با هیروشی ناکامورا، یکی از مهندسهای ارشد یه شرکت بزرگ فناوری در ژاپن، مصاحبه کردم، اینطوری توضیح داد:
"در غرب، کد مینویسن که فیچر تحویل بدن. تو ژاپن، کد مینویسیم که دههها عمر کنه. اون فیچر فقط نقطهی شروعه."
این تغییر ذهنیت واقعاً عمیقه.
بهجای اینکه شعارشون "سریع حرکت کن و همهچی رو بشکن" باشه، برنامهنویسهای ژاپنی باور دارن به "آروم بساز و کاری نذار که خراب شه".
———————————————————————
کایزن (Kaizen): اصل ۱٪ بهتر شدن
احتمالاً اسم کایزن رو توی زمینهی بهبود کسبوکار شنیدی،
ولی برنامهنویسهای ژاپنی این مفهوم رو مستقیم روی کد پیاده میکنن.
بهجای بازنویسیهای سنگین یا ریفکتور کردن کل سیستم،
اونا بهبودهای کوچیک و مداوم انجام میدن — هر روز، با هر کامیت.
توی عمل یعنی چی؟ اینطوری: (در تصویر )
برنامهنویس ژاپنی منتظر مجوز برای بهبود کد نمیمونه،
واسه "اسپرینتِ بدهی فنی" برنامهریزی نمیکنه،
فقط هر روز یه ذره همهچی رو بهتر میکنه.
مونوزوکوری (Monozukuri): هنر ساختن
در ژاپن مفهومی وجود دارد به نام مونوزوکوری — یعنی "هنر ساختن".
اما این فقط دربارهی تولید محصولات فیزیکی نیست؛ بلکه یک فلسفه است. فلسفهای که روی مهارت، بهبود مداوم، و افتخار به خود فرآیند ساخت تأکید دارد.
برنامهنویسهای ژاپنی فقط کد نمینویسن، اونو میسازن.
وقتی با هیروشی ناکامورا، یکی از مهندسهای ارشد یه شرکت بزرگ فناوری در ژاپن، مصاحبه کردم، اینطوری توضیح داد:
"در غرب، کد مینویسن که فیچر تحویل بدن. تو ژاپن، کد مینویسیم که دههها عمر کنه. اون فیچر فقط نقطهی شروعه."
این تغییر ذهنیت واقعاً عمیقه.
بهجای اینکه شعارشون "سریع حرکت کن و همهچی رو بشکن" باشه، برنامهنویسهای ژاپنی باور دارن به "آروم بساز و کاری نذار که خراب شه".
———————————————————————
کایزن (Kaizen): اصل ۱٪ بهتر شدن
احتمالاً اسم کایزن رو توی زمینهی بهبود کسبوکار شنیدی،
ولی برنامهنویسهای ژاپنی این مفهوم رو مستقیم روی کد پیاده میکنن.
بهجای بازنویسیهای سنگین یا ریفکتور کردن کل سیستم،
اونا بهبودهای کوچیک و مداوم انجام میدن — هر روز، با هر کامیت.
توی عمل یعنی چی؟ اینطوری: (در تصویر )
برنامهنویس ژاپنی منتظر مجوز برای بهبود کد نمیمونه،
واسه "اسپرینتِ بدهی فنی" برنامهریزی نمیکنه،
فقط هر روز یه ذره همهچی رو بهتر میکنه.
👍8🔥1
توسعه بهموقع (Just-In-Time Development)
تیمهای نرمافزاری ژاپنی، سیستم معروف تولید تویوتا رو برای توسعهی نرمافزار بومیسازی کردن.
یکی از مفاهیم قدرتمند این سیستم، توسعه بهموقع (Just-In-Time) هست.
بهجای اینکه فیچرهایی بسازن که «شاید یه روزی لازم بشه»،
دقیقاً همون چیزی رو میسازن که الان لازمه — نه بیشتر، نه کمتر.
———————————————
جیدوکا (Jidoka): طرز فکر "خط تولید رو متوقف کن"
توی کارخانههای تویوتا، هر کارگری میتونه خط تولید رو کامل متوقف کنه اگه مشکلی ببینه.
تیمهای توسعه نرمافزار ژاپنی دقیقاً همین اصل رو پیاده میکنن:
اگه مشکلی وجود داشته باشه، همهچی متوقف میشه تا اون مشکل حل بشه.
نه از این حرفا که "تو اسپرینت بعدی درستش میکنیم"،
نه این که "فعلاً بفرستیم، بعداً یه پچ میدیم."
یه بار دیدم یه تیم ژاپنی دو روز وقت گذاشت تا یه باگ گوشهای رو دیباگ کنه که فقط روی ۰.۱٪ از کاربرا تأثیر داشت.
وقتی پرسیدم چرا فقط لاگش نکردن و رفتن سراغ بقیه کارا، مدیر تیم گفت:
«اگه یه اشکال کوچیک رو قبول کنیم، یعنی اشکال داشتن رو عادی کردیم. خیلی زود، پر از اشکال میشیم.»
شاید سختگیرانه بهنظر بیاد —
اما وقتی میبینی توی سیستمشون تقریباً هیچ باگ تولیدی وجود نداره، میفهمی چرا اینقدر جواب میده.
تیمهای نرمافزاری ژاپنی، سیستم معروف تولید تویوتا رو برای توسعهی نرمافزار بومیسازی کردن.
یکی از مفاهیم قدرتمند این سیستم، توسعه بهموقع (Just-In-Time) هست.
بهجای اینکه فیچرهایی بسازن که «شاید یه روزی لازم بشه»،
دقیقاً همون چیزی رو میسازن که الان لازمه — نه بیشتر، نه کمتر.
———————————————
جیدوکا (Jidoka): طرز فکر "خط تولید رو متوقف کن"
توی کارخانههای تویوتا، هر کارگری میتونه خط تولید رو کامل متوقف کنه اگه مشکلی ببینه.
تیمهای توسعه نرمافزار ژاپنی دقیقاً همین اصل رو پیاده میکنن:
اگه مشکلی وجود داشته باشه، همهچی متوقف میشه تا اون مشکل حل بشه.
نه از این حرفا که "تو اسپرینت بعدی درستش میکنیم"،
نه این که "فعلاً بفرستیم، بعداً یه پچ میدیم."
یه بار دیدم یه تیم ژاپنی دو روز وقت گذاشت تا یه باگ گوشهای رو دیباگ کنه که فقط روی ۰.۱٪ از کاربرا تأثیر داشت.
وقتی پرسیدم چرا فقط لاگش نکردن و رفتن سراغ بقیه کارا، مدیر تیم گفت:
«اگه یه اشکال کوچیک رو قبول کنیم، یعنی اشکال داشتن رو عادی کردیم. خیلی زود، پر از اشکال میشیم.»
شاید سختگیرانه بهنظر بیاد —
اما وقتی میبینی توی سیستمشون تقریباً هیچ باگ تولیدی وجود نداره، میفهمی چرا اینقدر جواب میده.
👍17🍓1
Panic Dev
توسعه بهموقع (Just-In-Time Development) تیمهای نرمافزاری ژاپنی، سیستم معروف تولید تویوتا رو برای توسعهی نرمافزار بومیسازی کردن. یکی از مفاهیم قدرتمند این سیستم، توسعه بهموقع (Just-In-Time) هست. بهجای اینکه فیچرهایی بسازن که «شاید یه روزی لازم بشه»،…
هفت نوع اتلاف در توسعه نرمافزار
(برگرفته از سیستم تولید تویوتا)
برنامهنویسهای ژاپنی با الهام از سیستم تولید تویوتا،
هفت نوع «اتلاف» یا Wastes در توسعه نرمافزار رو شناسایی کردن —
و هدفشون حذف یا کاهش این موارده:
۱. کارِ نیمهتمام
کدی که نوشته شده ولی تست نشده، بررسی نشده یا هنوز دیپلوی نشده.
تیمهای ژاپنی تا جای ممکن کار در جریان رو کم میکنن و تلاش میکنن کارهای کوچیک رو بهطور کامل و تموم انجام بدن.
۲. قابلیتهای اضافه
ساختن فیچرهایی که کاربر واقعاً نیاز نداره.
برنامهنویسهای ژاپنی استاد "نه گفتن" به رشد بیرویهی امکانات هستن.
۳. دوبارهیادگیری
وقتی زمان صرف میشه برای فهمیدن اینکه یه تکه کد چیکار میکنه — چون مستند نیست یا ساختار خوبی نداره.
برای همین، اونا روی نامگذاری واضح و کامنتنویسی دقیق خیلی تأکید دارن.
۴. تحویلهای دستبهدست
وقتی یه تیم کد رو فقط "پرتاب" میکنه سمت یه تیم دیگه.
ژاپنیها تیمهای چندمهارتهای رو ترجیح میدن که مسئولیت کامل یه فیچر رو از اول تا آخر به عهده بگیرن.
۵. تأخیرها
منتظر موندن برای تأیید، بررسی یا وابستگیها.
اونا تلاش میکنن بازخوردها رو سریعتر بگیرن و تیمهایی بسازن که مستقلتر عمل کنن.
۶. پرش بین کارها
مدام بین پروژهها یا فیچرهای مختلف جابهجا شدن.
برنامهنویسهای ژاپنی ترجیح میدن روی یک چیز تمرکز کنن و همون رو درست و کامل انجام بدن.
۷. باگها (نقصها)
خطاهایی که نیاز به اصلاح دارن و باعث نارضایتی کاربر میشن.
این بزرگترین اتلافه — و دلیلش هم اینه که ژاپنیها پیشگیری رو به تشخیص و اصلاح ترجیح میدن.
✨ نتیجه؟
سیستمی با کمترین اتلاف، تمرکز بالا، و کیفیتی که حتی بعد از سالها هم قابل اتکا باقی میمونه.
(برگرفته از سیستم تولید تویوتا)
برنامهنویسهای ژاپنی با الهام از سیستم تولید تویوتا،
هفت نوع «اتلاف» یا Wastes در توسعه نرمافزار رو شناسایی کردن —
و هدفشون حذف یا کاهش این موارده:
۱. کارِ نیمهتمام
کدی که نوشته شده ولی تست نشده، بررسی نشده یا هنوز دیپلوی نشده.
تیمهای ژاپنی تا جای ممکن کار در جریان رو کم میکنن و تلاش میکنن کارهای کوچیک رو بهطور کامل و تموم انجام بدن.
۲. قابلیتهای اضافه
ساختن فیچرهایی که کاربر واقعاً نیاز نداره.
برنامهنویسهای ژاپنی استاد "نه گفتن" به رشد بیرویهی امکانات هستن.
۳. دوبارهیادگیری
وقتی زمان صرف میشه برای فهمیدن اینکه یه تکه کد چیکار میکنه — چون مستند نیست یا ساختار خوبی نداره.
برای همین، اونا روی نامگذاری واضح و کامنتنویسی دقیق خیلی تأکید دارن.
۴. تحویلهای دستبهدست
وقتی یه تیم کد رو فقط "پرتاب" میکنه سمت یه تیم دیگه.
ژاپنیها تیمهای چندمهارتهای رو ترجیح میدن که مسئولیت کامل یه فیچر رو از اول تا آخر به عهده بگیرن.
۵. تأخیرها
منتظر موندن برای تأیید، بررسی یا وابستگیها.
اونا تلاش میکنن بازخوردها رو سریعتر بگیرن و تیمهایی بسازن که مستقلتر عمل کنن.
۶. پرش بین کارها
مدام بین پروژهها یا فیچرهای مختلف جابهجا شدن.
برنامهنویسهای ژاپنی ترجیح میدن روی یک چیز تمرکز کنن و همون رو درست و کامل انجام بدن.
۷. باگها (نقصها)
خطاهایی که نیاز به اصلاح دارن و باعث نارضایتی کاربر میشن.
این بزرگترین اتلافه — و دلیلش هم اینه که ژاپنیها پیشگیری رو به تشخیص و اصلاح ترجیح میدن.
✨ نتیجه؟
سیستمی با کمترین اتلاف، تمرکز بالا، و کیفیتی که حتی بعد از سالها هم قابل اتکا باقی میمونه.
👍3❤🔥2🔥1
داخل یک پروداکت، زمان پاسخگویی API هاشون به شدت بالا رفته بود.
بررسیها نشون داد که عامل اصلی، استفادهی زیاد از تابع
در هر درخواست، این تابع حدود 300 بار اجرا میشد. در نهایت دیدیم که فقط همین بخش باعث مصرف ۴۰٪ از کل زمان اجرای درخواست شده!
نتایج:
- میانگین زمان پاسخگویی از 700ms به 200ms رسید
- در 95٪ مواقع زمان پاسخ از 1.2s به 350ms کاهش پیدا کرد
- استفاده از CPU سرورها 35٪ کمتر شد
- تعداد درخواستهایی که تونستن در ثانیه پردازش کنند، تقریباً ۳ برابر شد!
-— دلیل اصلی این تفاوت اینه که isset():
- مستقیماً در سطح زبان PHP پیادهسازی شده
- هزینهی پردازش تابع نداره
- بسیار سریعتر اجرا میشه
—- در مقابل array_key_exists():
- باید پارامترها رو بررسی کنه
- نیاز به بررسی نوع داده داره
- زمان اجراش بیشتره
اما توجه:
اگر مقدار
در نسخههای جدید PHP (مثل PHP 8 به بعد)، استفاده از ?? (عملگر Null Coalescing) یک جایگزین بسیار سریع و تمیز برای هر دو هست:
منبع
#laravel #php
@panicdev
بررسیها نشون داد که عامل اصلی، استفادهی زیاد از تابع
array_key_exists() بود، اون هم در تابعی که برای هر محصول در API صدها بار اجرا میشد.در هر درخواست، این تابع حدود 300 بار اجرا میشد. در نهایت دیدیم که فقط همین بخش باعث مصرف ۴۰٪ از کل زمان اجرای درخواست شده!
نتایج:
- میانگین زمان پاسخگویی از 700ms به 200ms رسید
- در 95٪ مواقع زمان پاسخ از 1.2s به 350ms کاهش پیدا کرد
- استفاده از CPU سرورها 35٪ کمتر شد
- تعداد درخواستهایی که تونستن در ثانیه پردازش کنند، تقریباً ۳ برابر شد!
-— دلیل اصلی این تفاوت اینه که isset():
- مستقیماً در سطح زبان PHP پیادهسازی شده
- هزینهی پردازش تابع نداره
- بسیار سریعتر اجرا میشه
—- در مقابل array_key_exists():
- باید پارامترها رو بررسی کنه
- نیاز به بررسی نوع داده داره
- زمان اجراش بیشتره
اما توجه:
اگر مقدار
null برای شما معنیداره (مثلاً در تنظیمات یا اعتبارسنجی API)، باید همچنان از array_key_exists() استفاده کنید چون isset() برای مقادیر null مقدار false برمیگردونه و ممکنه کلید موجود باشه ولی مقدارش null باشه.در نسخههای جدید PHP (مثل PHP 8 به بعد)، استفاده از ?? (عملگر Null Coalescing) یک جایگزین بسیار سریع و تمیز برای هر دو هست:
$value = $array['key'] ?? 'default';منبع
#laravel #php
@panicdev
👍11👌2
1.4 میلیارد لاگ کاربر، بدون شاردینگ یا سیستمهای پیچیده – فقط با PostgreSQL 18!
سیستمی ستاپ کردن که :
بیش از 1.4 میلیارد لاگ فعالیت کاربر رو مدیریت میکنه
همزمانی بالا در خواندن و نوشتن رو پشتیبانی میکنه
درخواستهای مهم رو زیر 200ms پاسخ میده
❌ بدون شاردینگ
❌ بدون چند دیتابیس یا معماری پیچیده
✅ فقط PostgreSQL 18، با تنظیمات دقیق و بهینهسازی
لینک مقاله
#database #postgres
@panicdev
سیستمی ستاپ کردن که :
بیش از 1.4 میلیارد لاگ فعالیت کاربر رو مدیریت میکنه
همزمانی بالا در خواندن و نوشتن رو پشتیبانی میکنه
درخواستهای مهم رو زیر 200ms پاسخ میده
❌ بدون شاردینگ
❌ بدون چند دیتابیس یا معماری پیچیده
✅ فقط PostgreSQL 18، با تنظیمات دقیق و بهینهسازی
لینک مقاله
#database #postgres
@panicdev
Medium
How We Designed a 1 Billion Row System on PostgreSQL 18 (And Why It’s Blazing Fast)
When most engineers think of storing over a billion rows, they usually turn to distributed databases like Cassandra, Bigtable, or DynamoDB…
👍1
فیلامنت نسخه ۴ به صورت پایدار (stable) روز ۱۲ اگست ساعت ۱ بعد از ظهر (UTC) ریلیز و در دسترس میشه 🙌
به زمان ایران/تهران میشه سه شنبه هفته آینده (۲۱ مرداد) ساعت ۴:۳۰ بعد از ظهر🚀
به زمان ایران/تهران میشه سه شنبه هفته آینده (۲۱ مرداد) ساعت ۴:۳۰ بعد از ظهر
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍4🎉1
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👍1🤣1
وقتی پروژه PHP فقط روی سیستم خودت جواب میده و حس میکنی همه چیز اوکیه، تازه نصف راه رو رفتی! توی محیط واقعی (سرور)، داستان فرق میکنه.
اینجا سرعت، پایداری و مدیریت منابع حرف اول رو میزنن.
🛠 چند تا نکته مهم که باید رعایت کنی:
🔹 فعال کردن OPcache
وقتی این قابلیت روشن باشه، کدها فقط یه بار کامپایل میشن و داخل حافظه میمونن. این یعنی سرعت بالاتر و فشار کمتر روی CPU.
داخل php.ini این خطها رو اضافه یا اصلاح کن:
⚠️ یادت نره بعد از هر دیپلوی، PHP-FPM رو ریستارت کنی.
⚠️ یاد باشه که validate_timestamps روی ۱ نباشه ، اونوقت PHP شروع میکنه به چک کردن filesystem و بیشتر پتانسیل Opcache رو از دست میدی
🔹 تنظیم درست PHP-FPM
این سیستم چندتا «Worker» آماده نگه میداره تا درخواستها رو سریع جواب بدن. تعداد Worker ها باید با مقدار رم سرور هماهنگ باشه.
یه مثال:
چطور میتونی بفهمی هر ورکر چقدر مموری مصرف میکنه ؟
در این حالت روی سرور با ۸ گیگ رم و مصرف ۸۰ مگ برای هر php ورکر ، شما تقریبا میتونید ۶۰ عدد max_children داشته باشید .
🔹 استفاده از realpath cache
این کار باعث میشه مسیر فایلها رو PHP هی دوباره چک نکنه و سرعت بالاتر بره:
🔹 فعال کردن /status و slowlog
با /status میتونی ببینی چندتا کارگر فعاله و چندتا بیکار.
با slowlog هم میفهمی کدوم درخواستها طولانی اجرا میشن تا مشکل رو پیدا کنی.
📌 نتیجه نهایی:
اگر اوپکش فعال باشه، PHP-FPM درست تنظیم شده باشه، تایماوت بذاری، کش مسیرها فعال باشه و مانیتورینگ رو جدی بگیری، اپلیکیشن PHP توی سرور خیلی سریعتر، پایدارتر و قابل اعتمادتر کار میکنه.
@panicdev
#laravel #php
اینجا سرعت، پایداری و مدیریت منابع حرف اول رو میزنن.
🛠 چند تا نکته مهم که باید رعایت کنی:
🔹 فعال کردن OPcache
وقتی این قابلیت روشن باشه، کدها فقط یه بار کامپایل میشن و داخل حافظه میمونن. این یعنی سرعت بالاتر و فشار کمتر روی CPU.
داخل php.ini این خطها رو اضافه یا اصلاح کن:
opcache.enable=1
opcache.memory_consumption=192
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
⚠️ یادت نره بعد از هر دیپلوی، PHP-FPM رو ریستارت کنی.
⚠️ یاد باشه که validate_timestamps روی ۱ نباشه ، اونوقت PHP شروع میکنه به چک کردن filesystem و بیشتر پتانسیل Opcache رو از دست میدی
🔹 تنظیم درست PHP-FPM
این سیستم چندتا «Worker» آماده نگه میداره تا درخواستها رو سریع جواب بدن. تعداد Worker ها باید با مقدار رم سرور هماهنگ باشه.
یه مثال:
pm = dynamic
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
pm.max_requests = 1000
request_terminate_timeout = 30
چطور میتونی بفهمی هر ورکر چقدر مموری مصرف میکنه ؟
ps -o rss,cmd -C php-fpm | awk '{ sum+=$1 } END { print sum/NR/1024 " MB" }'در این حالت روی سرور با ۸ گیگ رم و مصرف ۸۰ مگ برای هر php ورکر ، شما تقریبا میتونید ۶۰ عدد max_children داشته باشید .
🔹 استفاده از realpath cache
این کار باعث میشه مسیر فایلها رو PHP هی دوباره چک نکنه و سرعت بالاتر بره:
realpath_cache_size = 4096k
realpath_cache_ttl = 600
🔹 فعال کردن /status و slowlog
با /status میتونی ببینی چندتا کارگر فعاله و چندتا بیکار.
با slowlog هم میفهمی کدوم درخواستها طولانی اجرا میشن تا مشکل رو پیدا کنی.
📌 نتیجه نهایی:
اگر اوپکش فعال باشه، PHP-FPM درست تنظیم شده باشه، تایماوت بذاری، کش مسیرها فعال باشه و مانیتورینگ رو جدی بگیری، اپلیکیشن PHP توی سرور خیلی سریعتر، پایدارتر و قابل اعتمادتر کار میکنه.
@panicdev
#laravel #php
🔥23👍7