চাপ পরীক্ষা

চাপ পরীক্ষার ফলাফল কোন উপাদানগুলির দ্বারা প্রভাবিত হয়?

  • চাপ মেশিন থেকে সার্ভারের নেটওয়ার্ক লেটেন্সি (অভ্যন্তরীণ নেটওয়ার্ক বা স্থানীয় চাপ পরীক্ষার পরামর্শ দেওয়া হয়)
  • চাপ মেশিন থেকে সার্ভারের ব্যান্ডউইথ (অভ্যন্তরীণ নেটওয়ার্ক বা স্থানীয় চাপ পরীক্ষার পরামর্শ দেওয়া হয়)
  • HTTP keep-alive সক্ষম আছে কিনা (সক্ষম করা পরামর্শ দেওয়া হয়)
  • সঙ্গত সংখ্যা যথেষ্ট কি না (বাহ্যিক নেটওয়ার্কের চাপ পরীক্ষায় সম্ভবmer বড় সঙ্গত সংখ্যা চালু রাখা উচিত)
  • সার্ভার প্রক্রিয়াগুলোর পরিমাণ কি যুক্তিসঙ্গত (helloworld ব্যবসায়ের জন্য প্রক্রিয়ার সংখ্যা CPU সংখ্যা সমান হওয়া উচিত, ডেটাবেস ব্যবসায়ের জন্য প্রক্রিয়ার সংখ্যা CPU-এর চার গুণ বা তার বেশি হওয়া উচিত)
  • ব্যবসার নিজস্ব কার্যকারিতা (যেমন বাহ্যিক নেটওয়ার্কের ডেটাবেস ব্যবহার করা হয়েছে কি না)

HTTP keep-alive কি?

HTTP Keep-Alive মেকানিজম একটি প্রযুক্তি যা একটি একক TCP সংযোগে একাধিক HTTP অনুরোধ এবং প্রতিক্রিয়া প্রেরণ করার জন্য ব্যবহৃত হয়, এটি কর্মক্ষমতা পরীক্ষার ফলাফলের উপর বড় প্রভাব ফেলে, keep-alive বন্ধ করার পর QPS কয়েকগুণ কমে যেতে পারে। বর্তমানে, সমস্ত ব্রাউজার ডিফল্টভাবে keep-alive সক্ষম করে, অর্থাৎ ব্রাউজার যখন একটি নির্দিষ্ট HTTP ঠিকানায় প্রবেশ করে তখন এটি সংযোগটিকে সাময়িকভাবে বন্ধ না করে রেখে দেয়, পরবর্তী অনুরোধে এই সংযোগটি পুনরায় ব্যবহার করে কর্মক্ষমতা বাড়াতে। চাপ পরীক্ষার সময় keep-alive সক্রিয় করা পরামর্শ দেওয়া হয়। এছাড়াও, যদি keep-alive বন্ধ থাকে, ক্লায়েন্টের স্থানীয় পোর্ট খুব শীঘ্রই timewait অবস্থায় সম্পূর্ণ ব্যবহার হয়ে যাবে, যার ফলে মোট অনুরোধের সংখ্যা একটি নির্দিষ্ট সংখ্যার (সাধারণত প্রায় 28,000) বেশি হলে ব্যর্থ অনুরোধ দেখা দেবে।

চাপ পরীক্ষায় কিভাবে HTTP keep-alive সক্রিয় করবেন?

যদি আপনি ab প্রোগ্রামের মাধ্যমে চাপ পরীক্ষা করেন তবে -k প্যারামিটারটি যুক্ত করতে হবে, যেমন ab -n100000 -c200 -k http://127.0.0.1:8787/। apipost-এ keep-alive সক্রিয় করতে হলে ফিরতি হেডারে gzip হেডার থাকতে হবে (apipost-এর বাগ, নীচে দেখতে পারেন)। অন্যান্য চাপ পরীক্ষার প্রোগ্রাম সাধারণত ডিফল্টভাবে সক্রিয় থাকে।

বাহ্যিক নেটওয়ার্কে চাপ পরীক্ষা করার পর QPS খুব কম কেন?

বাহ্যিক নেটওয়ার্কের লেটেন্সি অত্যন্ত বেশি হওয়ার কারণে QPS খুব কম হওয়া সাধারণ একটি ঘটনা। উদাহরণস্বরূপ, baidu পৃষ্ঠার চাপ পরীক্ষায় QPS হয়তো শুধু কয়েকজন। অভ্যন্তরীণ নেটওয়ার্ক বা স্থানীয় চাপ পরীক্ষার পরামর্শ দেওয়া হয়, নেটওয়ার্ক লেটেন্সির প্রভাব বাতিল করার জন্য। যদি বাহ্যিক নেটওয়ার্কের চাপ পরীক্ষা চালানো আবশ্যক হয়, তবে সঙ্গত সংখ্যা বাড়িয়ে throughput বৃদ্ধি করতে পারেন (ব্যান্ডউইথ যথেষ্ট হতে হবে তা নিশ্চিত করুন)।

