WEB সার্ভারের যুদ্ধ। পার্ট 2 – বাস্তবসম্মত HTTPS দৃশ্যকল্প:

আমরা পদ্ধতি সম্পর্কে কথা বলেছি প্রথম অংশ নিবন্ধ, এই এক আমরা HTTPS পরীক্ষা, কিন্তু আরো বাস্তবসম্মত পরিস্থিতিতে. পরীক্ষার জন্য, আমরা একটি Let's Encrypt সার্টিফিকেট পেয়েছি এবং Brotli কম্প্রেশন 11 এ সক্ষম করেছি।

এইবার আমরা একটি VDS-এ সার্ভার স্থাপনের দৃশ্যকল্প বা একটি আদর্শ প্রসেসর সহ হোস্টে একটি ভার্চুয়াল মেশিন হিসাবে পুনরুত্পাদন করার চেষ্টা করব৷ এই উদ্দেশ্যে, একটি সীমা নির্ধারণ করা হয়েছিল:

• 25% - যা ~ 1350 MHz এর কম্পাঙ্কের সমতুল্য
• 35% -1890MHz
• 41% - 2214 MHz
• 65% - 3510 MHz

এককালীন সংযোগের সংখ্যা 500 থেকে কমিয়ে 1, 3, 5, 7 এবং 9 করা হয়েছে,

ফলাফল:

বিলম্ব:

TTFB বিশেষভাবে একটি পৃথক পরীক্ষা হিসাবে অন্তর্ভুক্ত করা হয়েছিল, কারণ HTTPD টুল প্রতিটি পৃথক অনুরোধের জন্য একটি নতুন ব্যবহারকারী তৈরি করে। এই পরীক্ষাটি এখনও বাস্তবতা থেকে বেশ বিচ্ছিন্ন, কারণ ব্যবহারকারী এখনও কয়েকটি পৃষ্ঠায় ক্লিক করবে এবং বাস্তবে TTFP প্রধান ভূমিকা পালন করবে।

প্রথম, সাধারণত IIS ভার্চুয়াল মেশিনের প্রথম স্টার্টের পর প্রথম অনুরোধটি গড়ে 120 ms লাগে।

পরবর্তী সমস্ত অনুরোধ 1.5 ms এর TTFP দেখায়। Apache এবং Nginx এক্ষেত্রে পিছিয়ে রয়েছে। ব্যক্তিগতভাবে, লেখক এই পরীক্ষাটিকে সবচেয়ে প্রকাশক বলে মনে করেন এবং শুধুমাত্র এর উপর ভিত্তি করে বিজয়ী নির্বাচন করবেন।
ফলাফলটি আশ্চর্যজনক নয় যেহেতু IIS ক্যাশে ইতিমধ্যেই স্থির বিষয়বস্তু সংকুচিত করে এবং প্রতিবার এটি অ্যাক্সেস করার সময় এটি সংকুচিত করে না।

ক্লায়েন্ট প্রতি ব্যয় করা সময়

কর্মক্ষমতা মূল্যায়ন করার জন্য, 1টি একক সংযোগ সহ একটি পরীক্ষা যথেষ্ট।
উদাহরণস্বরূপ, IIS 5000 সেকেন্ডে 40 ব্যবহারকারীর একটি পরীক্ষা সম্পন্ন করেছে, যা প্রতি সেকেন্ডে 123টি অনুরোধ।

নীচের গ্রাফগুলি সাইটের বিষয়বস্তু সম্পূর্ণরূপে স্থানান্তর না হওয়া পর্যন্ত সময় দেখায়৷ এটি একটি নির্দিষ্ট সময়ে সম্পন্ন করা অনুরোধের অনুপাত। আমাদের ক্ষেত্রে, সমস্ত অনুরোধের 80% IIS-এ 8ms এবং Apache এবং Nginx-এ 4.5ms-এ প্রক্রিয়া করা হয়েছিল এবং Apache এবং Nginx-এ সমস্ত অনুরোধের 8% 98 মিলিসেকেন্ড পর্যন্ত ব্যবধানে সম্পন্ন হয়েছিল।

যে সময় 5000 অনুরোধ প্রক্রিয়া করা হয়েছিল:

যে সময় 5000 অনুরোধ প্রক্রিয়া করা হয়েছিল:

আপনার যদি 3.5GHz CPU এবং 8 কোর সহ একটি ভার্চুয়াল মেশিন থাকে, তাহলে আপনি যা চান তা বেছে নিন। সমস্ত ওয়েব সার্ভার এই পরীক্ষায় খুব অনুরূপ। আমরা নীচে প্রতিটি হোস্টের জন্য কোন ওয়েব সার্ভার বেছে নেব সে সম্পর্কে আলোচনা করব৷

যখন এটি একটি সামান্য আরো বাস্তবসম্মত পরিস্থিতি আসে, সমস্ত ওয়েব সার্ভার মাথার দিকে যায়।

