SRE: ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ਲੇਸ਼ਣ। ਗੋ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਵੈੱਬ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੈੱਟਅੱਪ ਵਿਧੀ

ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਟਿਊਨਿੰਗ ਗਾਹਕਾਂ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਪਾਲਣਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਾਧਨ ਹੈ।

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

ਗੋ ਇੱਥੇ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਵਧੀਆ ਹੈ ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਪ੍ਰੋਫਾਈਲਿੰਗ ਟੂਲ ਹਨ pprof ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ.

ਰਣਨੀਤੀ

ਆਉ ਸਾਡੇ ਢਾਂਚਾਗਤ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਇੱਕ ਸੰਖੇਪ ਸੂਚੀ ਬਣਾਈਏ। ਅਸੀਂ ਅਨੁਭਵ ਜਾਂ ਅਨੁਮਾਨ ਦੇ ਆਧਾਰ 'ਤੇ ਬਦਲਾਅ ਕਰਨ ਦੀ ਬਜਾਏ ਫੈਸਲੇ ਲੈਣ ਲਈ ਕੁਝ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗੇ। ਅਜਿਹਾ ਕਰਨ ਲਈ ਅਸੀਂ ਇਹ ਕਰਾਂਗੇ:

• ਅਸੀਂ ਅਨੁਕੂਲਤਾ ਦੀਆਂ ਹੱਦਾਂ (ਲੋੜਾਂ) ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ;
• ਅਸੀਂ ਸਿਸਟਮ ਲਈ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੋਡ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ;
• ਅਸੀਂ ਟੈਸਟ ਕਰਦੇ ਹਾਂ (ਡੇਟਾ ਬਣਾਓ);
• ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ;
• ਅਸੀਂ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਹਾਂ - ਕੀ ਸਾਰੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ?
• ਅਸੀਂ ਇਸਨੂੰ ਵਿਗਿਆਨਕ ਤੌਰ 'ਤੇ ਸਥਾਪਤ ਕਰਦੇ ਹਾਂ, ਇੱਕ ਪਰਿਕਲਪਨਾ ਬਣਾਉਂਦੇ ਹਾਂ;
• ਅਸੀਂ ਇਸ ਧਾਰਨਾ ਨੂੰ ਪਰਖਣ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗ ਕਰਦੇ ਹਾਂ।

ਸਧਾਰਨ HTTP ਸਰਵਰ ਆਰਕੀਟੈਕਚਰ

ਇਸ ਲੇਖ ਲਈ ਅਸੀਂ ਗੋਲੰਗ ਵਿੱਚ ਇੱਕ ਛੋਟੇ HTTP ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ. ਇਸ ਲੇਖ ਤੋਂ ਸਾਰੇ ਕੋਡ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ ਇੱਥੇ.

ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜਾ ਰਿਹਾ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ HTTP ਸਰਵਰ ਹੈ ਜੋ ਹਰੇਕ ਬੇਨਤੀ ਲਈ Postgresql ਨੂੰ ਪੋਲ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਸਿਸਟਮ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਇਕੱਤਰ ਕਰਨ ਅਤੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਪ੍ਰੋਮੀਥੀਅਸ, ਨੋਡ_ਐਕਸਪੋਰਟਰ ਅਤੇ ਗ੍ਰਾਫਾਨਾ ਹੈ।

ਸਰਲ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਮੰਨਦੇ ਹਾਂ ਕਿ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ (ਅਤੇ ਗਣਨਾਵਾਂ ਨੂੰ ਸਰਲ ਬਣਾਉਣ) ਲਈ ਹਰੇਕ ਸੇਵਾ ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਇਕੱਠੇ ਤੈਨਾਤ ਕੀਤਾ ਗਿਆ ਹੈ:

ਟੀਚਿਆਂ ਦੀ ਪਰਿਭਾਸ਼ਾ

ਇਸ ਪੜਾਅ 'ਤੇ, ਅਸੀਂ ਟੀਚਾ ਤੈਅ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਕੀ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ? ਅਸੀਂ ਕਿਵੇਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਇਹ ਕਦੋਂ ਖਤਮ ਹੋਣ ਦਾ ਸਮਾਂ ਹੈ? ਇਸ ਲੇਖ ਵਿੱਚ, ਅਸੀਂ ਕਲਪਨਾ ਕਰਾਂਗੇ ਕਿ ਸਾਡੇ ਕੋਲ ਗਾਹਕ ਹਨ ਅਤੇ ਸਾਡੀ ਸੇਵਾ ਪ੍ਰਤੀ ਸਕਿੰਟ 10 ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰੇਗੀ।

