🛡 مدیریت درخواست‌های همزمان در Laravel با Session Blocking

در اپلیکیشن‌های پرترافیک مثل پرداخت، مدیریت موجودی یا رزرو، درخواست‌های همزمان می‌تونن باعث تداخل داده و باگ‌های جدی بشن. لاراول با یه قابلیت ساده ولی قدرتمند به اسم Session Blocking این مشکل رو حل کرده.

📌 چطوری کار می‌کنه؟
در Session Blocking با استفاده از atomic lock ها، فقط به یک درخواست در هر زمان اجازه می‌ده که اجرا بشه و بقیه باید صبر کنن یا تایم‌اوت می‌شن.

برای فعال‌سازی:
- از cache driverهایی مثل Redis استفاده کن.
- از session driver غیر از cookie مثل Redis یا database استفاده کن.
- در روت‌ها از متد ->block() استفاده کن:

Route::post('/products/update-stock', [StockController::class, 'updateStock'])->block(5, 10);

عدد اول: مدت زمان قفل (ثانیه)
عدد دوم: مدت زمانی که درخواست منتظر می‌مونه تا قفل آزاد شه

———————————————————
⚠️ ریسک‌ها و محدودیت‌ها
با وجود قدرت زیاد session blocking، باید حواست به محدودیت‌هاش هم باشه:

- خطر Deadlock: تنظیم نادرست زمان قفل‌ها مخصوصاً در فرایندهای پیچیده می‌تونه باعث بن‌بست بشه.

- افزایش بار سیستم: شکست‌های مکرر در قفل‌گذاری می‌توانند باعث افزایش سربار سیستم بشود. استفاده از مکانیزم‌های retry مؤثر توصیه می‌شه.

- وابستگی به کش: عملکرد این قابلیت به شدت وابسته به driver کش هست. پس حتماً باید Redis یا Memcached قوی و پایدار داشته باشی.

——————————————————-
🛠 جایگزین‌های session blocking
اگه احساس می‌کنی این راهکار مناسب پروژه‌ت نیست، گزینه‌های دیگه‌ای هم هست:

- گزینه Optimistic Locking: با استفاده از نسخه‌گذاری (versioning) تداخل در بروزرسانی‌ها رو تشخیص بده.

- صف‌های توزیع‌شده (Distributed Queues): عملیات رو به سیستم صف مثل RabbitMQ یا AWS SQS منتقل کن تا غیربلادرنگ (asynchronous) انجام بشه.

- محدودیت‌های دیتابیس: با تعریف constraint‌های خاص توی دیتابیس، از درج داده‌های تکراری جلوگیری کن.


🎯 نتیجه: Session Blocking ابزار فوق‌العاده‌ای برای مدیریت درخواست‌های حساسه، ولی باید با دقت و مانیتورینگ درست استفاده بشه.

منبع 👇
🔗لینک مقاله

#Laravel #PHP #ConcurrentRequests #SessionBlocking #توسعه_بک_اند #مدیریت_موجودی #رزرو_آنلاین #پرداخت_امن #برنامه_نویسی

@panicdev

💡 کلاس WeakMap در PHP: قهرمان خاموش برای مدیریت حافظه
در زمان توسعه بخش‌های پرفورمنس‌محور یک اپلیکیشن، متوجه شدم که WeakMap می‌تونه یه قهرمان خاموش باشه که زمانی که بهش نیاز داری، به دادت می‌رسه.

🔍 کلاس WeakMap چیست؟
در ظاهر، WeakMap مثل یه store کلید-مقدار عادی به نظر میاد. اما تفاوت اصلی اینجاست که WeakMap کلیدها رو به صورت weak reference نگه می‌داره، یعنی وقتی شی از حافظه پاک میشه، WeakMap به‌طور خودکار اون ورودی رو حذف می‌کنه. این ویژگی باعث میشه که نیازی به پاک‌سازی دستی داده‌ها نباشه و هیچ‌گونه حافظه‌ای به طور نادرست مصرف نشه.

📌 چرا این ویژگی اهمیت داره؟
فرض کنید در حال ساخت یک مدیریت مستندات یا مدیریت تصاویر هستید. هر شی (مثل یک فایل یا تصویر) ممکنه متادیتای پرهزینه‌ای برای محاسبه داشته باشه. می‌خواهید این متادیتا رو در هنگام استفاده از شی کش کنید ولی نیازی به پاک‌سازی دستی و نگرانی از نشت حافظه ندارید.

🛠 نمونه کد:
در کدی که در تصویر مشاهده میکنید . ما از WeakMap برای کش کردن متادیتای اشیاء استفاده می‌کنیم


🚀 نتیجه‌گیری

