ਜਿਵੇਂ ਕਿ ਜ਼ਿਆਦਾਤਰ ਪੋਸਟਾਂ, ਇੱਕ ਵਿਤਰਿਤ ਸੇਵਾ ਵਿੱਚ ਇੱਕ ਸਮੱਸਿਆ ਹੈ, ਆਓ ਇਸ ਸੇਵਾ ਨੂੰ ਐਲਵਿਨ ਨੂੰ ਕਾਲ ਕਰੀਏ। ਇਸ ਵਾਰ ਮੈਨੂੰ ਸਮੱਸਿਆ ਦਾ ਪਤਾ ਨਹੀਂ ਲੱਗਾ, ਕਲਾਇੰਟ ਸਾਈਡ ਦੇ ਮੁੰਡਿਆਂ ਨੇ ਮੈਨੂੰ ਸੂਚਿਤ ਕੀਤਾ।

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

ਐਲਵਿਨ ਨੂੰ ਟੈਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ 40k ਸਵਾਲ ਪ੍ਰਤੀ ਸਕਿੰਟ (QPS) ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਯੋਗ ਕੀਤੇ, ਸਾਰੇ 10ms ਤੋਂ ਘੱਟ ਦੀ ਲੇਟੈਂਸੀ ਦਿਖਾਉਂਦੇ ਹੋਏ। ਮੈਂ ਇਹ ਐਲਾਨ ਕਰਨ ਲਈ ਤਿਆਰ ਸੀ ਕਿ ਮੈਂ ਉਨ੍ਹਾਂ ਦੇ ਨਤੀਜਿਆਂ ਨਾਲ ਸਹਿਮਤ ਨਹੀਂ ਹਾਂ। ਪਰ ਚਿੱਠੀ 'ਤੇ ਇਕ ਹੋਰ ਨਜ਼ਰ ਮਾਰਦੇ ਹੋਏ, ਮੈਂ ਕੁਝ ਨਵਾਂ ਦੇਖਿਆ: ਮੈਂ ਉਨ੍ਹਾਂ ਸ਼ਰਤਾਂ ਦੀ ਬਿਲਕੁਲ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਸੀ, ਉਨ੍ਹਾਂ ਦਾ QPS ਮੇਰੇ ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਸੀ। ਮੈਂ 40k QPS 'ਤੇ ਟੈਸਟ ਕੀਤਾ, ਪਰ ਉਹ ਸਿਰਫ 1k 'ਤੇ. ਮੈਂ ਇੱਕ ਹੋਰ ਪ੍ਰਯੋਗ ਚਲਾਇਆ, ਇਸ ਵਾਰ ਘੱਟ QPS ਨਾਲ, ਸਿਰਫ਼ ਉਹਨਾਂ ਨੂੰ ਖੁਸ਼ ਕਰਨ ਲਈ।

ਕਿਉਂਕਿ ਮੈਂ ਇਸ ਬਾਰੇ ਬਲੌਗ ਕਰ ਰਿਹਾ ਹਾਂ, ਤੁਸੀਂ ਸ਼ਾਇਦ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਲਗਾ ਲਿਆ ਹੈ ਕਿ ਉਹਨਾਂ ਦੇ ਨੰਬਰ ਸਹੀ ਸਨ. ਮੈਂ ਆਪਣੇ ਵਰਚੁਅਲ ਕਲਾਇੰਟ ਦੀ ਬਾਰ-ਬਾਰ ਜਾਂਚ ਕੀਤੀ, ਉਸੇ ਨਤੀਜੇ ਦੇ ਨਾਲ: ਬੇਨਤੀਆਂ ਦੀ ਘੱਟ ਗਿਣਤੀ ਨਾ ਸਿਰਫ ਲੇਟੈਂਸੀ ਨੂੰ ਵਧਾਉਂਦੀ ਹੈ, ਬਲਕਿ 10 ms ਤੋਂ ਵੱਧ ਦੀ ਲੇਟੈਂਸੀ ਨਾਲ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਵਧਾਉਂਦੀ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਜੇਕਰ 40k QPS 'ਤੇ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ 50 ਬੇਨਤੀਆਂ 50 ms ਤੋਂ ਵੱਧ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ 1k QPS 'ਤੇ ਪ੍ਰਤੀ ਸਕਿੰਟ 100 ms ਤੋਂ ਵੱਧ 50 ਬੇਨਤੀਆਂ ਸਨ। ਵਿਰੋਧਾਭਾਸ!