В ਗੂਗਲ ਐਸਆਰਈ ਬੁੱਕ ਚੋਣ ਅਤੇ ਮਾਡਲਿੰਗ ਦੇ ਤਰੀਕਿਆਂ ਬਾਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ। ਚਲੋ ਉਹੀ ਕਰੀਏ ਅਤੇ ਮਾਡਲ ਬਣਾਉ:

• ਲੇਟੈਂਸੀ: 99% ਬੇਨਤੀਆਂ 60ms ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਪੂਰੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ;
• ਲਾਗਤ: ਸੇਵਾ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਪੈਸੇ ਦੀ ਖਪਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਅਸੀਂ ਸੋਚਦੇ ਹਾਂ ਕਿ ਇਹ ਮੁਨਾਸਬ ਤੌਰ 'ਤੇ ਸੰਭਵ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਥ੍ਰੁਪੁੱਟ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰਦੇ ਹਾਂ;
• ਸਮਰੱਥਾ ਦੀ ਯੋਜਨਾਬੰਦੀ: ਸਮੁੱਚੀ ਸਕੇਲਿੰਗ ਕਾਰਜਕੁਸ਼ਲਤਾ ਸਮੇਤ, ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਕਿੰਨੀਆਂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਲੋਡ ਅਤੇ ਵਿਵਸਥਾ ਦੀਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਕਿੰਨੀਆਂ ਉਦਾਹਰਣਾਂ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ, ਇਸ ਨੂੰ ਸਮਝਣ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਰਿਡੰਡੈਂਸੀ n+1.

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

ਇੱਕ ਟੈਸਟ ਵਾਤਾਵਰਣ ਸਥਾਪਤ ਕਰਨਾ

ਇੱਕ ਟੈਸਟ ਵਾਤਾਵਰਨ ਦੀ ਮਦਦ ਨਾਲ, ਅਸੀਂ ਆਪਣੇ ਸਿਸਟਮ 'ਤੇ ਇੱਕ ਮਾਪਿਆ ਲੋਡ ਰੱਖਣ ਦੇ ਯੋਗ ਹੋਵਾਂਗੇ। ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ, ਵੈੱਬ ਸੇਵਾ ਦੇ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਡੇਟਾ ਤਿਆਰ ਕੀਤਾ ਜਾਵੇਗਾ।

ਲੈਣ-ਦੇਣ ਦਾ ਲੋਡ

ਇਹ ਵਾਤਾਵਰਣ ਵਰਤਦਾ ਹੈ ਸਬਜ਼ੀਆਂ ਬੰਦ ਹੋਣ ਤੱਕ ਇੱਕ ਕਸਟਮ HTTP ਬੇਨਤੀ ਦਰ ਬਣਾਉਣ ਲਈ:

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

ਨਿਰੀਖਣ

ਰਨਟਾਈਮ 'ਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਲੋਡ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ। ਐਪਲੀਕੇਸ਼ਨ (ਬੇਨਤੀਆਂ ਦੀ ਸੰਖਿਆ, ਜਵਾਬ ਲੇਟੈਂਸੀ) ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ (ਮੈਮੋਰੀ, CPU, IOPS) ਮੈਟ੍ਰਿਕਸ ਤੋਂ ਇਲਾਵਾ, ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਫਾਈਲਿੰਗ ਨੂੰ ਇਹ ਸਮਝਣ ਲਈ ਚਲਾਇਆ ਜਾਵੇਗਾ ਕਿ ਇਸ ਵਿੱਚ ਕਿੱਥੇ ਸਮੱਸਿਆਵਾਂ ਹਨ ਅਤੇ CPU ਸਮਾਂ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ।

ਪਰੋਫਾਈਲਿੰਗ

ਪ੍ਰੋਫਾਈਲਿੰਗ ਮਾਪ ਦੀ ਇੱਕ ਕਿਸਮ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇਹ ਦੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਕਿ ਜਦੋਂ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਚੱਲ ਰਹੀ ਹੈ ਤਾਂ CPU ਸਮਾਂ ਕਿੱਥੇ ਜਾ ਰਿਹਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਕਿ ਪ੍ਰੋਸੈਸਰ ਦਾ ਸਮਾਂ ਕਿੱਥੇ ਅਤੇ ਕਿੰਨਾ ਖਰਚਿਆ ਜਾਂਦਾ ਹੈ:

ਇਸ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਵਿਅਰਥ CPU ਸਮੇਂ ਅਤੇ ਕੀਤੇ ਜਾ ਰਹੇ ਬੇਲੋੜੇ ਕੰਮ ਦੀ ਸਮਝ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵਿਸ਼ਲੇਸ਼ਣ ਦੌਰਾਨ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। Go (pprof) ਪਰੋਫਾਈਲ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਟੂਲਸ ਦੇ ਇੱਕ ਮਿਆਰੀ ਸੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਹਨਾਂ ਨੂੰ ਫਲੇਮ ਗ੍ਰਾਫ ਦੇ ਰੂਪ ਵਿੱਚ ਕਲਪਨਾ ਕਰ ਸਕਦਾ ਹੈ। ਮੈਂ ਲੇਖ ਵਿੱਚ ਬਾਅਦ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਅਤੇ ਸੈੱਟਅੱਪ ਗਾਈਡ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ।

ਐਗਜ਼ੀਕਿਊਸ਼ਨ, ਨਿਰੀਖਣ, ਵਿਸ਼ਲੇਸ਼ਣ.

ਆਓ ਇੱਕ ਪ੍ਰਯੋਗ ਕਰੀਏ। ਅਸੀਂ ਪ੍ਰਦਰਸ਼ਨ, ਨਿਰੀਖਣ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਉਦੋਂ ਤੱਕ ਕਰਾਂਗੇ ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਪ੍ਰਦਰਸ਼ਨ ਤੋਂ ਸੰਤੁਸ਼ਟ ਨਹੀਂ ਹੋ ਜਾਂਦੇ। ਆਉ ਅਸੀਂ ਪਹਿਲੇ ਨਿਰੀਖਣਾਂ ਦੇ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਇੱਕ ਮਨਮਰਜ਼ੀ ਨਾਲ ਘੱਟ ਲੋਡ ਮੁੱਲ ਦੀ ਚੋਣ ਕਰੀਏ। ਹਰ ਅਗਲੇ ਪੜਾਅ 'ਤੇ ਅਸੀਂ ਕੁਝ ਪਰਿਵਰਤਨ ਦੇ ਨਾਲ ਚੁਣੇ ਹੋਏ ਇੱਕ ਖਾਸ ਸਕੇਲਿੰਗ ਫੈਕਟਰ ਨਾਲ ਲੋਡ ਨੂੰ ਵਧਾਵਾਂਗੇ। ਹਰੇਕ ਲੋਡ ਟੈਸਟਿੰਗ ਰਨ ਐਡਜਸਟ ਕੀਤੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਸੰਖਿਆ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ: make load-test LOAD_TEST_RATE=X.

ਪ੍ਰਤੀ ਸਕਿੰਟ 50 ਬੇਨਤੀਆਂ

ਚੋਟੀ ਦੇ ਦੋ ਗ੍ਰਾਫਾਂ ਵੱਲ ਧਿਆਨ ਦਿਓ। ਉੱਪਰੀ ਖੱਬਾ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਤੀ ਸਕਿੰਟ 50 ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੀ ਹੈ (ਇਹ ਸੋਚਦਾ ਹੈ) ਅਤੇ ਉੱਪਰ ਸੱਜੇ ਪਾਸੇ ਹਰੇਕ ਬੇਨਤੀ ਦੀ ਮਿਆਦ ਦਿਖਾਉਂਦਾ ਹੈ। ਦੋਵੇਂ ਮਾਪਦੰਡ ਇਹ ਦੇਖਣ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕਰਦੇ ਹਨ ਕਿ ਕੀ ਅਸੀਂ ਆਪਣੀਆਂ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਹਾਂ ਜਾਂ ਨਹੀਂ। ਗ੍ਰਾਫ 'ਤੇ ਲਾਲ ਲਾਈਨ HTTP ਬੇਨਤੀ ਲੇਟੈਂਸੀ 60ms 'ਤੇ SLO ਦਿਖਾਉਂਦਾ ਹੈ। ਲਾਈਨ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਅਸੀਂ ਆਪਣੇ ਵੱਧ ਤੋਂ ਵੱਧ ਜਵਾਬ ਸਮੇਂ ਤੋਂ ਹੇਠਾਂ ਹਾਂ।