nginx প্রক্সির মাধ্যমে পারফরম্যান্স হ্রাস পাচ্ছে কেন?

nginx চালানোর জন্য সিস্টেমের সম্পদ ব্যবহার প্রয়োজন। একইসাথে, nginx এবং webman এর মধ্যে যোগাযোগও কিছু সম্পদ খরচ করে। তবে, সিস্টেমের সম্পদ সীমিত, webman সব সিস্টেম সম্পদ পেতে পারে না, তাই পুরো সিস্টেমের পারফরম্যান্স কিছুটা হ্রাস পাওয়া স্বাভাবিক। nginx প্রক্সি দ্বারা আনা পারফরম্যান্সের প্রভাব কমানোর জন্য, nginx লগ বন্ধ করার কথা বিবেচনা করতে পারেন (access_log off;), webman এর সাথে nginx এর মধ্যে keep-alive সক্রিয় করুন, nginx প্রক্সি দেখে নিন।

এছাড়াও https এবং http এর তুলনায় অধিক সম্পদ সংকুচিত করে, কারণ https SSL/TLS হাতে নেওয়া, ডেটা এনক্রিপশন এবং ডিক্রিপশন করতে হয়, প্যাকেটের আকার বৃদ্ধি পায় এবং আরও ব্যান্ডউইথ গ্রহণ করে, এগুলি পারফরম্যান্স কমায়। চাপ পরীক্ষায় অল্প সংযোগ (HTTP keep-alive বন্ধ) ব্যবহার করা হলে, প্রতিটি অনুরোধে অতিরিক্ত SSL/TLS হাতাকাঁপা যোগাযোগ প্রয়োজন, এটি কার্যকারিতা বড়ভাবে কমায়। চাপ পরীক্ষায় https এ HTTP keep-alive সক্রিয় করার পরামর্শ দেওয়া হয়।

কিভাবে জানবেন সিস্টেম ইতিমধ্যেই পারফরম্যান্সের চূড়া স্পর্শ করেছে?

সাধারণত, CPU 100% হলে বোঝায় যে সিস্টেমের কার্যকারিতা চূড়ান্ত গিয়ে পৌঁছেছে। যদি CPU তে কিছু খালি স্থান থাকে তবে বোঝায় এখনও চূড়ান্ত স্পর্শ হয়নি, তখন কিছুটা সঙ্গত বাড়িয়ে QPS বাড়ানো যেতে পারে। যদি সঙ্গত বাড়ানোর ফলে QPS বৃদ্ধি না পায় তবে সম্ভবত webman প্রক্রিয়ার সংখ্যা কম, আপনাকে webman প্রক্রিয়া বাড়াতে হবে। যদি তাও কার্যকরী না হয়ে থাকে তবে ব্যান্ডউইথ যথেষ্ট কিনা তার বিবেচনা করতে হবে।

কেন আমি চাপ পরীক্ষায় দেখতে পাচ্ছি webman পারফরম্যান্স go এর gin ফ্রেমওয়ার্ক থেকে কম?

techempower চাপ পরীক্ষায় দেখায় যে webman অনন্য টেক্সট, ডেটাবেস অনুসন্ধান, ডেটাবেস আপডেট ইত্যাদির সকল সূচকে gin এর কাছাকাছি এক গুণ বেশি খরচ করে। যদি আপনার ফলাফল আলাদা হয়, তবে সম্ভবত আপনি webman এর মধ্যে ORM ব্যবহার করবেন যার ফলে ক্রমবর্ধমান কার্যকারিতা ক্ষতি হয়েছে, আপনি webman+প্রাকৃতিক PDO এবং gin+প্রাকৃতিক SQL তুলনা করে দেখতে পারেন।

webman-এ ORM ব্যবহার করলে কতটা কার্যকারিতার ক্ষতি হয়?

নিচে একটি চাপ পরীক্ষার তথ্যের সেট দেওয়া হলো।

পরিবেশ
সার্ভার আলিবাবা ক্লাউড 4 কোর 4G, স্থানীয় MySQL ডেটাবেস, ১০০,০০০ রেকর্ড থেকে এলোমেলো একটি রেকর্ড অনুসন্ধান করে json ফেরত, স্থানীয় চাপ পরীক্ষা।