ਖੋਜ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਨਾ

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

ਇੱਕ ਚੰਗਾ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਮੁਕੰਮਲ ਹੋਏ I/O ਪਰਿਵਰਤਨ (ਨੈੱਟਵਰਕ ਕਾਲਾਂ/ਡਿਸਕ ਲੁੱਕਅੱਪ, ਆਦਿ) ਦੀ ਸੂਚੀ ਹੈ। ਆਉ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਕਿ ਦੇਰੀ ਕਿੱਥੇ ਹੈ. ਕਲਾਇੰਟ ਦੇ ਨਾਲ ਸਪੱਸ਼ਟ I/O ਤੋਂ ਇਲਾਵਾ, ਐਲਵਿਨ ਇੱਕ ਵਾਧੂ ਕਦਮ ਚੁੱਕਦਾ ਹੈ: ਉਹ ਡੇਟਾ ਸਟੋਰ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਸਟੋਰੇਜ ਐਲਵਿਨ ਦੇ ਸਮਾਨ ਕਲੱਸਟਰ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ, ਇਸਲਈ ਉੱਥੇ ਲੇਟੈਂਸੀ ਕਲਾਇੰਟ ਨਾਲੋਂ ਘੱਟ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਲਈ, ਸ਼ੱਕੀ ਦੀ ਸੂਚੀ:

1. ਕਲਾਇੰਟ ਤੋਂ ਐਲਵਿਨ ਨੂੰ ਨੈੱਟਵਰਕ ਕਾਲ।
2. ਐਲਵਿਨ ਤੋਂ ਡਾਟਾ ਸਟੋਰ ਲਈ ਨੈੱਟਵਰਕ ਕਾਲ।
3. ਡਾਟਾ ਸਟੋਰ ਵਿੱਚ ਡਿਸਕ 'ਤੇ ਖੋਜ ਕਰੋ.
4. ਡਾਟਾ ਵੇਅਰਹਾਊਸ ਤੋਂ ਐਲਵਿਨ ਨੂੰ ਨੈੱਟਵਰਕ ਕਾਲ।
5. ਐਲਵਿਨ ਤੋਂ ਇੱਕ ਗਾਹਕ ਨੂੰ ਨੈੱਟਵਰਕ ਕਾਲ।

ਆਓ ਕੁਝ ਨੁਕਤਿਆਂ ਨੂੰ ਪਾਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ।

ਡਾਟਾ ਸਟੋਰੇਜ ਦਾ ਇਸ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਹੈ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਮੈਂ ਕੀਤਾ ਉਹ ਐਲਵਿਨ ਨੂੰ ਇੱਕ ਪਿੰਗ-ਪਿੰਗ ਸਰਵਰ ਵਿੱਚ ਬਦਲਣਾ ਸੀ ਜੋ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਕਰਦਾ. ਜਦੋਂ ਇਹ ਇੱਕ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਖਾਲੀ ਜਵਾਬ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਲੇਟੈਂਸੀ ਘੱਟ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਐਲਵਿਨ ਜਾਂ ਡੇਟਾ ਵੇਅਰਹਾਊਸ ਸਥਾਪਨ ਵਿੱਚ ਇੱਕ ਬੱਗ ਕੁਝ ਵੀ ਅਣਸੁਣਿਆ ਨਹੀਂ ਹੈ। ਪਹਿਲੇ ਪ੍ਰਯੋਗ ਵਿੱਚ ਸਾਨੂੰ ਹੇਠਾਂ ਦਿੱਤਾ ਗ੍ਰਾਫ਼ ਮਿਲਦਾ ਹੈ:

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਪਿੰਗ-ਪਿੰਗ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਕੋਈ ਸੁਧਾਰ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡੇਟਾ ਵੇਅਰਹਾਊਸ ਲੇਟੈਂਸੀ ਨੂੰ ਨਹੀਂ ਵਧਾਉਂਦਾ, ਅਤੇ ਸ਼ੱਕੀਆਂ ਦੀ ਸੂਚੀ ਅੱਧੇ ਵਿੱਚ ਕੱਟ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ:

1. ਕਲਾਇੰਟ ਤੋਂ ਐਲਵਿਨ ਨੂੰ ਨੈੱਟਵਰਕ ਕਾਲ।
2. ਐਲਵਿਨ ਤੋਂ ਇੱਕ ਗਾਹਕ ਨੂੰ ਨੈੱਟਵਰਕ ਕਾਲ।

