TPS و Throughput در پیامک چیست؟ معیار درست برای سنجش ظرفیت زیرساخت

فرض کنید یک سامانهٔ بانکی یا فروشگاهی باید در زمانی کوتاه حجم زیادی اعلان یا رمز یک‌بارمصرف بفرستد. داشبورد ممکن است افزایش درخواست‌های پذیرفته‌شده را نشان دهد، اما هم‌زمان صف بلندتر شود و پیام‌ها دیر به مسیر اپراتوری برسند. برای یافتن گلوگاه باید نرخ ورودی و خروجی را در هر مرحله جدا اندازه گرفت. این راهنما تعریف TPS و Throughput، تفاوت اوج لحظه‌ای با ظرفیت پایدار و روش عملی برآورد ظرفیت را توضیح می‌دهد. نمای کلی اجزای مسیر را در معماری SMS Gateway سازمانی ببینید.

TPS پیامک و Throughput چه تفاوتی دارند؟

TPS مخفف Transactions Per Second است: تعداد عملیات تعریف‌شده‌ای که در یک ثانیه انجام می‌شوند. در یک API پیامک، ممکن است هر درخواست پذیرفته‌شده یک تراکنش شمرده شود؛ در اتصال SMPP، ممکن است معیار تعداد درخواست‌های submit_sm پذیرفته‌شده باشد. این دو تعریف الزاماً یکسان نیستند، زیرا یک درخواست API می‌تواند چند گیرنده یا چند بخش پیام داشته باشد.

Throughput یعنی نرخ عبور واقعی کار از یک مرز مشخص در یک بازهٔ معین. می‌توان آن را به‌صورت «تعداد پیام‌های خروجی از Gateway تقسیم بر مدت اندازه‌گیری» گزارش کرد. TPS معمولاً واحد شمارش عملیات در ثانیه است و Throughput مفهوم گسترده‌تری برای نرخ پردازش یا ارسال دارد. در گفتگوهای فنی، این دو اصطلاح گاهی به‌جای هم به کار می‌روند؛ برای تصمیم‌گیری، تعریف دقیق واحد و نقطهٔ اندازه‌گیری مهم‌تر از نام شاخص است.

TPS، MPS و تعداد بخش‌های پیام

در برخی سرویس‌ها واحد ظرفیت Messages Per Second یا MPS است و در برخی، تعداد بخش‌های پیام در ثانیه. پیام بلند، بسته به کدگذاری و طول محتوا، ممکن است به چند بخش تقسیم شود؛ بنابراین ۱۰۰ درخواست پیام لزوماً معادل ۱۰۰ بخش ارسالی نیست. در مستندات و قرارداد، روشن کنید سقف روی درخواست، گیرنده، پیام یا بخش پیام اعمال می‌شود. همچنین نرخ محدودشدهٔ API را با ظرفیت مسیر اپراتوری یکی نگیرید.

ظرفیت را در کدام نقطه اندازه بگیریم؟

مسیر معمول از سامانهٔ کسب‌وکار به API، صف، موتور مسیریابی پیامک، اتصال اپراتور و سپس شبکهٔ مقصد می‌رسد. هر مرز، نرخ ورودی و خروجی خودش را دارد. اگر فقط درخواست‌های پذیرفته‌شده در API را ثبت کنید، ممکن است فشار روی صف یا محدودیت اپراتور پنهان بماند.

برای هر شاخص، بازهٔ اندازه‌گیری، میانگین و صدک‌های تأخیر، نوع ترافیک و مسیر مربوط را ثبت کنید. یک نمودار دقیقه‌ای ممکن است جهش کوتاه چندثانیه‌ای را پنهان کند؛ نمودار ثانیه‌ای نیز برای سنجش رفتار پایدار به‌تنهایی کافی نیست. شناسهٔ پیام و زمان ثبت رویدادها کمک می‌کند نرخ را به تأخیر واقعی پیوند دهید. گزارش تحویل را نیز با زمان ایجاد درخواست و واگذاری به مسیر تطبیق دهید.

