ਵੈਬ ਸਰਵਰਾਂ ਦੀ ਲੜਾਈ। ਭਾਗ 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 ਕੋਰ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ। ਆਖਰਕਾਰ, ਉੱਚ ਲੋਡ ਦੇ ਅਧੀਨ 8 ਕੋਰਾਂ 'ਤੇ ਆਈਆਈਐਸ ਹਰ ਕਿਸੇ ਨਾਲੋਂ ਥੋੜ੍ਹਾ ਤੇਜ਼ ਸੀ, ਹਾਲਾਂਕਿ ਸਾਰੇ ਸਰਵਰ ਬਰਾਬਰ ਸਨ.

ਇਹ ਕੋਈ ਮਾਪ ਗਲਤੀ ਨਹੀਂ ਹੈ, ਇੱਥੇ ਗਲਤੀ +-1ms ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੈ। ਦੇਰੀ ਵਿੱਚ ਅਤੇ RPR ਲਈ ਪ੍ਰਤੀ ਸਕਿੰਟ +- 2-3 ਬੇਨਤੀਆਂ ਤੋਂ ਵੱਧ ਨਹੀਂ।

ਨਤੀਜੇ ਜਿੱਥੇ 8 ਕੋਰ ਮਾੜੇ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਨ ਉਹ ਬਿਲਕੁਲ ਵੀ ਹੈਰਾਨੀਜਨਕ ਨਹੀਂ ਹਨ, ਬਹੁਤ ਸਾਰੇ ਕੋਰ ਅਤੇ SMT/ਹਾਈਪਰਥ੍ਰੈਡਿੰਗ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਹੁਤ ਘਟਾਉਂਦੇ ਹਨ ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਇੱਕ ਸਮਾਂ ਸੀਮਾ ਹੈ ਜਿਸ ਵਿੱਚ ਸਾਨੂੰ ਪੂਰੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਪੂਰਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਸਰੋਤ: www.habr.com