در نتیجه WeakMap برای مواردی مثل مدیریت کش متادیتا یا پردازش‌های پرهزینه بسیار مفیده، چرا که از نشت حافظه جلوگیری می‌کنه و با خودکار حذف کردن ورودی‌ها از حافظه، کار رو برای برنامه‌نویس راحت‌تر می‌کنه.

🔗 منبع: مقاله

#PHP #MemoryManagement #WeakMap #Cashing #Development #Backend #OptimizedCode


@panicdev

🚀 معرفی Laravel RagKit: دستیار هوشمند اسناد برای پروژه‌های لاراولی شما!

تا حالا دوست داشتید اپلیکیشن Laravel شما بتونه به‌صورت هوشمند به سوالات درباره مستندات پاسخ بده؟
با Laravel RagKit آشنا بشید — ابزار قدرتمند RAG (تولید تقویت‌شده با بازیابی) مخصوص لاراول!

🎯 مشکلاتی که حل می‌کنه:

* دیگه نیازی به جستجوی دستی توی اسناد نیست
* پاسخ‌های دقیق و وابسته به متن
* پردازش خودکار مستندات
* تعامل به سبک چت با اسناد شما

💡 مثال ساده:
فرض کنید یه SaaS دارید با مستندات زیاد. به جای اینکه کاربرها توی مستندات سردرگم بشن:

1️⃣ مستندات رو آپلود کنید:

RagKit::uploadDocument(
    $collection,
    'user-guide.pdf',
    [
        'category' => 'documentation',
    ]
);

2️⃣ اجازه بدید کاربرها سوال بپرسن:

$answer = RagKit::ask(
    $collection,
    "چطور رمز عبورم رو ریست کنم؟",
    null,
    []
);

3️⃣ جواب‌های هوشمند همراه با منبع دریافت کنید! 🎉

🔥 ویژگی‌های مهم:
• پردازش Async
• پشتیبانی از چند ارائه‌دهنده
• گفت‌وگوهای چتی
• خلاصه‌سازی و FAQ اسناد
• یکپارچه با لاراول

⚙️ شروع سریع:

composer require mohaphez/laravel-ragkit

🔗 لینک پروژه:

laravel-ragkit

#Laravel #هوش_مصنوعی #RAG #PHP #مستندسازی

@panicdev

خوب صحبت از Octane شد، گفتیم یه بررسی داشته باشیم تا در انتخاب استفاده ازش دقت لازم داشته باشید .


🚀 فرق بین Laravel یا Laravel Octane چیست ؟

باید گفت Laravel Octane یه نسخه جدا نیست، بلکه یه افزونه‌ست که روی Laravel اجرا می‌شه و مخصوص PHP 8 به بالاست.
هدفش فقط یه چیزه: سرعت! ⚡️

⚙️ مقایسه‌ی سرعت

در Laravel معمولی: حدود ۵۰۰ درخواست در ثانیه

در Laravel Octane: راحت بالای ۲۰۰۰ درخواست در ثانیه!
اونم با حداقل ۱۰ برابر عملکرد بهتر 🤯

🧠 چرا Octane اینقدر سریع‌تره؟
تو Laravel معمولی، هر درخواست باعث می‌شه PHP از اول همه چیزو لود کنه (بوت اپلیکیشن، سرویس‌ها، کانفیگ‌ها و...).
ولی تو Octane، همه اینا فقط یه بار لود می‌شن و بعدش تو حافظه می‌مونن، یعنی هر درخواست بعدی خیلی سریع‌تر انجام می‌شه!

💡 پس Octane باهوش‌تره و تکرارای اضافی رو حذف می‌کنه.

🌐 سرورهای Octane فرق دارن
خود Laravel معمولاً روی Apache یا Nginx با PHP-FPM اجرا می‌شه.
ولی Octane از Swoole یا RoadRunner به‌عنوان سرور استفاده می‌کنه و ترافیک باید به اینا هدایت بشه.

🧩فرق Stateful یا Stateless چیه؟
لاراول معمولی «Stateless»‌، یعنی هر درخواست جداست.
ولی Octane «نیمه-Stateful»‌، یعنی یه سری اطلاعات بین درخواست‌ها تو حافظه می‌مونه.

📌 مثال واقعی:
تو حالت Stateless، هر بار که صفحه‌ای باز می‌کنی، سرور بررسی می‌کنه که لاگین هستی یا نه.
تو حالت Stateful (مثل Octane)، سرور همون‌طور که وارد شدی، اطلاعاتت رو نگه می‌داره تا وقتی logout کنی!

🔧خوب Swoole یا RoadRunner؟ کدوم بهتره؟

میشه گفت Swoole سریع‌تره ولی باید روی PHP نصب بشه، با Xdebug و مانیتورینگ‌ها خوب کار نمی‌کنه.