যদি প্রাকৃতিক PDO ব্যবহার করা হয়
webman QPS হচ্ছে 1.78万

যদি laravel এর Db::table() ব্যবহার করা হয়
webman QPS হ্রাস পেয়ে 0.94万 QPS হয়

যদি laravel এর Model ব্যবহার করা হয়
webman QPS হ্রাস পেয়ে 0.72万 QPS হয়

thinkORM এর ফলাফল কিছুটা অনুরূপ, পার্থক্য উল্লেখযোগ্য নয়।

দ্রষ্টব্য
যদিও ORM ব্যবহার করলে কার্যকারিতার কিছুটা ক্ষতি হয়, কিন্তু 99% ব্যবসার জন্য কার্যকারিতা ইতোমধ্যে অভূতপূর্ব, যদি আপনি ঠিক ওই 1% হন তাহলে CPU বা সার্ভার বৃদ্ধি করে সহজেই সমস্যার সমাধান করতে পারেন। আমাদের উচিত উন্নয়ন দক্ষতা, রক্ষণাবেক্ষণযোগ্যতা, কার্যকারিতা এবং অন্যান্য সূচকের মধ্যে একটি ভারসাম্য খুঁজে বের করা, কেবলমাত্র কার্যকারিতার পেছনে দৌড়ানো নয়।

কেন apipost দিয়ে চাপ পরীক্ষায় QPS খুব কম?

apipost-এর চাপ পরীক্ষার মডিউলে একটি বাগ আছে, যদি সার্ভার gzip হেডার ফেরত না দেয় তবে keep-alive বজায় রাখা যায় না, যা কার্যকারিতার ব্যাপক ক্ষতির কারণ। সমাধান হচ্ছে ডেটা সংকুচিত করে ফিরতি সময় gzip হেডার যুক্ত করা, যেমন

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

এছাড়া apipost কিছু পরিস্থিতিতে সন্তোষজনক চাপ তৈরি করতে সক্ষম নয়, এর ফলে সমান সঙ্গতের সাথে apipost ab-এর তুলনায় প্রায় 50% কম QPS দেখাবে। চাপ পরীক্ষার জন্য ab, wrk বা অন্যান্য পেশাদার চাপ পরীক্ষার সফ্টওয়্যার ব্যবহার করার পরামর্শ দেওয়া হয়, apipost নয়।

উপযুক্ত প্রক্রিয়ার সংখ্যা সেট করা

webman ডিফল্টভাবে cpu*4 এর প্রক্রিয়া সংখ্যা খুলে দেয়। বাস্তবে, নেটওয়ার্ক IO-এর অভাবের জন্য helloworld ব্যবসায়ের চাপ পরীক্ষার প্রক্রিয়ার সংখ্যা CPU কোর সREG প্রস্তুত করার জন্য পারফরম্যান্স সর্বাধিক হয়, এটি প্রক্রিয়া পরিবর্তনের খরচ কমাতে পারে। ডেটাবেস, redis ইত্যাদি ব্লকিং IO ব্যবসার ক্ষেত্রে, প্রক্রিয়ার সংখ্যা CPU-এর 3-8 গুণ হিসাবে সেট করা যেতে পারে, কারণ তখন আরও প্রক্রিয়ার প্রয়োজন সঙ্গত বাড়ানোর জন্য, এবং ব্লকিং IO-র সাথে প্রক্রিয়া পরিবর্তনের খরচ প্রায় অবহেলা করা যায়।

চাপ পরীক্ষার কিছু রেফারেন্স সীমা

ক্লাউড সার্ভার 4 কোর 4G 16 প্রক্রিয়া স্থানীয়/অভ্যন্তরীণ চাপ পরীক্ষা

- keep-alive সক্রিয় keep-alive নিষ্ক্রিয়
হ্যালো ওয়ার্ল্ড ৮-১৬万QPS ১-৩万QPS
ডেটাবেস একক অনুসন্ধান ১-২万QPS ১万QPS

তৃতীয় পক্ষের techempower চাপ পরীক্ষার তথ্য

চাপ পরীক্ষার কমান্ড উদাহরণ

ab

# 100000 অনুরোধ 200 সঙ্গত keep-alive সক্রিয়
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 অনুরোধ 200 সঙ্গত keep-alive নিষ্ক্রিয়
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# 200 সঙ্গতে 10 সেকেন্ড চাপ পরীক্ষা keep-alive সক্রিয় (ডিফল্ট)
wrk -c 200 -d 10s http://example.com