تا به حال برایتان پیش آمده بعد گذشت چند ماه از لانچ کردن پروژه در وب، کیفیت و کارآمدی سایت کاهش پیدا کند؟

کاربرانتان اطلاع می دهند سایت کند شده و مانیتورینگ سایت تان نشان می‌دهد که Response Time بالا رفته.. و حتی CPU سرور دیگه کارآیی گذشته رو نداشته باشه.

در ادامه به بررسی دلایل احتمالی این مشکل می پردازیم.

دلایلی که موجب می‌شوند پروژه وب شما کند شود. (از دیدگاه Backend)

1. رشد دیتا بدون رشد دادن معماری پایگاه داده

2. API  هایی که به سرعت رشد کردند ولی Refactorها نه !

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

4. cache  که درست طراحی نشده

5.افزایش همزمانی ها (concurrency) بدون آمادگی سایت

6. سرویس های خارجی که تبدیل به گلوگاه شده اند

7. رشد logs و I/O بلاک کننده ها

8. معماری مونولیت (monolithic architecture) که بزرگ شده

9. ORM  که درست طراحی نشده

10. رشد بالای Background Job

11. وقتی Observability واقعی نیست

12. Debt، تکینگی که انباشته شده

1. رشد دیتا (Data) بدون رشد دادن معماری پایگاه داده

تقریبا در اکثر پروژه هایی که بعد مدتی کند می شوند، ریشه مشکل به یک چیز بر می گردد :

DataBase رشد کرده ولی Queryها باز طراحی نشده اند.

به عنوان مثال در اوایل، سایت با 1000 کوئری کاربر و 5000 کوئری درخواست مشکلی نداشت اما با گذشت زمان با وجود هزاران رکورد کاربر و درخواست، سرعت سایت کاهش پیدا کرده چون همون Query  های گذشته استفاده می شوند.

برای مثال:

SELECT * FROM orders WHERE user_id

وقتی Index درست نباشه، DataBase کل جدول رو Scan می کند. در حالی که بک اند در ابتدا برای مقیاس کوچک نوشته شده و برای مقیاس داده بزرگتر، Re-evaluate نشده.

نشانه‌های این مشکل به این شکل هستند:

1. افزایش تدریجی Response Time

2. Spike در CPU دیتابیس

3. افزایش Lock

راه‌حل این است :

از ابتدا Index  را درست طراحی کنید.

از Explain Plan استفاده کنید.

Slow Query Log را مانتیور کنید.

Pagination واقعی، نه Load All

2.  APIهایی که بزرگ شدند ولی Refactor نشدند

طبیعی‌ست که در اوایل پروژه Endpointها ساده باشند.

ولی به مرور در برنامه:

– Business Logic اضافه می‌شود.

– شرط‌ ها زیاد می‌شود.

– Validation سنگین می‌شود.

– Queryها چند برابر می‌شود.

این در حالی است که برنامه هنوز همان Endpoint اولیه را Patch می‌کند.

برای مثال در  یک API مثل GET /dashboard در ابتدا تنها تعداد سفارش ها انجام می شد اما بعد مدتی آمار فروش، نمودار ها، لیست آخرین کاربرا، پیشنهادات هوشمند، پیام‌های سیستم و Notificationها نیز درخواست می شوند. آن هم در داخل یک Request.

در نتیجه یک Request می تواند به  ۱۲ تا Query،  یا 3 call به سرویس خارجی و  2 محاسبه سنگین تبدیل شود. در حالی که کاربر باید برای نتیجه صبر کند.

بنابراین ReFactor کردن را نباید به تعویق انداخت!

3. Memory Leak در بک‌اند

اگر پروژه شما با زبان های Node.js ،Java یا  Python و یا هر Runtime طولانی‌ مدت نوشته شده باشد، Memory Leak می‌تواند تدریجی رخ دهد.

نشانه‌های آن شامل :

•  RAM هر روز بیشتر می‌شود
• بعد از چند ساعت یا چند روز سرور کند می‌شود
• Restart موقتاً مشکل را حل می‌کند

دلایل رایج این رخداد شامل این نقص ها است:

•  Cache بدون Expire
•  Objectهایی که Release نمی‌شوند
•  Event Listenerهای بدون Cleanup
•  Promiseهایی که Resolve نمی‌شوند

و چون سیستم اولش سریع بوده، ممکن است فکر می‌کنید مشکل از ترافیک است، در حالی که مشکل از مدیریت حافظه است.

4.  کش (Cache) که درست طراحی نشده

چه چیزی باید cache شود و چه چیزی نه! انتخاب شما روی سرعت سایت تاثیر دارد.

نشانه ها این ها هستند:

•  Cache Invalidation اشتباه
•  Cache Stale
•  Cache Stampede
•  Memory Overhead