ਆਉ ਲਾਗਤ ਪੱਖ ਨੂੰ ਵੇਖੀਏ:

10000 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ / 50 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਰਵਰ = 200 ਸਰਵਰ + 1

ਅਸੀਂ ਅਜੇ ਵੀ ਇਸ ਅੰਕੜੇ ਨੂੰ ਸੁਧਾਰ ਸਕਦੇ ਹਾਂ।

ਪ੍ਰਤੀ ਸਕਿੰਟ 500 ਬੇਨਤੀਆਂ

ਹੋਰ ਦਿਲਚਸਪ ਚੀਜ਼ਾਂ ਹੋਣੀਆਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਲੋਡ ਪ੍ਰਤੀ ਸਕਿੰਟ 500 ਬੇਨਤੀਆਂ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ:

ਦੁਬਾਰਾ, ਉੱਪਰਲੇ ਖੱਬੇ ਗ੍ਰਾਫ ਵਿੱਚ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਆਮ ਲੋਡ ਨੂੰ ਰਿਕਾਰਡ ਕਰ ਰਹੀ ਹੈ। ਜੇਕਰ ਅਜਿਹਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਸਰਵਰ 'ਤੇ ਸਮੱਸਿਆ ਹੈ ਜਿਸ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਚੱਲ ਰਹੀ ਹੈ। ਜਵਾਬ ਲੇਟੈਂਸੀ ਗ੍ਰਾਫ ਉੱਪਰ ਸੱਜੇ ਪਾਸੇ ਸਥਿਤ ਹੈ, ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਪ੍ਰਤੀ ਸਕਿੰਟ 500 ਬੇਨਤੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ 25-40ms ਦੀ ਦੇਰੀ ਹੋਈ ਹੈ। 99ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ ਅਜੇ ਵੀ ਉੱਪਰ ਚੁਣੇ ਗਏ 60ms SLO ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਬੈਠਦਾ ਹੈ।

ਲਾਗਤ ਦੇ ਰੂਪ ਵਿੱਚ:

10000 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ / 500 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਰਵਰ = 20 ਸਰਵਰ + 1

ਸਭ ਕੁਝ ਅਜੇ ਵੀ ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਪ੍ਰਤੀ ਸਕਿੰਟ 1000 ਬੇਨਤੀਆਂ

ਸ਼ਾਨਦਾਰ ਲਾਂਚ! ਐਪਲੀਕੇਸ਼ਨ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਇਸਨੇ ਪ੍ਰਤੀ ਸਕਿੰਟ 1000 ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ, ਪਰ SLO ਦੁਆਰਾ ਲੇਟੈਂਸੀ ਸੀਮਾ ਦੀ ਉਲੰਘਣਾ ਕੀਤੀ ਗਈ ਸੀ। ਇਹ ਉੱਪਰਲੇ ਸੱਜੇ ਗ੍ਰਾਫ ਵਿੱਚ ਲਾਈਨ p99 ਵਿੱਚ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ p100 ਲਾਈਨ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ, ਅਸਲ ਦੇਰੀ ਵੱਧ ਤੋਂ ਵੱਧ 60ms ਤੋਂ ਵੱਧ ਹੈ। ਆਓ ਇਹ ਪਤਾ ਕਰਨ ਲਈ ਪ੍ਰੋਫਾਈਲਿੰਗ ਵਿੱਚ ਡੁਬਕੀ ਕਰੀਏ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੀ ਹੈ।

ਪਰੋਫਾਈਲਿੰਗ

ਪ੍ਰੋਫਾਈਲਿੰਗ ਲਈ, ਅਸੀਂ ਲੋਡ ਨੂੰ 1000 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ 'ਤੇ ਸੈੱਟ ਕਰਦੇ ਹਾਂ, ਫਿਰ ਵਰਤੋਂ pprof ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਡੇਟਾ ਕੈਪਚਰ ਕਰਨ ਲਈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ CPU ਸਮਾਂ ਕਿੱਥੇ ਖਰਚ ਕਰ ਰਹੀ ਹੈ। ਇਹ HTTP ਅੰਤਮ ਬਿੰਦੂ ਨੂੰ ਸਰਗਰਮ ਕਰਕੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ pprof, ਅਤੇ ਫਿਰ, ਲੋਡ ਦੇ ਅਧੀਨ, ਕਰਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਤੀਜਿਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ:

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

