ਵੈਬ ਸਰਵਰਾਂ ਦੀ ਲੜਾਈ। ਭਾਗ 1 - HTTP ਸੰਪਰਕ ਤੋਂ ਬਾਹਰ:

ਇਸ ਲੇਖ ਵਿਚ ਅਸੀਂ ਰਿਵਰਸ ਇੰਜੀਨੀਅਰਿੰਗ 'ਤੇ ਆਪਣਾ ਹੱਥ ਅਜ਼ਮਾਵਾਂਗੇ, ਕੋਈ ਕਹਿ ਸਕਦਾ ਹੈ. ਅਸੀਂ ਹਰੇਕ ਵੈਬ ਸਰਵਰ ਦੇ ਹੁੱਡ ਦੇ ਹੇਠਾਂ ਆਪਣੇ ਗੰਦੇ ਹੱਥਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਾਂਗੇ, ਉਹਨਾਂ ਦਾ ਅਜਿਹੇ ਤਰੀਕਿਆਂ ਨਾਲ ਸ਼ੋਸ਼ਣ ਕਰਾਂਗੇ ਜਿਸਦਾ ਕੋਈ ਵੀ ਸ਼ੋਸ਼ਣ ਨਹੀਂ ਕਰੇਗਾ।

ਇਹ ਟੈਸਟ ਵੈਕਿਊਮ ਵਿੱਚ ਇੱਕ ਗੋਲਾਕਾਰ ਘੋੜੇ ਦਾ ਇੱਕ ਮਾਪ ਹੈ, ਜੋ ਕਿ ਡੇਟਾ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ ਹੈ, ਅਤੇ ਹੁਣ ਸਾਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਸ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ।

ਵਿਧੀ

Nginx ਅਤੇ Apache ਲਈ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ IIS Windows Server Core 18.04 ਲਈ Ubuntu 2019 LTS ਹੈ। ਟੈਸਟਾਂ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਰੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਨੂੰ 04.12.2019 ਦਸੰਬਰ, XNUMX ਤੱਕ ਨਵੀਨਤਮ ਅੱਪਡੇਟ ਪ੍ਰਾਪਤ ਹੋਏ ਸਨ।

ਟੈਸਟ ਸਿਰਫ਼ HTTP 'ਤੇ ਹੀ ਕੀਤੇ ਗਏ ਸਨ। ਹਰੇਕ ਵੈਬ ਸਰਵਰ ਇੱਕੋ ਪੰਨੇ ਨੂੰ ਚਲਾਉਂਦਾ ਸੀ, ਕੋਡਰੌਪਸ ਤੋਂ ਇੱਕ ਮੁਫਤ ਜੇਕੈਲ ਟੈਂਪਲੇਟ। ਲਿੰਕ ਨੂੰ. ਹਰੇਕ ਵੈੱਬ ਸਰਵਰ 'ਤੇ gzip ਕੰਪਰੈਸ਼ਨ ਅਸਮਰੱਥ ਸੀ।

ਥ੍ਰੋਪੁੱਟ ਟੈਸਟ Httpd-ਟੂਲਜ਼ ਨਾਲ ਆਰਗੂਮੈਂਟਾਂ ਨਾਲ ਕੀਤਾ ਗਿਆ ਸੀ:

ab -n 50000 -c 500 http://192.168.76.204:80/

ਸਰਵਰ 10, 5, ਅਤੇ ਇੱਕ ਕੋਰ 'ਤੇ ਕੋਰ ਦੇ 1, 8, ਅਤੇ 4 ਪ੍ਰਤੀਸ਼ਤ ਤੱਕ ਸੀਮਿਤ ਸਨ। ਟੈਸਟ ਬੈਂਚ 9900K@5400MHz ਵਾਲਾ ਇੱਕ ਕੰਪਿਊਟਰ ਸੀ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ 10% ਸੀਮਾ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਸਰਵਰ ਨੂੰ ਪ੍ਰਤੀ ਕੋਰ ਲਗਭਗ 540MHz ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ।

TTFB ਟੈਸਟ ਉਦੋਂ ਕੀਤਾ ਗਿਆ ਸੀ ਜਦੋਂ ਸਰਵਰ ਨੂੰ ਪਹਿਲੀ ਵਾਰ ਬੂਟ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ DevTools ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮਾਪਿਆ ਗਿਆ ਸੀ; ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਰਵਰ ਨੂੰ ਬੰਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ ਅਤੇ ਕਿਸੇ ਵੀ ਕਿਸਮ ਦੇ ਕੈਚਾਂ ਦੀ ਦਿੱਖ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ ਪਿਛਲੀ ਚੈਕਪੁਆਇੰਟ 'ਤੇ ਵਾਪਸ ਰੋਲ ਕੀਤਾ ਗਿਆ ਸੀ।