تفاوت Peak TPS با ظرفیت پایدار چیست؟

Peak TPS بیشترین نرخ دیده‌شده در یک پنجرهٔ کوتاه است؛ Throughput پایدار نرخی است که زیرساخت در بازهٔ طولانی‌تر، با تأخیر و خطای قابل‌قبول، حفظ می‌کند. یک آزمون چندثانیه‌ای ممکن است عدد بالایی نشان دهد، اما با پر شدن صف، محدودیت نرخ، کندی پایگاه داده یا تأخیر پاسخ اپراتور، همان نرخ در چند دقیقه ادامه‌پذیر نباشد.

برای سنجش معتبر، طول آزمون، الگوی ورود بار، تعداد بخش‌ها، تعداد مسیرها و معیار پایان موفق را از پیش تعریف کنید. «پذیرش API» به‌عنوان پایان آزمون، ظرفیت تحویل را نمی‌سنجد. در ترافیک واقعی، درخواست‌ها همیشه یکنواخت نیستند؛ کمپین‌ها، تراکنش‌های هم‌زمان و رویدادهای بیرونی می‌توانند موج کوتاه بسازند. تحلیل این وضعیت در مقالهٔ گلوگاه‌های Peak Traffic پیامک آمده است.

چه چیزهایی Throughput پیامک را محدود می‌کنند؟

۱. محدودیت API و پردازش Backend

اعتبارسنجی، ثبت درخواست، دسترسی به پایگاه داده و سرویس‌های جانبی می‌توانند نرخ پذیرش را محدود کنند. اگر خطا یا زمان پاسخ API با افزایش بار بالا برود، قبل از تغییر مسیر اپراتوری، همین لایه را بررسی کنید. تعداد اتصال‌ها و سیاست محدودسازی نرخ نیز باید با قرارداد سرویس هماهنگ باشد.

۲. Queue و اختلاف نرخ ورودی و خروجی

وقتی ورود پیام برای مدتی از خروج بیشتر باشد، موجودی صف افزایش می‌یابد. صف، جهش بار را جذب می‌کند اما ظرفیت جدید ایجاد نمی‌کند. طول صف، سن قدیمی‌ترین پیام، نرخ مصرف و زمان انتظار را کنار هم بخوانید. اگر صف پس از پایان موج هم کوچک نمی‌شود، احتمالاً گلوگاه پایدار وجود دارد. برای عیب‌یابی دقیق‌تر، راهنمای Queue پیامک را ببینید.

۳. محدودیت مسیر و اپراتور

مسیر بالادستی ممکن است سقف نرخ، پنجرهٔ هم‌زمانی، زمان پاسخ یا محدودیت‌های دیگر داشته باشد. تنظیم نرخ بالاتر در نرم‌افزار، سقف بیرونی را حذف نمی‌کند؛ ممکن است فقط صف یا خطای throttle را بیشتر کند. ظرفیت را به‌ازای مسیر، اپراتور، نوع شماره و مقصد با دادهٔ واقعی و شرایط قرارداد ارزیابی کنید.

۴. تلاش دوباره، خطا و پیام چندبخشی

Retry بدون کنترل می‌تواند همان پیام را دوباره وارد بار سیستم کند و در زمان ازدحام، ظرفیت مؤثر پیام‌های تازه را کاهش دهد. پیام چندبخشی نیز مصرف واقعی مسیر را نسبت به شمار درخواست‌ها بالا می‌برد. خطای گذرا، رد دائمی و وضعیت نامعلوم را جدا کنید؛ ارسال دوبارهٔ کورکورانه هم به نرخ فشار می‌آورد و هم خطر ارسال تکراری دارد. روش تصمیم‌گیری در سیاست Retry پیامک توضیح داده شده است.

چگونه ظرفیت موردنیاز SMS Gateway را برآورد کنیم؟