ਨਤੀਜੇ ਇਸ ਤਰ੍ਹਾਂ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ:

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

ਗ੍ਰਾਫ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕਿੱਥੇ ਅਤੇ ਕਿੰਨਾ CPU ਸਮਾਂ ਬਿਤਾਉਂਦੀ ਹੈ। ਤੋਂ ਵਰਣਨ ਤੋਂ ਬ੍ਰੈਂਡਨ ਗ੍ਰੇਗ:

X ਧੁਰਾ ਸਟੈਕ ਪ੍ਰੋਫਾਈਲ ਦੀ ਆਬਾਦੀ ਹੈ, ਵਰਣਮਾਲਾ ਅਨੁਸਾਰ ਕ੍ਰਮਬੱਧ (ਇਹ ਸਮਾਂ ਨਹੀਂ ਹੈ), Y ਧੁਰਾ ਸਟੈਕ ਦੀ ਡੂੰਘਾਈ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, [ਟੌਪ] 'ਤੇ ਜ਼ੀਰੋ ਤੋਂ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ। ਹਰ ਆਇਤਕਾਰ ਇੱਕ ਸਟੈਕ ਫਰੇਮ ਹੈ। ਫਰੇਮ ਜਿੰਨਾ ਚੌੜਾ ਹੁੰਦਾ ਹੈ, ਓਨਾ ਹੀ ਅਕਸਰ ਇਹ ਸਟੈਕ ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ। ਸਿਖਰ 'ਤੇ ਕੀ ਹੈ CPU 'ਤੇ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਹੇਠਾਂ ਕੀ ਹੈ ਉਹ ਚਾਈਲਡ ਐਲੀਮੈਂਟਸ ਹਨ। ਰੰਗਾਂ ਦਾ ਆਮ ਤੌਰ 'ਤੇ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਫਰੇਮਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰਨ ਲਈ ਬੇਤਰਤੀਬ ਢੰਗ ਨਾਲ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ।

ਵਿਸ਼ਲੇਸ਼ਣ - ਅਨੁਮਾਨ

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

ਬ੍ਰੈਂਡਨ ਗ੍ਰੇਗ ਦੀਆਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਚਾਰਟ ਨੂੰ ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਤੱਕ ਪੜ੍ਹਾਂਗੇ। ਹਰ ਲਾਈਨ ਇੱਕ ਸਟੈਕ ਫਰੇਮ (ਫੰਕਸ਼ਨ ਕਾਲ) ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੀ ਹੈ। ਪਹਿਲੀ ਲਾਈਨ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਹੈ, ਹੋਰ ਸਾਰੀਆਂ ਕਾਲਾਂ ਦਾ ਮੂਲ (ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਹੋਰ ਸਾਰੀਆਂ ਕਾਲਾਂ ਦੇ ਸਟੈਕ ਵਿੱਚ ਇਹ ਹੋਵੇਗਾ)। ਅਗਲੀ ਲਾਈਨ ਪਹਿਲਾਂ ਹੀ ਵੱਖਰੀ ਹੈ:

ਜੇਕਰ ਤੁਸੀਂ ਗ੍ਰਾਫ 'ਤੇ ਕਿਸੇ ਫੰਕਸ਼ਨ ਦੇ ਨਾਮ 'ਤੇ ਕਰਸਰ ਨੂੰ ਹੋਵਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਡੀਬੱਗਿੰਗ ਦੌਰਾਨ ਸਟੈਕ 'ਤੇ ਰਹਿਣ ਦਾ ਕੁੱਲ ਸਮਾਂ ਦਿਖਾਇਆ ਜਾਵੇਗਾ। HTTPServe ਫੰਕਸ਼ਨ ਉੱਥੇ 65% ਸਮਾਂ ਸੀ, ਹੋਰ ਰਨਟਾਈਮ ਫੰਕਸ਼ਨ runtime.mcall, mstart и gc, ਬਾਕੀ ਸਮਾਂ ਲਿਆ। ਮਜ਼ੇਦਾਰ ਤੱਥ: ਕੁੱਲ ਸਮੇਂ ਦਾ 5% DNS ਸਵਾਲਾਂ 'ਤੇ ਖਰਚਿਆ ਜਾਂਦਾ ਹੈ:

ਪਤੇ ਜੋ ਪ੍ਰੋਗਰਾਮ ਲੱਭਦਾ ਹੈ Postgresql ਨਾਲ ਸਬੰਧਤ ਹੈ। 'ਤੇ ਕਲਿੱਕ ਕਰੋ FindByAge:

ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ, ਪ੍ਰੋਗਰਾਮ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ, ਸਿਧਾਂਤ ਵਿੱਚ, ਤਿੰਨ ਮੁੱਖ ਸਰੋਤ ਹਨ ਜੋ ਦੇਰੀ ਜੋੜਦੇ ਹਨ: ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣਾ ਅਤੇ ਬੰਦ ਕਰਨਾ, ਡੇਟਾ ਦੀ ਬੇਨਤੀ ਕਰਨਾ, ਅਤੇ ਡੇਟਾਬੇਸ ਨਾਲ ਜੁੜਨਾ। ਗ੍ਰਾਫ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ DNS ਬੇਨਤੀਆਂ, ਖੁੱਲਣ ਅਤੇ ਬੰਦ ਕਰਨ ਵਾਲੇ ਕੁਨੈਕਸ਼ਨ ਕੁੱਲ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮੇਂ ਦਾ ਲਗਭਗ 13% ਲੈਂਦੇ ਹਨ।

ਕਲਪਨਾ: ਪੂਲਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨ ਨਾਲ ਇੱਕ ਸਿੰਗਲ HTTP ਬੇਨਤੀ ਦੇ ਸਮੇਂ ਨੂੰ ਘਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਉੱਚ ਥ੍ਰਰੂਪੁਟ ਅਤੇ ਘੱਟ ਲੇਟੈਂਸੀ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ.

ਐਪਲੀਕੇਸ਼ਨ ਸੈਟ ਅਪ ਕਰਨਾ - ਪ੍ਰਯੋਗ

ਅਸੀਂ ਸਰੋਤ ਕੋਡ ਨੂੰ ਅਪਡੇਟ ਕਰਦੇ ਹਾਂ, ਹਰੇਕ ਬੇਨਤੀ ਲਈ Postgresql ਨਾਲ ਕਨੈਕਸ਼ਨ ਨੂੰ ਹਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਪਹਿਲਾ ਵਿਕਲਪ ਵਰਤਣਾ ਹੈ ਕੁਨੈਕਸ਼ਨ ਪੂਲ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ 'ਤੇ. ਇਸ ਪ੍ਰਯੋਗ ਵਿੱਚ ਅਸੀਂ ਚਲੋ ਇਸਨੂੰ ਸੈਟ ਅਪ ਕਰੀਏ ਗੋ ਲਈ sql ਡਰਾਈਵਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ:

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

ਐਗਜ਼ੀਕਿਊਸ਼ਨ, ਨਿਰੀਖਣ, ਵਿਸ਼ਲੇਸ਼ਣ

ਪ੍ਰਤੀ ਸਕਿੰਟ 1000 ਬੇਨਤੀਆਂ ਦੇ ਨਾਲ ਟੈਸਟ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ p99 ਦੇ ਲੇਟੈਂਸੀ ਪੱਧਰ 60ms ਦੇ SLO ਨਾਲ ਆਮ ਵਾਂਗ ਵਾਪਸ ਆ ਗਏ ਹਨ!

ਲਾਗਤ ਕੀ ਹੈ?

10000 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ / 1000 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਰਵਰ = 10 ਸਰਵਰ + 1

ਚਲੋ ਇਸਨੂੰ ਹੋਰ ਵੀ ਵਧੀਆ ਕਰੀਏ!

ਪ੍ਰਤੀ ਸਕਿੰਟ 2000 ਬੇਨਤੀਆਂ

ਲੋਡ ਨੂੰ ਦੁੱਗਣਾ ਕਰਨਾ ਇੱਕੋ ਚੀਜ਼ ਦਿਖਾਉਂਦਾ ਹੈ, ਉੱਪਰ ਖੱਬੇ ਗ੍ਰਾਫ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਤੀ ਸਕਿੰਟ 2000 ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦੀ ਹੈ, p100 60ms ਤੋਂ ਘੱਟ ਹੈ, p99 SLO ਨੂੰ ਸੰਤੁਸ਼ਟ ਕਰਦਾ ਹੈ।

ਲਾਗਤ ਦੇ ਰੂਪ ਵਿੱਚ:

10000 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ / 2000 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਰਵਰ = 5 ਸਰਵਰ + 1

ਪ੍ਰਤੀ ਸਕਿੰਟ 3000 ਬੇਨਤੀਆਂ

