WEB সার্ভারের যুদ্ধ। পার্ট 1 – HTTP স্পর্শের বাইরে:

এই নিবন্ধে আমরা বিপরীত প্রকৌশলে আমাদের হাত চেষ্টা করব, কেউ বলতে পারে। আমরা প্রতিটি ওয়েব সার্ভারের হুডের নিচে আমাদের নোংরা হাত পাব, তাদের এমনভাবে শোষণ করব যা কেউ কখনও শোষণ করবে না।

এই পরীক্ষাটি একটি ভ্যাকুয়ামে একটি গোলাকার ঘোড়ার পরিমাপ, প্রাপ্ত ডেটা ছাড়া আর কিছুই নয়, এবং এখন আমরা জানি না এটি দিয়ে কী করতে হবে।

প্রযুক্তি

Nginx এবং Apache-এর জন্য অপারেটিং সিস্টেম হল Ubuntu ১৮.০৪ এলটিএস, আইআইএস-এর জন্য Windows Server কোর ২০১৯। পরীক্ষার আগে, ৪ ডিসেম্বর, ২০১৯ তারিখের সর্বশেষ আপডেট অনুযায়ী সমস্ত অপারেটিং সিস্টেম আপডেট করা হয়েছে।

পরীক্ষাগুলো একচেটিয়াভাবে HTTP-র মাধ্যমে করা হয়েছিল। প্রতিটি ওয়েব সার্ভার একই পৃষ্ঠা চালাত, Codrops থেকে একটি বিনামূল্যে Jekyll টেমপ্লেট। লিংক. প্রতিটি ওয়েব সার্ভারে জিজিপ কম্প্রেশন অক্ষম ছিল।

থ্রুপুট পরীক্ষাটি আর্গুমেন্ট সহ Httpd-টুল দিয়ে করা হয়েছিল:

ab -n 50000 -c 500 http://192.168.76.204:80/

সার্ভারগুলি 10, 5 এবং একটি কোরের 1, 8, এবং 4 শতাংশের মধ্যে সীমাবদ্ধ ছিল৷ পরীক্ষার বেঞ্চটি ছিল 9900K@5400MHz সহ একটি কম্পিউটার, যার মানে হল যে 10% সীমা প্রাপ্ত সার্ভার প্রতি কোরে প্রায় 540MHz গ্রহণ করে।

TTFB পরীক্ষাটি করা হয়েছিল যখন সার্ভারটি প্রথম বুট করা হয়েছিল এবং ফলাফল পাওয়ার পরে, সার্ভারটি বন্ধ করে দেওয়া হয়েছিল এবং যেকোনো ধরনের ক্যাশের উপস্থিতি বাদ দিতে পূর্ববর্তী চেকপয়েন্টে ফিরিয়ে আনা হয়েছিল।

পরীক্ষক এবং ওয়েব সার্ভার একই হোস্টে এবং একই ভার্চুয়াল সুইচে ছিল।

ডিস্ক সাবসিস্টেমকে অবিলম্বে মূল্যায়ন করতে, ATTO এবং CrystalDIskMark বেঞ্চমার্কের ফলাফলগুলি যাতে বাধাগুলি সম্পর্কে ধারণা থাকে।

ভার্চুয়াল মেশিন থেকে নেওয়া ডেটা:

ফলাফল:

TTFB:

IIS-এর গড় TTFB হল সবচেয়ে ছোট, 0,5ms, বনাম Apache-এর জন্য 1,4ms এবং Nginx-এর জন্য 4ms।

থ্রুপুট:

প্রথমে, আসুন দেখি প্রতিটি সার্ভার কোরের সংখ্যার উপর ভিত্তি করে কতটা ভালোভাবে স্কেল করে।