ਬਹੁਤ ਵਧੀਆ! ਸੂਚੀ ਤੇਜ਼ੀ ਨਾਲ ਸੁੰਗੜ ਰਹੀ ਹੈ। ਮੈਂ ਸੋਚਿਆ ਕਿ ਮੈਂ ਇਸ ਦਾ ਕਾਰਨ ਲਗਭਗ ਸਮਝ ਲਿਆ ਸੀ।

ਜੀਆਰਪੀਸੀ

ਹੁਣ ਤੁਹਾਨੂੰ ਇੱਕ ਨਵੇਂ ਖਿਡਾਰੀ ਨਾਲ ਜਾਣੂ ਕਰਵਾਉਣ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ: ਜੀਆਰਪੀਸੀ. ਇਹ ਪ੍ਰਕਿਰਿਆ-ਅਧੀਨ ਸੰਚਾਰ ਲਈ Google ਦੀ ਇੱਕ ਓਪਨ ਸੋਰਸ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਸੀ.ਪੀ.ਆਰ.... ਹਾਲਾਂਕਿ gRPC ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲਿਤ ਅਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਗਿਆ, ਇਹ ਮੇਰੀ ਪਹਿਲੀ ਵਾਰ ਸੀ ਜਦੋਂ ਇਸ ਆਕਾਰ ਦੇ ਸਿਸਟਮ 'ਤੇ ਇਸਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ ਮੈਨੂੰ ਉਮੀਦ ਸੀ ਕਿ ਮੇਰੇ ਲਾਗੂਕਰਨ ਸਬ-ਅਨੁਕੂਲ ਹੋਣਗੇ - ਘੱਟੋ ਘੱਟ ਕਹਿਣ ਲਈ.

ਉਪਲੱਬਧਤਾ gRPC in stack ਨੇ ਇੱਕ ਨਵੇਂ ਸਵਾਲ ਨੂੰ ਜਨਮ ਦਿੱਤਾ: ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਮੇਰਾ ਲਾਗੂ ਹੋਵੇ ਜਾਂ ਮੈਂ gRPC ਲੇਟੈਂਸੀ ਸਮੱਸਿਆ ਦਾ ਕਾਰਨ ਬਣ ਰਿਹਾ ਹੈ? ਸੂਚੀ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਸ਼ੱਕੀ ਸ਼ਾਮਲ ਕਰਨਾ:

1. ਗਾਹਕ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ gRPC
2. ਲਾਇਬਰੇਰੀ ਨੂੰ gRPC ਗਾਹਕ 'ਤੇ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਇੱਕ ਨੈੱਟਵਰਕ ਕਾਲ ਕਰਦਾ ਹੈ gRPC ਸਰਵਰ 'ਤੇ
3. ਲਾਇਬਰੇਰੀ ਨੂੰ gRPC ਸੰਪਰਕ ਐਲਵਿਨ (ਪਿੰਗ-ਪੌਂਗ ਸਰਵਰ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਕੋਈ ਕਾਰਵਾਈ ਨਹੀਂ)

ਤੁਹਾਨੂੰ ਇਹ ਵਿਚਾਰ ਦੇਣ ਲਈ ਕਿ ਕੋਡ ਕਿਹੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ, ਮੇਰਾ ਕਲਾਇੰਟ/ਐਲਵਿਨ ਲਾਗੂਕਰਨ ਕਲਾਇੰਟ-ਸਰਵਰ ਨਾਲੋਂ ਬਹੁਤ ਵੱਖਰਾ ਨਹੀਂ ਹੈ async ਉਦਾਹਰਨਾਂ.

ਨੋਟ: ਉਪਰੋਕਤ ਸੂਚੀ ਥੋੜੀ ਸਰਲ ਹੈ ਕਿਉਂਕਿ gRPC ਤੁਹਾਡੇ ਆਪਣੇ (ਟੈਂਪਲੇਟ?) ਥ੍ਰੈਡਿੰਗ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਟੈਕ ਆਪਸ ਵਿੱਚ ਜੁੜਿਆ ਹੋਇਆ ਹੈ gRPC ਅਤੇ ਉਪਭੋਗਤਾ ਲਾਗੂ ਕਰਨਾ। ਸਾਦਗੀ ਦੀ ਖ਼ਾਤਰ, ਅਸੀਂ ਇਸ ਮਾਡਲ ਨਾਲ ਜੁੜੇ ਰਹਾਂਗੇ.