ਟੈਸਟਰ ਅਤੇ ਵੈਬ ਸਰਵਰ ਇੱਕੋ ਹੋਸਟ ਅਤੇ ਇੱਕੋ ਵਰਚੁਅਲ ਸਵਿੱਚ 'ਤੇ ਸਨ।

ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਦਾ ਤੁਰੰਤ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ, ਰੁਕਾਵਟਾਂ ਦਾ ਵਿਚਾਰ ਕਰਨ ਲਈ ATTO ਅਤੇ CrystalDIskMark ਬੈਂਚਮਾਰਕ ਦੇ ਨਤੀਜੇ।

ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਤੋਂ ਲਿਆ ਡੇਟਾ:

ਨਤੀਜੇ:

TTFB:

IIS ਲਈ ਔਸਤ TTFB ਸਭ ਤੋਂ ਛੋਟਾ ਹੈ, 0,5ms, ਬਨਾਮ ਅਪਾਚੇ ਲਈ 1,4ms ਅਤੇ Nginx ਲਈ 4ms।

ਥਰੋਪੁਟ:

ਪਹਿਲਾਂ, ਆਓ ਦੇਖੀਏ ਕਿ ਹਰੇਕ ਸਰਵਰ ਕੋਰ ਦੀ ਸੰਖਿਆ ਦੇ ਅਧਾਰ ਤੇ ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਕੇਲ ਕਰਦਾ ਹੈ।

ਗ੍ਰਾਫ ਵੈੱਬ ਸਰਵਰ ਅਤੇ ਲੇਟੈਂਸੀ ਨੂੰ ਟੈਸਟਰ ਕਾਲਾਂ ਦੀ ਸੰਖਿਆ ਦਿਖਾਉਂਦਾ ਹੈ। ਗ੍ਰਾਫ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ NGINX ਨੇ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਦੇ 98% ਨੂੰ ਸੰਸਾਧਿਤ ਕੀਤਾ, ਸਾਈਟ ਨੂੰ 20ms ਜਾਂ ਘੱਟ ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤਾ। IIS, ਅਪਾਚੇ ਵਾਂਗ, ਸਾਰੀਆਂ ਕਾਲਾਂ ਦੇ ਆਖਰੀ 5% ਨੂੰ ਕ੍ਰਮਵਾਰ 76ms ਅਤੇ 14ms ਵਿੱਚ ਪੂਰਾ ਕੀਤਾ।

ਗ੍ਰਾਫ ਤਣਾਅ ਦੇ ਟੈਸਟ ਦੌਰਾਨ ਇੱਕ ਬੇਨਤੀ ਲਈ ਔਸਤ ਪ੍ਰੋਸੈਸਿੰਗ ਸਮਾਂ ਦਿਖਾਉਂਦਾ ਹੈ।

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਗ੍ਰਾਫਾਂ ਤੋਂ ਦੇਖ ਸਕਦੇ ਹੋ, IIS ਨੇ ਅਪਾਚੇ ਅਤੇ Nginx ਦੋਵਾਂ ਨੂੰ ਉਡਾ ਦਿੱਤਾ, ਉੱਚ ਲੋਡ ਦੇ ਹੇਠਾਂ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਹੌਲੀ ਹੋ ਗਿਆ. 

IIS ਨੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ 4 ਤੋਂ ਵੱਧ XNUMX ਕੋਰਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ, XNUMX 'ਤੇ ਘੱਟ ਲੇਟੈਂਸੀ ਦਿਖਾਉਂਦੇ ਹੋਏ, ਪਰ ਇੱਕ ਕੋਰ ਦਾ ਵੀ ਜ਼ੋਰਦਾਰ ਸਮਰਥਨ ਨਹੀਂ ਕੀਤਾ।

NGINX ਸਾਰੇ 8 ਕੋਰਾਂ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਕੇਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਪਾਚੇ ਲਈ, ਸਿੰਗਲ-ਕੋਰ ਦ੍ਰਿਸ਼ ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਜਾਪਦਾ ਹੈ।

ਸਕੇਲੇਬਿਲਟੀ:

ਐਨਜਿਨੈਕਸ:

ਹੁਣ ਆਉ ਫ੍ਰੀਕੁਐਂਸੀ ਅਤੇ ਕੋਰਾਂ ਦੀ ਸੰਖਿਆ ਦੇ ਰੂਪ ਵਿੱਚ ਸਕੇਲੇਬਿਲਟੀ ਨੂੰ ਵੇਖੀਏ। 

Nginx ਨੇ 1 ਅਤੇ 4 ਕੋਰ ਲਈ 1% ਦੀ ਸੀਮਾ ਦੇ ਨਾਲ ਟੈਸਟ ਪਾਸ ਨਹੀਂ ਕੀਤੇ; ਜਦੋਂ ਇਹ 2000 ਬੇਨਤੀਆਂ ਤੋਂ ਵੱਧ ਗਿਆ, ਤਾਂ ਇਸਨੇ ਟੈਸਟਰ ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਖਤਮ ਕਰ ਦਿੱਤਾ।

ਅਪਾਚੇ:

ਅਪਾਚੇ, ਜਿਵੇਂ ਕਿ Nginx, ਨੇ 2500 ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਕੇ, ਕੁਨੈਕਸ਼ਨ ਛੱਡ ਦਿੱਤਾ ਅਤੇ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਅਪਾਚੇ 8% ਦੀ ਸੀਮਾ ਦੇ ਨਾਲ 4, 1 ਅਤੇ 1 ਕੋਰ 'ਤੇ ਟੈਸਟ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ, ਪਰ ਇਸ ਤੋਂ ਇਲਾਵਾ ਇਹ ਇੱਕ ਕੋਰ 'ਤੇ 5% ਸੀਮਾ ਦੇ ਨਾਲ ਟੈਸਟ ਵਿੱਚ ਵੀ ਅਸਫਲ ਰਿਹਾ, ਜੋ ਕਿ Nginx ਨਾਲੋਂ ਵੀ ਮਾੜਾ ਹੈ।

ਆਈਆਈਐਸ:

ਟੈਸਟਾਂ ਦੇ ਦੌਰਾਨ, IIS ਨੇ ਬੇਨਤੀਆਂ ਦੀ ਇੱਕ ਵਿਸ਼ਾਲ ਕਤਾਰ ਇਕੱਠੀ ਕੀਤੀ ਪਰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ। ਜ਼ਾਹਰ ਤੌਰ 'ਤੇ, ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਕੋਈ ਸਮਾਂ ਸਮਾਪਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਚਾਰਟ ਟੈਸਟ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਲੱਗਿਆ ਸਮਾਂ ਦਿਖਾਉਂਦਾ ਹੈ। ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਤੁਕੇ ਟੈਸਟਿੰਗ ਕੌਂਫਿਗਰੇਸ਼ਨਾਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ। ਚਿੱਤਰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਜਦੋਂ ਹਾਰਡਵੇਅਰ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ ਤਾਂ IIS ਦੀ ਕਿੰਨੀ ਮੰਗ ਹੁੰਦੀ ਹੈ, ਅਤੇ NGINX ਕਿੰਨਾ ਸ਼ਾਨਦਾਰ ਹੈ।

ਡਿਸਕ ਤੋਂ ਸਕੇਲੇਬਿਲਟੀ:

ਐਨਜਿਨੈਕਸ:

ਆਉ ਹੁਣ ਬਾਰੰਬਾਰਤਾ ਅਤੇ ਕੋਰਾਂ ਦੀ ਸੰਖਿਆ ਅਤੇ ਡਿਸਕ ਦੀ ਗਤੀ ਦੇ ਰੂਪ ਵਿੱਚ ਸਕੇਲੇਬਿਲਟੀ ਨੂੰ ਵੇਖੀਏ। 

ਇਸ ਵਾਰ Nginx ਦੋ ਦੀ ਬਜਾਏ 4 ਟੈਸਟਾਂ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ।

ਅਪਾਚੇ:

ਅਪਾਚੇ ਪਿਛਲੀ ਵਾਰ ਦੇ ਬਰਾਬਰ ਟੈਸਟਾਂ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ।

ਆਈਆਈਐਸ:

IIS ਲਗਭਗ ਇੱਕੋ ਜਿਹਾ ਗ੍ਰਾਫ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਕੋਈ ਡਿਸਕ ਪਾਬੰਦੀਆਂ ਨਹੀਂ ਸਨ। ਆਮ ਤੌਰ 'ਤੇ, ਸਾਰੇ ਸਰਵਰਾਂ ਦੇ ਗ੍ਰਾਫਿਕਸ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ ਬਦਲੇ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੇ RAM ਵਿੱਚ ਸਥਿਰ ਡੇਟਾ ਨੂੰ ਕੈਸ਼ ਕੀਤਾ ਅਤੇ ਇਸ ਨੂੰ ਉੱਥੋਂ ਸੇਵਾ ਦਿੱਤੀ। ਇੱਥੇ ਅਸੀਂ ਮੁੱਖ ਰੁਕਾਵਟ ਦੇਖਦੇ ਹਾਂ - ਵੈੱਬ ਸਰਵਰ ਆਪਣੇ ਆਪ ਵਿੱਚ।

ਇਸ ਟੈਸਟਿੰਗ ਦੇ ਆਧਾਰ 'ਤੇ ਸਿੱਟਾ ਕੱਢਣਾ ਬਹੁਤ ਜਲਦੀ ਹੈ; ਅਸੀਂ ਹਾਲੇ ਤੱਕ ਲੈਟਸ ਐਨਕ੍ਰਿਪਟ ਤੋਂ ਲਾਈਵ ਸਰਟੀਫਿਕੇਟ ਦੇ ਨਾਲ HTTPS, ਕੰਪਰੈਸ਼ਨ ਅਤੇ HTTP/2 ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਹੈ। ਅਸੀਂ ਅਗਲੇ ਲੇਖ ਵਿਚ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ।

ਸਰੋਤ: www.habr.com