உள்ள வழிமுறை பற்றி பேசினோம் கட்டுரை, இதில் நாங்கள் HTTPS ஐ சோதிக்கிறோம், ஆனால் மிகவும் யதார்த்தமான காட்சிகளில். சோதனைக்காக, லெட்ஸ் என்க்ரிப்ட் சான்றிதழைப் பெற்று, ப்ரோட்லி சுருக்கத்தை 11க்கு இயக்கினோம்.
இந்த நேரத்தில், VDS இல் சேவையகத்தை அல்லது ஒரு நிலையான செயலியுடன் ஒரு மெய்நிகர் கணினியில் பயன்படுத்துவதற்கான காட்சியை மீண்டும் உருவாக்க முயற்சிப்போம். இந்த நோக்கத்திற்காக, வரம்பு நிர்ணயிக்கப்பட்டது:
- 25% - இது ~ 1350 மெகா ஹெர்ட்ஸ் அலைவரிசைக்கு சமம்
- 35% -1890MHz
- 41% - 2214 மெகா ஹெர்ட்ஸ்
- 65% - 3510 மெகா ஹெர்ட்ஸ்
ஒரு முறை இணைப்புகளின் எண்ணிக்கை 500ல் இருந்து 1, 3, 5, 7 மற்றும் 9 ஆக குறைக்கப்பட்டுள்ளது.
முடிவு:
தாமதங்கள்:
TTFB குறிப்பாக ஒரு தனி சோதனையாக சேர்க்கப்பட்டுள்ளது, ஏனெனில் HTTPD கருவிகள் ஒவ்வொரு தனிப்பட்ட கோரிக்கைக்கும் ஒரு புதிய பயனரை உருவாக்குகிறது. இந்த சோதனை இன்னும் யதார்த்தத்திலிருந்து முற்றிலும் பிரிக்கப்பட்டுள்ளது, ஏனெனில் பயனர் இன்னும் ஓரிரு பக்கங்களைக் கிளிக் செய்வார், உண்மையில் TTFP முக்கிய பங்கு வகிக்கும்.
ஐஐஎஸ் மெய்நிகர் இயந்திரத்தின் முதல் தொடக்கத்திற்குப் பிறகு முதல், பொதுவாக முதல் கோரிக்கை சராசரியாக 120 எம்எஸ் எடுக்கும்.
அனைத்து அடுத்தடுத்த கோரிக்கைகளும் 1.5 ms இன் TTFP ஐக் காட்டுகின்றன. இந்த விஷயத்தில் அப்பாச்சி மற்றும் என்ஜின்க்ஸ் பின்தங்கி உள்ளன. தனிப்பட்ட முறையில், ஆசிரியர் இந்த சோதனையை மிகவும் வெளிப்படுத்துவதாகக் கருதுகிறார் மற்றும் அதன் அடிப்படையில் மட்டுமே வெற்றியாளரைத் தேர்ந்தெடுப்பார்.
IIS தற்காலிகச் சேமிப்பில் ஏற்கனவே சுருக்கப்பட்ட நிலையான உள்ளடக்கம் மற்றும் அதை அணுகும் ஒவ்வொரு முறையும் அதை சுருக்காது என்பதால் முடிவு ஆச்சரியப்படுவதற்கில்லை.
ஒரு வாடிக்கையாளருக்கு செலவழித்த நேரம்
செயல்திறனை மதிப்பிட, 1 ஒற்றை இணைப்புடன் ஒரு சோதனை போதுமானது.
எடுத்துக்காட்டாக, ஐஐஎஸ் 5000 பயனர்களின் சோதனையை 40 வினாடிகளில் முடித்தது, அதாவது வினாடிக்கு 123 கோரிக்கைகள்.
கீழேயுள்ள வரைபடங்கள் தளத்தின் உள்ளடக்கம் முழுமையாக மாற்றப்படும் வரையிலான நேரத்தைக் காட்டுகிறது. இது ஒரு குறிப்பிட்ட நேரத்தில் முடிக்கப்பட்ட கோரிக்கைகளின் விகிதமாகும். எங்கள் விஷயத்தில், அனைத்து கோரிக்கைகளிலும் 80% ஐஐஎஸ்ஸில் 8எம்எஸ் மற்றும் அப்பாச்சி மற்றும் என்ஜின்எக்ஸ் ஆகியவற்றில் 4.5எம்எஸ்களில் செயலாக்கப்பட்டன, மேலும் அப்பாச்சி மற்றும் என்ஜின்எக்ஸில் 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 இரண்டையும் இழக்க முடிகிறது.
வரைபடங்களின் அனைத்து வளைவுகளும் இரும்பு உறையுடன் மீண்டும் உருவாக்கப்படுகின்றன.
சில வகையான முடிவு:
ஆம், அப்பாச்சி 1 மற்றும் 8 கோர்களில் மோசமாக வேலை செய்கிறது, ஆனால் 4ல் கொஞ்சம் சிறப்பாக செயல்படுகிறது.
ஆம், 8 கோர்களில் உள்ள Nginx 1 மற்றும் 4 கோர்களில் ஒன்றன் பின் ஒன்றாகச் சிறப்பாகக் கோருகிறது, மேலும் பல இணைப்புகள் இருக்கும்போது மோசமாக வேலை செய்கிறது.
ஆம், மல்டி-த்ரெட் பணிச்சுமைகளுக்கு 4 கோர்களை IIS விரும்புகிறது மற்றும் ஒற்றை-திரிக்கப்பட்ட பணிச்சுமைகளுக்கு 8 கோர்களை விரும்புகிறது. இறுதியில், அனைத்து சேவையகங்களும் சமமாக இருந்தாலும், அதிக சுமையின் கீழ் 8 கோர்களில் எல்லோரையும் விட IIS சற்று வேகமாக இருந்தது.
இது அளவீட்டுப் பிழை அல்ல, இங்குள்ள பிழை +-1msக்கு மேல் இல்லை. தாமதங்கள் மற்றும் RPR க்கான வினாடிக்கு +- 2-3 கோரிக்கைகளுக்கு மேல் இல்லை.
8 கோர்கள் மோசமாகச் செயல்படும் முடிவுகள் ஆச்சரியப்படுவதற்கில்லை, முழு பைப்லைனையும் முடிக்க வேண்டிய காலக்கெடு இருந்தால், பல கோர்கள் மற்றும் SMT/Hyperthreading செயல்திறனை வெகுவாகக் குறைக்கும்.
ஆதாரம்: www.habr.com