ਪ੍ਰੋਫਾਈਲਿੰਗ ਸਭ ਕੁਝ ਠੀਕ ਕਰ ਦੇਵੇਗੀ

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

ਮੈਂ ਚਾਰ ਪ੍ਰੋਫਾਈਲ ਲਏ: ਉੱਚ QPS (ਘੱਟ ਲੇਟੈਂਸੀ) ਦੇ ਨਾਲ ਅਤੇ ਘੱਟ QPS (ਉੱਚ ਲੇਟੈਂਸੀ) ਵਾਲੇ ਪਿੰਗ-ਪੌਂਗ ਸਰਵਰ ਦੇ ਨਾਲ, ਕਲਾਇੰਟ ਸਾਈਡ ਅਤੇ ਸਰਵਰ ਸਾਈਡ ਦੋਵਾਂ 'ਤੇ। ਅਤੇ ਸਿਰਫ ਮਾਮਲੇ ਵਿੱਚ, ਮੈਂ ਇੱਕ ਨਮੂਨਾ ਪ੍ਰੋਸੈਸਰ ਪ੍ਰੋਫਾਈਲ ਵੀ ਲਿਆ. ਪ੍ਰੋਫਾਈਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਸਮੇਂ, ਮੈਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਅਸਧਾਰਨ ਕਾਲ ਸਟੈਕ ਦੀ ਭਾਲ ਕਰਦਾ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਉੱਚ ਲੇਟੈਂਸੀ ਵਾਲੇ ਮਾੜੇ ਪਾਸੇ ਬਹੁਤ ਸਾਰੇ ਹੋਰ ਸੰਦਰਭ ਸਵਿੱਚ ਹਨ (10 ਵਾਰ ਜਾਂ ਵੱਧ)। ਪਰ ਮੇਰੇ ਕੇਸ ਵਿੱਚ, ਸੰਦਰਭ ਸਵਿੱਚਾਂ ਦੀ ਗਿਣਤੀ ਲਗਭਗ ਇੱਕੋ ਜਿਹੀ ਸੀ. ਮੇਰੇ ਡਰ ਲਈ, ਉੱਥੇ ਕੁਝ ਵੀ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਸੀ.

ਵਧੀਕ ਡੀਬੱਗਿੰਗ

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

ਕੀ, ਜੇਕਰ

ਸ਼ੁਰੂ ਤੋਂ ਹੀ, ਮੈਂ ਖਾਸ 50ms ਲੇਟੈਂਸੀ ਬਾਰੇ ਚਿੰਤਤ ਸੀ। ਇਹ ਬਹੁਤ ਵੱਡਾ ਸਮਾਂ ਹੈ। ਮੈਂ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਮੈਂ ਕੋਡ ਦੇ ਟੁਕੜੇ ਕੱਟਾਂਗਾ ਜਦੋਂ ਤੱਕ ਮੈਂ ਇਹ ਪਤਾ ਨਹੀਂ ਲਗਾ ਸਕਦਾ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਇਸ ਗਲਤੀ ਦਾ ਕਾਰਨ ਬਣ ਰਿਹਾ ਸੀ। ਫਿਰ ਇੱਕ ਪ੍ਰਯੋਗ ਆਇਆ ਜਿਸ ਨੇ ਕੰਮ ਕੀਤਾ.

ਆਮ ਵਾਂਗ, ਪਛਤਾਵੇ ਵਿਚ ਇਹ ਲਗਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਸਪੱਸ਼ਟ ਸੀ. ਮੈਂ ਕਲਾਇੰਟ ਨੂੰ ਐਲਵਿਨ ਵਾਂਗ ਹੀ ਮਸ਼ੀਨ 'ਤੇ ਰੱਖਿਆ - ਅਤੇ ਇਸ ਨੂੰ ਬੇਨਤੀ ਭੇਜੀ localhost. ਅਤੇ ਲੇਟੈਂਸੀ ਵਿੱਚ ਵਾਧਾ ਖਤਮ ਹੋ ਗਿਆ ਹੈ!

ਨੈੱਟਵਰਕ ਵਿੱਚ ਕੁਝ ਗੜਬੜ ਸੀ।

