পুরো report
সাধারণ আর সবচেয়ে ধীর page—পাশাপাশি।
সাধারণ page (p50) আর সবচেয়ে ধীর 5% (p95)—shopper-দের দেশ থেকে end to end মেপে, একই run-এর server time, success rate আর memory-ও দেখানো হয়েছে।
কর্মক্ষমতার রিপোর্ট
সত্যিকারের চলা দোকানে মেপেছি।সাধারণ hardware-এও দ্রুত।
নিজস্ব 2 vCPU server-এ চলা একটি ফ্যাশন দোকানে আমরা load test করেছি। আসল গ্রাহকদের journey তাদের নিজের দেশ থেকে পাঠানো হয়েছে। কতটা কাজ সামলাল, কীভাবে মাপলাম, আর আপনার business বড় হলেও কেন দ্রুত থাকবে—সব এখানে দেখুন।
সরাসরি চলা দোকান ও catalogগ্রাহকদের নিজের দেশ থেকে পাঠানোpage cache ছাড়া server timeসাধারণ PHP-FPM
ফিল্মটি দেখুন
2 vCPU-তে load test।
2 vCPU-তে একসঙ্গে 40 জন ক্রেতা: typical page ≈0.4 s, server time 83–89 ms, error ছাড়াই 99.97%।
83–89 mspage cache ছাড়া প্রতি পেজের server time
0.24–0.52 sএকসঙ্গে 20–30 জন গ্রাহক থাকলে সাধারণ পেজ
≈0.4 sএকসঙ্গে 40 জন গ্রাহক থাকলে সাধারণ পেজ
99.97%7,714টি request-এর একটিও error ছাড়া serve হয়েছে।
পরীক্ষায় কী দেখা গেল
ছোট server-এও যথেষ্ট জায়গা।
Application, PostgreSQL, Redis আর background worker—সবাই একই 2 vCPU server-এ চলেছে, যেখানে RAM ছিল 3.8 GB।
একসঙ্গে 20–30 জন গ্রাহক
সাধারণ পেজ 0.24–0.52 s, আর সবচেয়ে ধীর 5% পেজ 1.5 s-এর মধ্যে; CPU-র load ছিল অর্ধেকেরও কম।
একসঙ্গে 40 জন গ্রাহক
সাধারণ পেজের সময় প্রায় 0.4 s; CPU 58–83% থাকলেও আরও কাজের জায়গা ছিল।
প্রতি ঘণ্টায় 43,000–50,000 request
প্রতি সেকেন্ডে 12–14টি request হলেও একই ছোট server ব্যস্ত বিক্রির সময়ে সামলায়।
Memory-র ব্যবহার স্থির থাকে
পুরো test চলাকালীন web container-এর memory ব্যবহার ছিল 225–262 MiB; 2.4 GB-এর বেশি RAM খালি ছিল।
server-এ 83–89 ms
Sign-in করা ক্রেতার ক্ষেত্রে, page cache ছাড়া—server-এর জন্য সবচেয়ে কঠিন পরিস্থিতি।
Search-এর উত্তর প্রায় 170 ms-এ
একই ছোট server-এ পণ্য search-এর উত্তর আসতে server time প্রায় 170 ms লাগে।
কীভাবে মাপলাম
আসল দোকান, আসল shopper journey, আসল দূরত্ব।
বিশ্বাসযোগ্য সংখ্যার জন্য মাপার পরিস্থিতিও আপনার চেনা হওয়া দরকার। তাই ক্রেতারা যেভাবে আসে, সেভাবেই মেপেছি।
1
চালু একটি দোকান
2 vCPU, 3.8 GB server-এ আসল ফ্যাশনের পণ্যতালিকা আর checkout; সবকিছু একই box-এ।
2
আসল shopper journey
70% নতুন visitor ছিল, প্রত্যেকে এক থেকে চারটি page দেখে, search করে, cart-এ যোগ করে এবং click-এর মধ্যে 5–15 seconds পড়ে।
3
আসল দূরত্ব
k6, shopper-দের নিজের দেশ থেকে traffic পাঠায়; gzip on ছিল, আর প্রতিটি virtual shopper-এর নিজস্ব session ছিল।
4
সৎ সময়ের হিসাব
Page time-এ network ও TLS-ও ধরা আছে; server time-এ কোনো page cache নেই। ব্যবহার করা হয়েছে OPcache-সহ সাধারণ PHP-FPM।
কেন গতি থাকে
হালকা করে বানানো, প্রতি release-এ test করা।
দ্রুততার জন্য আমরা server upgrade কিনতে বলি না। এটা app কীভাবে বানানো হয় আর যাচাই করা হয়, তার ওপর নির্ভর করে।
শুরু থেকেই হালকা
আমরা মেপেছি, তারপর app-কে আরও হালকা ও দ্রুত করেছি।
প্রতিটি page server-এই render হয়, আর script চালু হওয়ার আগেই পড়া যায়। সব visitor-এর জন্য একই data cached files হিসেবে পাঠানো হয়; module শুধু কোনো request-এ দরকার হলেই চালু হয়।
- Storefront page 501 KB থেকে 78 KB-এ কমেছে
- আগে app উত্তর দিতে 480–770 ms লাগত, এখন 87–92 ms-এ ready হয়।
- Guest page host ও language অনুযায়ী cache হয়, তাই repeat visit-এ database লাগে না।
- সব image WebP-তে convert করা হয়েছে, আর slot অনুযায়ী size ঠিক করা হয়েছে।
আলাদা কোনো runtime লাগে না
সাধারণ hosting-এও দ্রুত।
standard PHP-FPM ও OPcache ব্যবহার করেই এই ফলাফল। Octane, Swoole, FrankenPHP বা JIT লাগে না। তাই Docker থাকা যেকোনো Linux server-এ একই speed পাবেন, আর চালু রাখার জন্য অদ্ভুত কিছু লাগে না।
সাধারণ PHP-FPMযে runtime সব PHP host-ই আগে থেকেই support করে
OPcache tune করাশুরু থেকেই বড় application সামলায়
হালকা queryRelated data আগেই load হয়, row by row নয়
Edge-এ cache করাGuest page-গুলোর সামনে চাইলে CDN
মান
প্রতিটি release একই যাচাই পেরোয়।
Release build হওয়ার আগে static analysis আর 14,000-এর বেশি automated test চলে। তাই নতুন feature আপনার দোকানকে চুপচাপ ধীর বা কম নির্ভরযোগ্য করে দেয় না।
প্রয়োজন হলে আরও বড় করা যায়
আরও গ্রাহক আসছে? নতুন করে সব লিখবেন না—capacity বাড়ান।
appটি CPU-bound, আর কোনো local state রাখে না। বেশি core পেলে capacity বাড়ে। আগে serverটিকে 4 vCPU-তে upgrade করুন, এরপর database-কে আলাদা server-এ নিন, তারপর load balancer-এর পেছনে আরও app server যোগ করুন।
Performance-এর প্রশ্ন
Speed নিয়ে সরাসরি উত্তর।
আমার server-এও কি এতটাই দ্রুত চলবে?
হ্যাঁ—আপনার গ্রাহকদের কাছাকাছি থাকা তুলনীয় 2 vCPU server-এ একই গতি পাবেন। Page-এর সময়ে network-ও ধরা পড়ে, তাই server size-এর মতোই hosting location গ্রাহকদের কাছে রাখা জরুরি।
একই সময়ে বেশি গ্রাহক বলতে কী বোঝায়?
একই সময়ে দোকান ঘুরে দেখছেন—এমন গ্রাহকদের কথা। তাঁরা প্রতিটি ক্লিকের পরে 5–15 seconds করে পড়েন। একসাথে 40 জন গ্রাহক থাকলে দোকানটি দিনে হাজার হাজার visitor সামলায়।
Traffic বাড়লে কী করব?
আগে serverটিকে 4 vCPU-তে upgrade করুন। এরপর database-এর জন্য আলাদা server নিন, তারপর load balancer-এর পেছনে app server যোগ করুন। প্রতিটি ধাপেই software আর data একই থাকবে।
Page cache করেন?
হ্যাঁ। Guest page প্রতিটি host ও language-এর জন্য আলাদা করে cache হয়, তাই একই visitor আবার ঢুকলে database লাগে না। সামনে CDN বসানোও যায়। এই page-এ দেওয়া server time page cache ছাড়া মাপা হয়েছে।
Octane বা Swoole কেন নয়?
এগুলোর দরকার নেই। সাধারণ PHP-FPM-এর মাধ্যমে hosting সহজ থাকে, আর performance-এর ধরনও সহজেই অনুমান করা যায়। appটি ইতিমধ্যেই যথেষ্ট lean, তাই special runtime ছাড়াই দ্রুত চলে।
নিজের server-এ চেষ্টা করুন।
plan সাজান, Docker দিয়ে deploy করুন, তারপর নিজের পণ্যের তালিকা দিয়েই গতি দেখুন।