ہم نے طریقہ کار کے بارے میں بات کی۔ مضمون، اس میں ہم HTTPS کی جانچ کرتے ہیں، لیکن زیادہ حقیقت پسندانہ منظرناموں میں۔ جانچ کے لیے، ہم نے Let's Encrypt سرٹیفکیٹ حاصل کیا اور Brotli کمپریشن کو 11 پر فعال کیا۔
اس بار ہم VDS پر سرور کی تعیناتی کے منظر نامے کو دوبارہ پیش کرنے کی کوشش کریں گے یا معیاری پروسیسر کے ساتھ میزبان پر ورچوئل مشین کے طور پر۔ اس مقصد کے لیے ایک حد مقرر کی گئی تھی:
- 25% - جو ~ 1350 MHz کی فریکوئنسی کے برابر ہے۔
- 35% -1890MHz
- 41% - 2214 میگاہرٹز
- 65% - 3510 میگاہرٹز
یک وقتی رابطوں کی تعداد 500 سے کم کر کے 1، 3، 5، 7 اور 9 کر دی گئی ہے۔
نتائج:
تاخیر:
TTFB کو خاص طور پر ایک علیحدہ ٹیسٹ کے طور پر شامل کیا گیا تھا، کیونکہ HTTPD ٹولز ہر فرد کی درخواست کے لیے ایک نیا صارف تخلیق کرتا ہے۔ یہ ٹیسٹ ابھی بھی حقیقت سے بالکل الگ ہے، کیونکہ صارف اب بھی چند صفحات پر کلک کرے گا، اور حقیقت میں TTFP مرکزی کردار ادا کرے گا۔
پہلی، عام طور پر پہلی درخواست IIS ورچوئل مشین کے پہلے آغاز کے بعد اوسطاً 120 ایم ایس لیتی ہے۔
تمام بعد کی درخواستیں 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 cores والی ورچوئل مشین ہے، تو آپ جو چاہیں منتخب کریں۔ تمام ویب سرورز اس ٹیسٹنگ میں بہت ملتے جلتے ہیں۔ ہم ذیل میں بات کریں گے کہ ہر میزبان کے لیے کون سا ویب سرور منتخب کرنا ہے۔
جب قدرے زیادہ حقیقت پسندانہ صورتحال کی بات آتی ہے تو، تمام ویب سرورز سر جوڑ کر چلتے ہیں۔
ان پٹ:
تاخیر کا گراف بمقابلہ بیک وقت کنکشنز کی تعداد۔ ہموار اور کم بہتر ہے. آخری 2% کو چارٹ سے ہٹا دیا گیا کیونکہ وہ انہیں پڑھنے کے قابل بنا دیں گے۔
اب آئیے اس آپشن پر غور کریں جہاں ورچوئل ہوسٹنگ پر سرور ہوسٹ کیا جاتا ہے۔ آئیے 4 GHz پر 2.2 کور اور 1.8 GHz پر ایک کور لیں۔
پیمانہ کیسے کریں۔
اگر آپ نے کبھی دیکھا ہے کہ ویکیوم ٹرائیوڈس، پینٹوڈس وغیرہ کی کرنٹ وولٹیج کی خصوصیات کیسی نظر آتی ہیں تو یہ گراف آپ کے لیے واقف ہوں گے۔ یہ وہی ہے جسے ہم پکڑنے کی کوشش کر رہے ہیں - سنترپتی۔ حد اس وقت ہوتی ہے جب اس سے کوئی فرق نہیں پڑتا ہے کہ آپ کتنے کور پھینکتے ہیں، کارکردگی میں اضافہ قابل توجہ نہیں ہوگا۔
اس سے پہلے، پورا چیلنج تمام درخواستوں کے لیے کم ترین تاخیر کے ساتھ 98% درخواستوں پر کارروائی کرنا تھا، وکر کو ہر ممکن حد تک فلیٹ رکھتے ہوئے۔ اب، ایک اور کریو بنا کر، ہم ہر ایک سرور کے لیے بہترین آپریٹنگ پوائنٹ تلاش کریں گے۔
ایسا کرنے کے لیے، آئیے درخواستیں فی سیکنڈ (RPR) اشارے لیں۔ افقی فریکوئنسی ہے، عمودی فی سیکنڈ پر کارروائی کی جانے والی درخواستوں کی تعداد ہے، لائنیں کور کی تعداد ہیں۔
اس بات کا ارتباط دکھاتا ہے کہ Nginx ایک کے بعد ایک درخواستوں پر کتنی اچھی طرح سے عمل کرتا ہے۔ اس ٹیسٹ میں 8 کور بہتر کارکردگی کا مظاہرہ کرتے ہیں۔
یہ گراف واضح طور پر ظاہر کرتا ہے کہ Nginx سنگل کور پر کتنا بہتر (زیادہ نہیں) کام کرتا ہے۔ اگر آپ کے پاس Nginx ہے، تو آپ کو کور کی تعداد کو کم کرنے پر غور کرنا چاہئے اگر آپ صرف جامد کی میزبانی کر رہے ہیں۔
IIS، اگرچہ Chrome میں DevTools کے مطابق اس کے پاس سب سے کم TTFB ہے، اپاچی فاؤنڈیشن کے تناؤ کے ٹیسٹ کے ساتھ ایک سنگین لڑائی میں Nginx اور Apache دونوں سے ہارنے کا انتظام کرتا ہے۔
گراف کے تمام گھماؤ لوہے سے ملبوس دوبارہ تیار کیے گئے ہیں۔
کسی قسم کا نتیجہ:
ہاں، اپاچی 1 اور 8 کور پر بدتر کام کرتا ہے، لیکن 4 پر تھوڑا بہتر کام کرتا ہے۔
ہاں، 8 کور پر Nginx 1 اور 4 cores پر ایک کے بعد ایک بہتر درخواستیں کرتا ہے، اور بہت سے کنکشن ہونے پر بدتر کام کرتا ہے۔
ہاں، IIS ملٹی تھریڈڈ ورک بوجھ کے لیے 4 کور کو ترجیح دیتا ہے اور سنگل تھریڈڈ ورک بوجھ کے لیے 8 کور کو ترجیح دیتا ہے۔ بالآخر، IIS زیادہ بوجھ کے تحت 8 کور پر ہر کسی سے تھوڑا تیز تھا، حالانکہ تمام سرورز برابر تھے۔
یہ پیمائش کی غلطی نہیں ہے، یہاں غلطی +-1ms سے زیادہ نہیں ہے۔ تاخیر میں اور RPR کے لیے +- 2-3 درخواستیں فی سیکنڈ سے زیادہ نہیں۔
نتائج جہاں 8 کور بدتر کارکردگی کا مظاہرہ کرتے ہیں وہ بالکل بھی حیران کن نہیں ہیں، بہت سے کور اور ایس ایم ٹی/ہائپر تھریڈنگ کارکردگی کو بہت زیادہ گرا دیتے ہیں اگر ہمارے پاس ایک ٹائم فریم ہے جس میں ہمیں پوری پائپ لائن کو مکمل کرنا ہے۔
ماخذ: www.habr.com