ਨੈੱਟਵਰਕ ਇੰਜੀਨੀਅਰ ਦੇ ਹੁਨਰ ਸਿੱਖਣਾ

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

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

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਲਾਂਚ ਕੀਤਾ PsPing ਐਲਵਿਨ ਦੇ TCP ਪੋਰਟ ਲਈ। ਮੈਂ ਡਿਫੌਲਟ ਸੈਟਿੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ - ਕੁਝ ਖਾਸ ਨਹੀਂ। ਇੱਕ ਹਜ਼ਾਰ ਤੋਂ ਵੱਧ ਪਿੰਗਾਂ ਵਿੱਚੋਂ, ਕੋਈ ਵੀ 10 ms ਤੋਂ ਵੱਧ ਨਹੀਂ ਸੀ, ਗਰਮ ਕਰਨ ਲਈ ਪਹਿਲੇ ਇੱਕ ਨੂੰ ਛੱਡ ਕੇ। ਇਹ 50ਵੇਂ ਪ੍ਰਤੀਸ਼ਤ 'ਤੇ 99 ms ਦੀ ਲੇਟੈਂਸੀ ਵਿੱਚ ਦੇਖੇ ਗਏ ਵਾਧੇ ਦੇ ਉਲਟ ਹੈ: ਉੱਥੇ, ਹਰ 100 ਬੇਨਤੀਆਂ ਲਈ, ਸਾਨੂੰ 50 ms ਦੀ ਲੇਟੈਂਸੀ ਦੇ ਨਾਲ ਲਗਭਗ ਇੱਕ ਬੇਨਤੀ ਦੇਖੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਫਿਰ ਮੈਂ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਟ੍ਰੈਕਰਟ: ਐਲਵਿਨ ਅਤੇ ਕਲਾਇੰਟ ਵਿਚਕਾਰ ਰੂਟ ਦੇ ਨਾਲ ਨੋਡਾਂ ਵਿੱਚੋਂ ਇੱਕ 'ਤੇ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ। ਪਰ ਟਰੇਸਰ ਵੀ ਖਾਲੀ ਹੱਥ ਪਰਤ ਗਿਆ।

ਇਸ ਲਈ ਇਹ ਮੇਰਾ ਕੋਡ, ਜੀਆਰਪੀਸੀ ਲਾਗੂਕਰਨ, ਜਾਂ ਨੈੱਟਵਰਕ ਨਹੀਂ ਸੀ ਜੋ ਦੇਰੀ ਦਾ ਕਾਰਨ ਬਣ ਰਿਹਾ ਸੀ। ਮੈਨੂੰ ਚਿੰਤਾ ਹੋਣ ਲੱਗੀ ਸੀ ਕਿ ਮੈਨੂੰ ਇਹ ਕਦੇ ਸਮਝ ਨਹੀਂ ਆਵੇਗੀ।

ਹੁਣ ਅਸੀਂ ਕਿਸ OS 'ਤੇ ਹਾਂ

gRPC ਲੀਨਕਸ 'ਤੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਵਿੰਡੋਜ਼ 'ਤੇ ਵਿਦੇਸ਼ੀ। ਮੈਂ ਇੱਕ ਪ੍ਰਯੋਗ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਜਿਸਨੇ ਕੰਮ ਕੀਤਾ: ਮੈਂ ਇੱਕ ਲੀਨਕਸ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਬਣਾਈ, ਲੀਨਕਸ ਲਈ ਐਲਵਿਨ ਨੂੰ ਕੰਪਾਇਲ ਕੀਤਾ, ਅਤੇ ਇਸਨੂੰ ਤੈਨਾਤ ਕੀਤਾ।

ਅਤੇ ਇੱਥੇ ਇਹ ਹੈ ਕਿ ਕੀ ਹੋਇਆ: ਲੀਨਕਸ ਪਿੰਗ-ਪੌਂਗ ਸਰਵਰ ਵਿੱਚ ਵਿੰਡੋਜ਼ ਹੋਸਟ ਦੇ ਸਮਾਨ ਦੇਰੀ ਨਹੀਂ ਸੀ, ਹਾਲਾਂਕਿ ਡੇਟਾ ਸਰੋਤ ਕੋਈ ਵੱਖਰਾ ਨਹੀਂ ਸੀ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਵਿੰਡੋਜ਼ ਲਈ gRPC ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਹੈ।

ਨਾਗਲੇ ਦਾ ਐਲਗੋਰਿਦਮ