مشکل بزرگ‌ اینجا است که خیلی از پروژه‌ها بدون Strategy کش می‌زنند. فقط Redis می‌گذارند چون باید باشد!

اما مسئله اینجا است که چه چیزی در سایت باید Cache شود، برای چه مدت و چه زمان باید پاک شود یا Refresh گردد.

این مسائل باید حتما درست طراحی گردند.

5. افزایش همزمانی (Concurrency) بدون آمادگی

پروژه شما در ابتدا ۲۰ کاربر همزمان دارد و ۶ ماه بعد ۲۰۰۰ کاربر همزمان.

در حالی که Connection Pool و Thread Pool همان قبلی است و Rate Limit و Queue وجود ندارد.

در این حالت :

•  Deadlock
•  Timeout
•  Exhaust شدن Connectionها

اشتباه اینجا است که خیلی از بک‌اندها برای Load واقعی تست نمی‌شوند. یعنی Load Testing انجام نشده و سیستم فقط در محیط Dev و با ۳ کاربر تست شده.

6. سرویس‌های خارجی (Third-party) که تبدیل به گلوگاه شدند

در ابتدا یک API پیامک، یک Payment Gateway، یک سرویس ایمیل وجود داشت و همه چیز سریع انجام می شد.

اما با رشد ترافیک، با Rate Limit و  بالا رفتن Latencyو Retryها مواجه می شویم و چون Callها Sync هستند، کل Response معطل می‌ماند.

اشتباه رایج این است که  External API را داخل Request مستقیم صدا زده می شوند.

در حالی که باید:

•  Async شود.
•  Queue شود.
•  Circuit Breaker داشته باشد.

7. رشد لاگ‌ها و I/O بلاک‌کننده

یکی از چیزهایی که کمتر دیده می‌شود اما تاثیر گذار است Logging بیش از حد می باشد.

برای مثال:

هر Request → ۵ لاگ

هر Error → Stack کامل

لاگ Sync روی Disk

در Load بالا، همین نوشتن لاگ تبدیل می‌شود به Bottleneck. به خصوص اگر SSD ضعیف باشد، یا فایل‌ها Rotate نشوند.

8. معماری مونولیت که بزرگ شده اما refactor خیر!

وقتی ۲۰۰ فایل Controller و  ۱۵۰ Service و ۴۰۰ مدل به همراه  هزاران Dependency همگی داخل یک Runtime باشند :

•  Deploy کند می‌شود
• Memory بالا می‌رود
• Cold Start طولانی می‌شود
• و هر Feature جدید Performance را کمی بدتر می‌کند.

مشکل از مونولیت نیست؛ مشکل Refactor نکردن آن است.

9. N+1 Query؛ مشکل اصلی در ORM

این را شاید تجربه کرده باشید که یک لیست سفارش دارید. برای هر سفارش یک Query کاربر و برای هر کاربر یک Query دیگر و… ، که در دیتای کم دیده نمی‌شود اما در دیتای زیاد فاجعه است.

راه‌حل این است:

•  Eager Loading
• استفاده از Join درست
• Query Aggregation

10. Background Jobهایی که ناگهان زیاد شدند

اگر Queue Monitor انجام نگردد، Delay بالا می‌رود، Retry زیاد می‌شود و سرور CPU Spike می‌کند. همچنین  Responseهای اصلی هم کند می‌شوند.

11. نبود Observability واقعی

خیلی پروژه‌ها وقتی کند می‌شوند تازه متوجه می شویم که ARM، Trace نداریم و  دقیق نمی دانیم کدام Query کند است و Bottleneck کجاست.

Performance بدون Measurement یعنی حدس زدن!

12. Debt تکنیکی که جمع شده

به تعویق انداختن اصلاحات و refactor  کردن ها، و ده ها کار ریز که انجامشان به تاخیر افتاده، پروژه را کند کرده اند و کار را سخت تر می کنند.

اگر بخواهیم واقع‌بین باشیم، پروژه‌های وب کند نمی‌شوند چون تکنولوژی مان بد است و…  کند می‌شوند چون:

1. بک اند مقیاس پذیر طراحی نشده است

2. مانیتور نشده‌اند

3. Refactor نشده‌اند

4. تحت Load واقعی تست نشده‌اند

برسی سریع

برای جلوگیری از کند شدن پروژه، این موراد رو حتما برسی کنید:

✅ Slow Query Log فعال
✅ Index بررسی‌شده
✅ Load Testing انجام‌شده
✅ Connection Pool تنظیم‌شده
✅ Cache Strategy مشخص
✅ External APIها Async
✅ Memory Monitor فعال
✅ APM فعال
✅ Refactor دوره‌ای

امیدوارم این جزئیات را به تعویق نیاندازید.

پیشنهاد می کنم مقاله “چگونه بک اند مقیاس پذیر طراحی کنیم” را هم مطالعه بفرمائید.