ਇੱਥੇ ਐਪਲੀਕੇਸ਼ਨ 3000ms ਤੋਂ ਘੱਟ ਦੀ p99 ਲੇਟੈਂਸੀ ਨਾਲ 60 ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦੀ ਹੈ। SLO ਦੀ ਉਲੰਘਣਾ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ, ਅਤੇ ਲਾਗਤ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਸਵੀਕਾਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

10000 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ / ਪ੍ਰਤੀ ਸਰਵਰ ਪ੍ਰਤੀ 3000 ਬੇਨਤੀਆਂ = 4 ਸਰਵਰ + 1 (ਲੇਖਕ ਨੇ ਰਾਊਂਡਅੱਪ ਕੀਤਾ ਹੈ, ਲਗਭਗ ਅਨੁਵਾਦਕ)

ਆਉ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਇੱਕ ਹੋਰ ਦੌਰ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ.

ਵਿਸ਼ਲੇਸ਼ਣ - ਅਨੁਮਾਨ

ਅਸੀਂ 3000 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਦੇ ਨਤੀਜੇ ਇਕੱਠੇ ਕਰਦੇ ਅਤੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਹਾਂ:

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

ਕਲਪਨਾ: ਕਨੈਕਸ਼ਨ, ਪੂਲ ਦੀ ਮੌਜੂਦਗੀ ਦੇ ਬਾਵਜੂਦ, ਅਜੇ ਵੀ ਛੱਡੇ ਗਏ ਹਨ ਅਤੇ ਸਾਫ਼ ਕੀਤੇ ਗਏ ਹਨ, ਇਸਲਈ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਰੀਸੈਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪੂਲ ਦੇ ਆਕਾਰ 'ਤੇ ਬਕਾਇਆ ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਸੈੱਟ ਕਰਨ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਕੁਨੈਕਸ਼ਨ ਬਣਾਉਣ ਦੇ ਸਮੇਂ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਕੇ ਲੇਟੈਂਸੀ ਵਿੱਚ ਮਦਦ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।.

ਐਪਲੀਕੇਸ਼ਨ ਸੈਟ ਅਪ ਕਰਨਾ - ਪ੍ਰਯੋਗ

ਸਥਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ MaxIdleConns ਪੂਲ ਦੇ ਆਕਾਰ ਦੇ ਬਰਾਬਰ (ਇਹ ਵੀ ਦੱਸਿਆ ਗਿਆ ਹੈ ਇੱਥੇ):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

ਐਗਜ਼ੀਕਿਊਸ਼ਨ, ਨਿਰੀਖਣ, ਵਿਸ਼ਲੇਸ਼ਣ

ਪ੍ਰਤੀ ਸਕਿੰਟ 3000 ਬੇਨਤੀਆਂ

p99 ਕਾਫ਼ੀ ਘੱਟ p60 ਦੇ ਨਾਲ 100ms ਤੋਂ ਘੱਟ ਹੈ!

ਫਲੇਮ ਗ੍ਰਾਫ ਦੀ ਜਾਂਚ ਕਰਨਾ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੁਨੈਕਸ਼ਨ ਹੁਣ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਹੈ! ਦੇ ਹੋਰ ਵੇਰਵੇ ਵਿੱਚ ਚੈੱਕ ਕਰੀਏ pg(*conn).query - ਅਸੀਂ ਇੱਥੇ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਹੋਣ ਬਾਰੇ ਵੀ ਧਿਆਨ ਨਹੀਂ ਦਿੰਦੇ ਹਾਂ।

ਸਿੱਟਾ

ਕਾਰਗੁਜ਼ਾਰੀ ਵਿਸ਼ਲੇਸ਼ਣ ਇਹ ਸਮਝਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਗਾਹਕ ਦੀਆਂ ਉਮੀਦਾਂ ਅਤੇ ਗੈਰ-ਕਾਰਜਸ਼ੀਲ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ। ਗਾਹਕ ਦੀਆਂ ਉਮੀਦਾਂ ਨਾਲ ਨਿਰੀਖਣਾਂ ਦੀ ਤੁਲਨਾ ਕਰਕੇ ਵਿਸ਼ਲੇਸ਼ਣ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਸਵੀਕਾਰਯੋਗ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ। Go ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਬਣੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਟੂਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਸਰਲ ਅਤੇ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।

ਸਰੋਤ: www.habr.com