ਇਹ ਸਾਰਾ ਸਮਾਂ ਮੈਂ ਸੋਚਿਆ ਕਿ ਮੈਂ ਝੰਡਾ ਗੁਆ ਰਿਹਾ ਹਾਂ gRPC. ਹੁਣ ਮੈਂ ਸਮਝਦਾ ਹਾਂ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ gRPC ਵਿੰਡੋਜ਼ ਫਲੈਗ ਗੁੰਮ ਹੈ। ਮੈਨੂੰ ਇੱਕ ਅੰਦਰੂਨੀ RPC ਲਾਇਬ੍ਰੇਰੀ ਮਿਲੀ ਜਿਸ ਬਾਰੇ ਮੈਨੂੰ ਭਰੋਸਾ ਸੀ ਕਿ ਸਾਰੇ ਫਲੈਗ ਸੈੱਟਾਂ ਲਈ ਵਧੀਆ ਕੰਮ ਕਰੇਗਾ ਵਿਨਸੌਕ. ਫਿਰ ਮੈਂ ਇਹ ਸਾਰੇ ਫਲੈਗ ਜੀਆਰਪੀਸੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਅਤੇ ਐਲਵਿਨ ਨੂੰ ਵਿੰਡੋਜ਼ ਉੱਤੇ, ਇੱਕ ਪੈਚ ਕੀਤੇ ਵਿੰਡੋਜ਼ ਪਿੰਗ-ਪੌਂਗ ਸਰਵਰ ਵਿੱਚ ਤਾਇਨਾਤ ਕੀਤਾ!

ਲਗਭਗ ਲਗਭਗ ਹੋ ਗਿਆ: ਮੈਂ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਫਲੈਗਾਂ ਨੂੰ ਹਟਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਜਦੋਂ ਤੱਕ ਰਿਗਰੈਸ਼ਨ ਵਾਪਸ ਨਹੀਂ ਆ ਜਾਂਦਾ ਤਾਂ ਕਿ ਮੈਂ ਕਾਰਨ ਦਾ ਪਤਾ ਲਗਾ ਸਕਾਂ। ਇਹ ਬਦਨਾਮ ਸੀ TCP_NODELAY, Nagle ਦਾ ਐਲਗੋਰਿਦਮ ਸਵਿੱਚ.

ਨਾਗਲੇ ਦਾ ਐਲਗੋਰਿਦਮ ਸੁਨੇਹਿਆਂ ਦੇ ਪ੍ਰਸਾਰਣ ਵਿੱਚ ਦੇਰੀ ਕਰਕੇ ਇੱਕ ਨੈੱਟਵਰਕ ਉੱਤੇ ਭੇਜੇ ਗਏ ਪੈਕੇਟਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਘਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਪੈਕੇਟ ਦਾ ਆਕਾਰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੰਖਿਆ ਬਾਈਟਸ ਤੋਂ ਵੱਧ ਨਹੀਂ ਜਾਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਇਹ ਔਸਤ ਉਪਭੋਗਤਾ ਲਈ ਵਧੀਆ ਹੋ ਸਕਦਾ ਹੈ, ਇਹ ਰੀਅਲ-ਟਾਈਮ ਸਰਵਰਾਂ ਲਈ ਵਿਨਾਸ਼ਕਾਰੀ ਹੈ ਕਿਉਂਕਿ OS ਕੁਝ ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਦੇਰੀ ਕਰੇਗਾ, ਜਿਸ ਨਾਲ ਘੱਟ QPS 'ਤੇ ਪਛੜ ਜਾਵੇਗਾ। ਯੂ gRPC ਇਹ ਫਲੈਗ TCP ਸਾਕਟਾਂ ਲਈ ਲੀਨਕਸ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਵਿੰਡੋਜ਼ ਵਿੱਚ ਨਹੀਂ। ਮੈਂ ਇਹ ਹਾਂ ਠੀਕ ਕੀਤਾ.

ਸਿੱਟਾ

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

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

ਅਗਲੀ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਘਟਣ ਦੇ ਨਾਲ ਲੇਟੈਂਸੀ ਵਿੱਚ ਵਾਧਾ ਦੇਖਦੇ ਹੋ, ਤਾਂ Nagle ਦਾ ਐਲਗੋਰਿਦਮ ਸ਼ੱਕੀਆਂ ਦੀ ਤੁਹਾਡੀ ਸੂਚੀ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ!

ਸਰੋਤ: www.habr.com