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 દર્શાવે છે. અપાચે અને 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 બંને સામે હારનું સંચાલન કરે છે.

આલેખની તમામ વક્રતા આયર્ન-આચ્છાદિત પુનઃઉત્પાદિત છે.

અમુક પ્રકારના નિષ્કર્ષ:

હા, અપાચે 1 અને 8 કોરો પર ખરાબ કામ કરે છે, પરંતુ 4 પર થોડું સારું કામ કરે છે.

હા, 8 કોરો પર Nginx 1 અને 4 કોરો પર એક પછી એક વધુ સારી રીતે વિનંતી કરે છે અને જ્યારે ઘણા કનેક્શન હોય ત્યારે વધુ ખરાબ કામ કરે છે.

હા, IIS બહુ-થ્રેડેડ વર્કલોડ માટે 4 કોરો પસંદ કરે છે અને સિંગલ-થ્રેડેડ વર્કલોડ માટે 8 કોરો પસંદ કરે છે. આખરે, IIS ઊંચા લોડ હેઠળ 8 કોરો પર બીજા બધા કરતા સહેજ ઝડપી હતું, જો કે બધા સર્વર્સ સમાન હતા.

આ કોઈ માપન ભૂલ નથી, અહીં ભૂલ +-1ms કરતાં વધુ નથી. વિલંબમાં અને RPR માટે પ્રતિ સેકન્ડ +- 2-3 વિનંતીઓ કરતાં વધુ નહીં.

પરિણામો જ્યાં 8 કોરો ખરાબ પ્રદર્શન કરે છે તે આશ્ચર્યજનક નથી, ઘણા કોરો અને એસએમટી/હાયપરથ્રેડીંગ પ્રભાવને મોટા પ્રમાણમાં બગાડે છે જો આપણી પાસે સમયમર્યાદા હોય જેમાં આપણે આખી પાઇપલાઇન પૂર્ણ કરવાની હોય.

સોર્સ: www.habr.com