අපි තාක්ෂණය ගැන කතා කළා ලිපිය, මෙහි අපි HTTPS පරීක්ෂා කරමු, නමුත් වඩාත් යථාර්ථවාදී අවස්ථා වලදී. පරීක්ෂා කිරීම සඳහා, අපි Let's Encrypt සහතිකයක් ලබාගෙන Brotli සම්පීඩනය 11 දක්වා සක්‍රීය කළෙමු.
මෙම අවස්ථාවේදී අපි සේවාදායකයක් VDS මත හෝ වර්චුවල් යන්ත්‍රයක් ලෙස සම්මත ප්‍රොසෙසරයක් සහිත ධාරකයක යෙදවීමේ අවස්ථාව ප්‍රතිනිෂ්පාදනය කිරීමට උත්සාහ කරමු. මෙම කාර්යය සඳහා, සීමාවක් නියම කර ඇත:
- 25% - එය ~ 1350 MHz සංඛ්‍යාතයකට සමාන වේ
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
එක් වරක් සම්බන්ධතා ගණන 500 සිට 1, 3, 5, 7 සහ 9 දක්වා අඩු කර ඇත.
ප්රතිඵල:
ප්‍රමාදයන්:
HTTPD මෙවලම් එක් එක් ඉල්ලීම සඳහා නව පරිශීලකයෙකු නිර්මාණය කරන බැවින්, TTFB වෙනම පරීක්ෂණයක් ලෙස විශේෂයෙන් ඇතුළත් කර ඇත. පරිශීලකයා තවමත් පිටු කිහිපයක් ක්ලික් කරන අතර යථාර්ථයේ දී 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 cores සහිත අතථ්‍ය යන්ත්‍රයක් තිබේ නම්, ඔබට අවශ්‍ය දේ තෝරන්න. මෙම පරීක්ෂණයේදී සියලුම වෙබ් සේවාදායකයන් බොහෝ දුරට සමාන වේ. අපි පහත එක් එක් සත්කාරක සඳහා තෝරාගත යුතු වෙබ් සේවාදායකය ගැන කතා කරමු.
තරමක් යථාර්ථවාදී තත්වයකට පැමිණි විට, සියලුම වෙබ් සේවාදායකයන් හිසට යොමු කරයි.
ප්‍රතිදානය:
ප්‍රමාදයේ ප්‍රස්තාරය සහ සමගාමී සම්බන්ධතා ගණන. සිනිඳු සහ පහළ වඩා හොඳය. අවසාන 2% ප්‍රස්ථාරවලින් ඉවත් කළේ ඒවා කියවීමට නොහැකි වන බැවිනි.
දැන් අපි සේවාදායකය අථත්‍ය සත්කාරකයේ සත්කාරකත්වය සපයන විකල්පය සලකා බලමු. අපි 4 GHz දී core 2.2 ක් සහ 1.8 GHz දී එක් හරයක් ගනිමු.
පරිමාණය කරන්නේ කෙසේද
රික්ත ට්‍රයිඩෝ, පෙන්ටෝඩ සහ යනාදී ධාරා-වෝල්ටීයතා ලක්ෂණ කෙබඳුදැයි ඔබ කවදා හෝ දැක ඇත්නම්, මෙම ප්‍රස්ථාර ඔබට හුරුපුරුදු වනු ඇත. අපි අල්ලා ගැනීමට උත්සාහ කරන්නේ මෙයයි - සංතෘප්තිය. ලිමිට් එක කියන්නේ කොච්චර cores දැම්මත් Performance වැඩි වීම නොපෙනෙන එක.
මින් පෙර, සම්පූර්ණ අභියෝගය වූයේ වක්‍රය හැකිතාක් පැතලි ලෙස තබා ගනිමින්, සියලුම ඉල්ලීම් සඳහා අවම ප්‍රමාදයකින් 98% ඉල්ලීම් සැකසීමයි. දැන්, වෙනත් වක්‍රයක් ගොඩනැගීමෙන්, අපි එක් එක් සේවාදායකය සඳහා ප්‍රශස්ත මෙහෙයුම් ලක්ෂ්‍යය සොයා ගනිමු.
මෙය සිදු කිරීම සඳහා, අපි තත්පරයට ඉල්ලීම් (RPR) දර්ශකය ගනිමු. තිරස් යනු සංඛ්‍යාතය, සිරස් යනු තත්පරයකට සකසන ලද ඉල්ලීම් ගණන, රේඛා යනු හර ගණනයි.
Nginx ඉල්ලීම් එකින් එක සකසන ආකාරය පිළිබඳ සහසම්බන්ධයක් පෙන්වයි. මෙම පරීක්ෂණයේදී හරය 8ක් වඩා හොඳින් ක්‍රියා කරයි.
මෙම ප්‍රස්ථාරය පැහැදිලිව පෙන්නුම් කරන්නේ Nginx තනි හරයක් මත කොපමණ හොඳ (බොහෝ නොවේ) ක්‍රියා කරයිද යන්නයි. ඔබට Nginx තිබේ නම්, ඔබ ස්ථිතික ඒවා පමණක් සත්කාරක කරන්නේ නම්, හර ගණන එකකට අඩු කිරීම සලකා බැලිය යුතුය.
IIS, ක්‍රෝම් හි DevTools අනුව අඩුම TTFB ඇති නමුත්, Apache පදනමේ ආතති පරීක්ෂණය සමඟ බරපතල සටනකදී Nginx සහ Apache යන දෙකටම පරාජය වීමට සමත් වේ.
ප්‍රස්ථාරවල සියලුම වක්‍රය යකඩ ආවරණයකින් ප්‍රතිනිෂ්පාදනය කර ඇත.
යම් ආකාරයක නිගමන:
ඔව්, Apache 1 සහ 8 cores මත නරක ලෙස ක්‍රියා කරයි, නමුත් 4 මත ටිකක් හොඳින් ක්‍රියා කරයි.
ඔව්, Nginx 8 cores ක්‍රියාවලීන් 1 සහ 4 cores මත එකින් එක වඩා හොඳ ලෙස ඉල්ලා සිටින අතර බොහෝ සම්බන්ධතා ඇති විට වඩාත් නරක ලෙස ක්‍රියා කරයි.
ඔව්, IIS බහු-නූල් වැඩ බර සඳහා හරයන් 4කට වැඩි කැමැත්තක් දක්වන අතර තනි නූල් වැඩ බර සඳහා හරයන් 8කට වැඩි කැමැත්තක් දක්වයි. අවසාන වශයෙන්, IIS සියලු සේවාදායකයන් සම මට්ටමක පැවතුනද, ඉහළ බරක් යටතේ මධ්‍ය 8 ක් මත අනෙක් සියල්ලන්ට වඩා තරමක් වේගවත් විය.
මෙය මිනුම් දෝෂයක් නොවේ, මෙහි දෝෂය +-1ms ට වඩා වැඩි නොවේ. ප්‍රමාද වලදී සහ RPR සඳහා තත්පරයකට +- 2-3 ඉල්ලීම් වලට වඩා වැඩි නොවේ.
හරය 8 ක් නරක ලෙස ක්‍රියා කරන ප්රතිඵල කිසිසේත්ම පුදුමයට කරුණක් නොවේ, බොහෝ හරයන් සහ SMT/Hyperthreading අපට සම්පූර්ණ නල මාර්ගයම සම්පූර්ණ කළ යුතු කාල රාමුවක් තිබේ නම් කාර්ය සාධනය බෙහෙවින් පිරිහී යයි.
මූලාශ්රය: www.habr.com