থ্রুপুট:

একযোগে সংযোগের সংখ্যা বনাম বিলম্বের গ্রাফ। মসৃণ এবং নিম্ন ভাল. শেষ 2% চার্ট থেকে সরানো হয়েছে কারণ তারা তাদের অপঠনযোগ্য করে তুলবে।

এখন এর বিকল্পটি বিবেচনা করা যাক যেখানে সার্ভারটি ভার্চুয়াল হোস্টিংয়ে হোস্ট করা হয়। 4 GHz এ 2.2টি কোর এবং 1.8 GHz এ একটি কোর নেওয়া যাক।

কিভাবে স্কেল

আপনি যদি কখনও দেখে থাকেন যে ভ্যাকুয়াম ট্রায়োড, পেন্টোড এবং আরও অনেক কিছুর কারেন্ট-ভোল্টেজের বৈশিষ্ট্যগুলি কেমন দেখতে, এই গ্রাফগুলি আপনার কাছে পরিচিত হবে। এটিই আমরা ধরার চেষ্টা করছি - স্যাচুরেশন। সীমা হল যখন আপনি কতগুলি কোর নিক্ষেপ করুন না কেন, কর্মক্ষমতা বৃদ্ধি লক্ষণীয় হবে না।

পূর্বে, সমগ্র চ্যালেঞ্জ ছিল সমস্ত অনুরোধের জন্য সর্বনিম্ন লেটেন্সি সহ 98% অনুরোধ প্রক্রিয়া করা, বক্ররেখা যতটা সম্ভব সমতল রাখা। এখন, অন্য একটি বক্ররেখা তৈরি করে, আমরা প্রতিটি সার্ভারের জন্য সর্বোত্তম অপারেটিং পয়েন্ট খুঁজে পাব।

এটি করার জন্য, প্রতি সেকেন্ডে অনুরোধ (RPR) সূচকটি নেওয়া যাক। অনুভূমিক হল ফ্রিকোয়েন্সি, উল্লম্ব হল প্রতি সেকেন্ডে প্রসেস করা অনুরোধের সংখ্যা, লাইন হল কোরের সংখ্যা।

Nginx একের পর এক অনুরোধ কতটা ভালোভাবে প্রক্রিয়া করে তার একটি সম্পর্ক দেখায়। 8টি কোর এই পরীক্ষায় ভাল পারফর্ম করে।

এই গ্রাফটি স্পষ্টভাবে দেখায় যে Nginx একটি একক কোরে কতটা ভাল (বেশি নয়) কাজ করে। আপনার যদি Nginx থাকে, আপনি যদি শুধুমাত্র স্ট্যাটিক হোস্টিং করেন তবে আপনার কোরের সংখ্যা কমিয়ে একটিতে বিবেচনা করা উচিত।

IIS, যদিও Chrome-এর DevTools অনুসারে এটির সর্বনিম্ন TTFB রয়েছে, অ্যাপাচি ফাউন্ডেশনের স্ট্রেস টেস্টের সাথে একটি গুরুতর লড়াইয়ে Nginx এবং Apache উভয়ের কাছেই হেরেছে।

গ্রাফের সমস্ত বক্রতা লোহা দিয়ে পুনরুত্পাদিত হয়।

কিছু ধরনের উপসংহার:

হ্যাঁ, Apache 1 এবং 8 কোরে খারাপ কাজ করে, কিন্তু 4 তে একটু ভালো কাজ করে।

হ্যাঁ, 8 কোরে Nginx 1 এবং 4 কোরে একের পর এক আরও ভাল অনুরোধ করে এবং অনেকগুলি সংযোগ থাকলে আরও খারাপ কাজ করে।

হ্যাঁ, IIS মাল্টি-থ্রেডেড ওয়ার্কলোডের জন্য 4 কোর পছন্দ করে এবং একক-থ্রেডেড ওয়ার্কলোডের জন্য 8 কোর পছন্দ করে। শেষ পর্যন্ত, IIS উচ্চ লোডের অধীনে 8 কোরে অন্য সবার চেয়ে কিছুটা দ্রুত ছিল, যদিও সমস্ত সার্ভার সমান ছিল।

এটি একটি পরিমাপ ত্রুটি নয়, এখানে ত্রুটি +-1ms এর বেশি নয়৷ বিলম্বে এবং RPR-এর জন্য প্রতি সেকেন্ডে +- 2-3টির বেশি অনুরোধ নয়।

ফলাফল যেখানে 8টি কোর খারাপ কাজ করে তা মোটেও আশ্চর্যজনক নয়, অনেক কোর এবং এসএমটি/হাইপারথ্রেডিং কার্যক্ষমতাকে ব্যাপকভাবে হ্রাস করে যদি আমাদের একটি সময়সীমা থাকে যেখানে আমাদের সম্পূর্ণ পাইপলাইনটি সম্পূর্ণ করতে হবে।

উত্স: www.habr.com