درحالی که RoadRunner راحت‌تر نصب می‌شه و به تنظیم خاصی نیاز نداره، ولی کمی کندتر از Swoole‌.

🤔 بالاخره Octane رو استفاده کنیم یا نه؟
✅ بله، اگه سایتت زیر بار سنگینه یا سرعتش اذیتت می‌کنه
❌ نه، اگه با PHP 8 سازگار نیستی یا تیمت هنوز با مفاهیم stateful آشنا نیست

#Laravel #PHP #Octane

@panicdev

🚀خوب Laravel Octane واقعاً فوق‌العاده‌ست، اما...

همانطور که میدونید Laravel Octane به‌خاطر افزایش چشمگیر سرعت اپلیکیشن‌ها خیلی محبوب شده. چون حافظه‌ی اپ بین درخواست‌ها حفظ می‌شه، دیگه هر بار لازم نیست از اول بارگذاری بشه.
ولی همونطور که دوستمون @Mahdi_Saremi گفت باید ها و نباید ها دارد .
قبل از اینکه سریع بری سراغ استفاده ازش، باید یه‌سری نکات مهم رو بدونی تا سرت به سنگ نخوره! 🧠

👇 چند مورد از محدودیت‌ها و نکات مهم Octane رو باهم مرور کنیم:

🔁 1. برنامه دیگه Stateless نیست!

تو لاراول معمولی، هر درخواست از صفر اجرا می‌شه. ولی تو Octane همه چیز تو حافظه می‌مونه!
یعنی اگه تو یه درخواست یه متغیر مثل $user ست بشه و پاک نشه، ممکنه درخواست بعدی هم همون مقدار رو ببینه! 😱
✅ حتماً از Octane::reset() یا tick/booting برای پاک‌سازی وضعیت استفاده کن.

🔌 2. همه پکیج‌ها با Octane سازگار نیستن!

یه‌سری پکیج‌ها مثل پکیج‌های سشن یا احراز هویت که به lifecycle معمولی PHP وابسته‌ان، ممکنه تو Octane درست کار نکنن.
✅ قبل از استفاده از هر پکیجی، بررسی کن با Octane سازگاره یا نه. اگه ناسازگاره یا عوضش کن یا resetش کن.

🧠 3. نشت حافظه (Memory Leak)

چون پردازش‌ها طولانی‌ان، حافظه می‌تونه پر بشه و اپت کند یا حتی داون بشه!
✅ با تنظیم max_requests بعد از یه تعداد خاصی درخواست، worker رو ری‌استارت کن. حواست به مصرف رم باشه.

📦 4. مناسب کارای طولانی نیست

بله Octane برای درخواست‌های سریع و زیاد ساخته شده. کارای سنگین مثل آپلود فایل یا پردازش تصویری رو می‌تونه قفل کنه.
✅ این کارا رو بده به Queue یا jobهای پس‌زمینه.

🔀 5. محدودیت تو هم‌زمانی (Concurrency)
بسته به اینکه از Swoole یا RoadRunner استفاده می‌کنی، یه‌سری مشکلات خاص ممکنه پیش بیاد، مثل هم‌زمان نوشتن روی فایل.
✅ از lock و عملیات اتمی استفاده کن. اپ رو قبل از دیپلوی حسابی تست کن.

🐞 6. دیباگ و تست کردن عجیب می‌شه!

دیگه مثل قبل نمی‌تونی راحت dd() بزنی و نتیجه بگیری. چون ممکنه state قبلی تو worker هنوز بمونه!
✅ از ابزارهایی مثل Clockwork یا Laravel Debugbar استفاده کن. Log بگیر و از رویدادهای reset کمک بگیر.

🚀 7. تغییر تو دیپلوی و CI/CD

اگه بعد از دیپلوی workerها رو ری‌استارت نکنی، اپ ممکنه با کد یا تنظیمات قدیمی اجرا بشه!
✅ از ابزارهایی مثل Envoyer استفاده کن. حتماً بعد از دیپلوی بزن:

php artisan octane:restart

⚠️ جمع‌بندی
خوب Octane واقعاً عالیه برای اپ‌هایی که درخواست زیاد و سریع دارن. ولی باید با دقت و آگاهی ازش استفاده کنی، چون اگه آماده نباشی، ممکنه بیشتر از اینکه کمک کنه، دردسر درست کنه.


اینم یه ریپازیتوری که best-practice های مربوط به اکتان رو اوردن

laravel-octane-best-practices

#Laravel #PHP #Octane

@panicdev

وقتی پروژه 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

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


Design Patterns Part 1

Design Patterns Part 2


#php #laravel #design_pattern