গ্রাফটি ওয়েব সার্ভারে পরীক্ষকের কলের সংখ্যা এবং লেটেন্সি দেখায়। গ্রাফটি দেখায় যে NGINX সমস্ত অনুরোধের 98% প্রক্রিয়া করেছে, 20ms বা তার কম সময়ে সাইটটি সরবরাহ করেছে৷ IIS, Apache এর মতো, সব কলের শেষ 5% যথাক্রমে 76ms এবং 14ms-এ সম্পন্ন করেছে।

গ্রাফটি একটি চাপ পরীক্ষার সময় একটি অনুরোধের জন্য গড় প্রক্রিয়াকরণ সময় দেখায়।

আপনি গ্রাফ থেকে দেখতে পাচ্ছেন, IIS Apache এবং Nginx উভয়কেই উড়িয়ে দিয়েছে, উচ্চ লোডের অধীনে উল্লেখযোগ্যভাবে ধীর হয়ে গেছে। 

IIS স্পষ্টতই 4 এর চেয়ে XNUMXটি কোর পছন্দ করেছে, XNUMX তে কম বিলম্ব দেখায়, কিন্তু একটি কোরকে দৃঢ়ভাবে সমর্থন করেনি।

NGINX সমস্ত 8টি কোর জুড়ে ভাল স্কেল করে, এবং Apache-এর জন্য, একক-কোর দৃশ্যকল্পটি সেরা পছন্দ বলে মনে হয়।

পরিমাপযোগ্যতা:

nginx:

এখন আসুন ফ্রিকোয়েন্সি এবং কোরের সংখ্যার পরিপ্রেক্ষিতে স্কেলেবিলিটি দেখি। 

Nginx 1 এবং 4 কোরের জন্য 1% সীমা সহ পরীক্ষা পাস করেনি যখন এটি 2000 অনুরোধ অতিক্রম করে, এটি পরীক্ষকের সাথে সংযোগ বন্ধ করে দেয়।

এ্যাপাচি:

Apache, Nginx এর মত, 2500 টি অনুরোধ প্রসেস করে, সংযোগ ছেড়ে দেয় এবং বন্ধ করে দেয়। অ্যাপাচি 8, 4 এবং 1 কোরে 1% সীমা সহ পরীক্ষায় ব্যর্থ হয়েছিল, তবে এর পাশাপাশি এটি একটি কোরে 5% সীমা সহ পরীক্ষায় ব্যর্থ হয়েছিল, যা Nginx এর চেয়েও খারাপ।

আইআইএস:

পরীক্ষার সময়, IIS অনুরোধের একটি বিশাল সারি জমা করেছিল কিন্তু সেগুলির প্রতিটিকে প্রক্রিয়া করেছিল। দৃশ্যত, বাক্সের বাইরে অনুরোধ প্রক্রিয়াকরণের জন্য কোন সময়সীমা সেট করা নেই।

চার্টটি পরীক্ষাটি সম্পূর্ণ করতে কত সময় নিয়েছে তা দেখায়। সম্পূর্ণ অযৌক্তিক পরীক্ষার কনফিগারেশন বাতিল করা হয়েছে। চিত্রটি দেখায় যে হার্ডওয়্যারের ক্ষেত্রে আইআইএস কতটা চাহিদাপূর্ণ এবং এনজিআইএনএক্স কতটা চমৎকার।

ডিস্ক থেকে পরিমাপযোগ্যতা:

nginx:

এখন আসুন ফ্রিকোয়েন্সি এবং কোরের সংখ্যা এবং ডিস্কের গতির পরিপ্রেক্ষিতে স্কেলেবিলিটি দেখি। 

এবার Nginx দুটির পরিবর্তে 4টি পরীক্ষায় ব্যর্থ হয়েছে।

এ্যাপাচি:

অ্যাপাচি গতবারের মতো একই সংখ্যক পরীক্ষায় ব্যর্থ হয়েছে।

আইআইএস:

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

এই পরীক্ষার উপর ভিত্তি করে সিদ্ধান্ত নেওয়া খুব তাড়াতাড়ি; আমরা পরবর্তী নিবন্ধে এই সম্পর্কে কথা বলতে হবে.

উত্স: www.habr.com