از نیاز کسب‌وکار شروع کنید: چند گیرنده، در چه بازه‌ای، با چه نوع پیام و چه موعدی باید پردازش شوند؟ سپس واحد را به پیام و بخش پیام تبدیل کنید. برای مثال، اگر ۱۲۰ هزار پیام مستقل باید طی ۲۰ دقیقه از درگاه عبور کنند، نرخ متوسط نظری ۱۰۰ پیام در ثانیه است. اگر هر پیام به‌طور متوسط ۱٫۲ بخش مصرف کند، بار مسیر حدود ۱۲۰ بخش در ثانیه خواهد بود؛ پیش از لحاظ‌کردن جهش بار، Retry، محدودیت مقصد و حاشیهٔ اطمینان. این فقط نمونهٔ محاسباتی است، نه مشخصات یک سرویس.

1. مرز سنجش را مشخص کنید: پذیرش API، خروج از صف یا پذیرش اپراتور؟ برای نیاز به تحویل، زمان گزارش تحویل را نیز جدا بررسی کنید.
2. الگوی بار را استخراج کنید: میانگین روزانه کافی نیست؛ بیشترین پنجره‌های چندثانیه‌ای و چنددقیقه‌ای را از دادهٔ واقعی بگیرید.
3. مصرف واقعی را محاسبه کنید: تعداد گیرنده، بخش‌های پیام، نرخ خطا و تلاش دوباره را لحاظ کنید.
4. مسیرها را جدا بسنجید: محدودیت هر اپراتور و مقصد را با نرخ خروجی واقعی مقایسه کنید؛ جمع ظرفیت اسمی مسیرها همیشه ظرفیت قابل‌استفاده نیست.
5. آزمون بار مرحله‌ای انجام دهید: هم نرخ پردازش و هم سن صف، تأخیر، خطا، CPU و زمان پاسخ مسیر را اندازه بگیرید.
6. هشدار عملیاتی تعریف کنید: رشد مداوم صف، افزایش سن پیام، افت نرخ پذیرش مسیر و افزایش خطا باید پیش از رسیدن به بحران دیده شوند.

اگر هدف، ارسال پیام زمان‌حساس است، «آخرین زمان مفید» هر پیام را نیز تعریف کنید. پیامی که بعد از پایان اعتبار کد به مقصد برسد، حتی اگر در آمار تحویل موفق باشد، هدف کسب‌وکار را برآورده نکرده است. ظرفیت‌سنجی باید نرخ و تأخیر را با هم ببیند؛ افزایش TPS اسمی بدون کنترل زمان انتظار صف، تجربهٔ مخاطب را بهتر نمی‌کند.

پرسش‌های رایج دربارهٔ TPS پیامک

TPS در پیامک یعنی چه؟

تعداد تراکنش‌های تعریف‌شده در هر ثانیه است. باید روشن باشد تراکنش، درخواست API، پیام پذیرفته‌شده یا عملیات دیگری است.

آیا TPS بالاتر یعنی پیامک سریع‌تر تحویل می‌شود؟

لزوماً خیر. TPS یک مرحله را می‌سنجد؛ صف، محدودیت مسیر و شبکهٔ مقصد بر زمان رسیدن و گزارش تحویل اثر دارند.

تفاوت TPS و MPS چیست؟

TPS تعداد تراکنش در ثانیه را می‌شمارد؛ MPS معمولاً پیام یا بخش پیام در ثانیه را توصیف می‌کند. تعریف دقیق MPS را در مستندات همان سرویس بررسی کنید.

چرا با وجود TPS مناسب، صف پیامک رشد می‌کند؟

ممکن است TPS مربوط به پذیرش API باشد، در حالی که نرخ خروج از صف یا پذیرش اپراتور کمتر از نرخ ورودی است. سن صف و نرخ هر مرحله را جدا پایش کنید.

برای Capacity Planning کدام عدد مهم‌تر است؟

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

منابع فنی: راهنمای Throughput و صف در Twilio، راهنمای مقیاس‌پذیری پیام‌رسانی Twilio، مستندات محدودیت نرخ AWS End User Messaging، مشخصات SMPP v3.4. این منابع مفاهیم عمومی را توضیح می‌دهند و نشانهٔ استفادهٔ تلیرکو از ارائه‌دهندهٔ مشخص نیستند.