Bioyino - ਵੰਡਿਆ, ਸਕੇਲੇਬਲ ਮੈਟ੍ਰਿਕਸ ਐਗਰੀਗੇਟਰ

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

ਸਾਡੇ ਪਿਛਲੇ ਲੇਖਾਂ ਤੋਂ (1, 2) ਤੁਸੀਂ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਕੁਝ ਸਮੇਂ ਤੱਕ ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅੰਕ ਇਕੱਠੇ ਕੀਤੇ ਹਨ ਬਰੂਬੇਕ. ਇਹ ਸੀ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ. ਇੱਕ ਕੋਡ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਇੱਕ ਪਲੱਗ ਵਾਂਗ ਸਧਾਰਨ ਹੈ (ਇਹ ਉਦੋਂ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਯੋਗਦਾਨ ਪਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ) ਅਤੇ, ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਇਹ ਸਾਡੇ 2 ਮਿਲੀਅਨ ਮੀਟ੍ਰਿਕਸ ਪ੍ਰਤੀ ਸਕਿੰਟ (MPS) ਨੂੰ ਸਿਖਰ 'ਤੇ ਸੰਭਾਲਦਾ ਹੈ। ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ। ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਤਾਰੇ ਦੇ ਨਾਲ 4 ਮਿਲੀਅਨ MPS ਲਈ ਸਮਰਥਨ ਦੱਸਿਆ ਗਿਆ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਲੀਨਕਸ ਉੱਤੇ ਨੈੱਟਵਰਕ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਦੱਸਿਆ ਗਿਆ ਚਿੱਤਰ ਮਿਲੇਗਾ। (ਸਾਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਨੈੱਟਵਰਕ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਕਿੰਨੇ MPS ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ)। ਇਹਨਾਂ ਫਾਇਦਿਆਂ ਦੇ ਬਾਵਜੂਦ, ਸਾਡੇ ਕੋਲ ਬਰੂਬੇਕ ਬਾਰੇ ਕਈ ਗੰਭੀਰ ਸ਼ਿਕਾਇਤਾਂ ਸਨ।

ਦਾਅਵਾ 1. ਪ੍ਰੋਜੈਕਟ ਦੇ ਡਿਵੈਲਪਰ, ਗਿਥੁਬ ਨੇ ਇਸਦਾ ਸਮਰਥਨ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ: ਪੈਚ ਅਤੇ ਫਿਕਸ ਪ੍ਰਕਾਸ਼ਤ ਕਰਨਾ, ਸਾਡਾ ਸਵੀਕਾਰ ਕਰਨਾ ਅਤੇ (ਸਿਰਫ ਸਾਡਾ ਹੀ ਨਹੀਂ) ਪੀ.ਆਰ. ਪਿਛਲੇ ਕੁਝ ਮਹੀਨਿਆਂ (ਫਰਵਰੀ-ਮਾਰਚ 2018 ਤੋਂ) ਵਿੱਚ, ਸਰਗਰਮੀ ਮੁੜ ਸ਼ੁਰੂ ਹੋਈ ਹੈ, ਪਰ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਲਗਭਗ 2 ਸਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸ਼ਾਂਤ ਸੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਪ੍ਰੋਜੈਕਟ ਤਿਆਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਅੰਦਰੂਨੀ Gihub ਲੋੜਾਂ ਲਈ, ਜੋ ਕਿ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਲਈ ਇੱਕ ਗੰਭੀਰ ਰੁਕਾਵਟ ਬਣ ਸਕਦੀ ਹੈ।

ਦਾਅਵਾ 2. ਗਣਨਾ ਦੀ ਸ਼ੁੱਧਤਾ। ਬਰੂਬੇਕ ਏਕੀਕਰਣ ਲਈ ਕੁੱਲ 65536 ਮੁੱਲਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਕੁਝ ਮੈਟ੍ਰਿਕਸ ਲਈ, ਏਕੀਕਰਣ ਦੀ ਮਿਆਦ (30 ਸਕਿੰਟ) ਦੇ ਦੌਰਾਨ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਮੁੱਲ ਆ ਸਕਦੇ ਹਨ (ਸਿਖਰ 'ਤੇ 1)। ਇਸ ਨਮੂਨੇ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਵੱਧ ਤੋਂ ਵੱਧ ਅਤੇ ਘੱਟੋ ਘੱਟ ਮੁੱਲ ਬੇਕਾਰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ. ਉਦਾਹਰਨ ਲਈ, ਇਸ ਤਰ੍ਹਾਂ:

ਜਿਵੇਂ ਕਿ ਇਹ ਸੀ

ਇਹ ਕਿਵੇਂ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ

ਇਸੇ ਕਾਰਨ ਕਰਕੇ, ਰਕਮਾਂ ਦੀ ਆਮ ਤੌਰ 'ਤੇ ਗਲਤ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇੱਥੇ ਇੱਕ 32-ਬਿੱਟ ਫਲੋਟ ਓਵਰਫਲੋ ਦੇ ਨਾਲ ਇੱਕ ਬੱਗ ਸ਼ਾਮਲ ਕਰੋ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਨਿਰਦੋਸ਼ ਮੈਟ੍ਰਿਕ ਪ੍ਰਾਪਤ ਕਰਨ ਵੇਲੇ ਸਰਵਰ ਨੂੰ segfault ਵਿੱਚ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਸਭ ਕੁਝ ਵਧੀਆ ਬਣ ਜਾਂਦਾ ਹੈ। ਬੱਗ, ਤਰੀਕੇ ਨਾਲ, ਠੀਕ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਅਤੇ ਅੰਤ ਵਿੱਚ ਦਾਅਵਾ ਐਕਸ. ਲਿਖਣ ਦੇ ਸਮੇਂ, ਅਸੀਂ ਇਸ ਨੂੰ ਸਾਰੇ 14 ਵੱਧ ਜਾਂ ਘੱਟ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸਟੈਟਸਡੀ ਲਾਗੂਕਰਨਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਨ ਲਈ ਤਿਆਰ ਹਾਂ ਜੋ ਅਸੀਂ ਲੱਭਣ ਦੇ ਯੋਗ ਸੀ। ਚਲੋ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਕੁਝ ਸਿੰਗਲ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਇੰਨਾ ਵਧ ਗਿਆ ਹੈ ਕਿ 4 ਮਿਲੀਅਨ MPS ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਹੁਣ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਜਾਂ ਭਾਵੇਂ ਇਹ ਅਜੇ ਵਧਿਆ ਨਹੀਂ ਹੈ, ਪਰ ਮੈਟ੍ਰਿਕਸ ਤੁਹਾਡੇ ਲਈ ਪਹਿਲਾਂ ਹੀ ਇੰਨੇ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿ ਚਾਰਟ ਵਿੱਚ 2-3 ਮਿੰਟ ਦੀ ਕਮੀ ਪਹਿਲਾਂ ਹੀ ਨਾਜ਼ੁਕ ਬਣ ਸਕਦੀ ਹੈ ਅਤੇ ਪ੍ਰਬੰਧਕਾਂ ਵਿੱਚ ਅਸਹਿਣਸ਼ੀਲ ਉਦਾਸੀ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ। ਕਿਉਂਕਿ ਡਿਪਰੈਸ਼ਨ ਦਾ ਇਲਾਜ ਕਰਨਾ ਇੱਕ ਬੇਸ਼ੁਮਾਰ ਕੰਮ ਹੈ, ਤਕਨੀਕੀ ਹੱਲਾਂ ਦੀ ਲੋੜ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ, ਤਾਂ ਜੋ ਸਰਵਰ 'ਤੇ ਅਚਾਨਕ ਸਮੱਸਿਆ ਦਫਤਰ ਵਿੱਚ ਮਨੋਵਿਗਿਆਨਕ ਜੂਮਬੀ ਐਪੋਕੇਲਿਪਸ ਦਾ ਕਾਰਨ ਨਾ ਬਣੇ। ਦੂਜਾ, ਲੀਨਕਸ ਨੈਟਵਰਕ ਸਟੈਕ ਵਿੱਚ ਡੂੰਘੀ ਖੁਦਾਈ ਕੀਤੇ ਬਿਨਾਂ ਅਤੇ ਲੋੜੀਂਦੇ ਆਕਾਰ ਤੱਕ "ਚੌੜਾਈ ਵਿੱਚ" ਵਧਦੇ ਹੋਏ, 4 ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ MPS ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਲਈ ਸਕੇਲਿੰਗ।

ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਸਕੇਲਿੰਗ ਲਈ ਥਾਂ ਸੀ, ਅਸੀਂ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। "ਬਾਰੇ! ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ! ਇਹ ਸਧਾਰਨ ਹੈ, ਅਸੀਂ ਇਹ ਕਰ ਸਕਦੇ ਹਾਂ," ਅਸੀਂ ਸੋਚਿਆ ਅਤੇ 2 ਸਰਵਰ ਲਾਂਚ ਕੀਤੇ, ਹਰੇਕ 'ਤੇ ਬਰੂਬੇਕ ਦੀ ਇੱਕ ਕਾਪੀ ਤਿਆਰ ਕੀਤੀ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਦੋਵਾਂ ਸਰਵਰਾਂ ਲਈ ਮੈਟ੍ਰਿਕਸ ਦੇ ਨਾਲ ਟ੍ਰੈਫਿਕ ਦੀ ਨਕਲ ਕਰਨੀ ਪਈ ਅਤੇ ਇਸਦੇ ਲਈ ਲਿਖਣਾ ਵੀ ਸੀ ਛੋਟੀ ਸਹੂਲਤ. ਅਸੀਂ ਇਸ ਨਾਲ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕੀਤਾ, ਪਰ... ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ। ਪਹਿਲਾਂ ਸਭ ਕੁਝ ਬਹੁਤ ਵਧੀਆ ਜਾਪਦਾ ਸੀ: ਹਰੇਕ ਬਰੂਬੈਕ ਇਕੱਤਰਤਾ ਦਾ ਆਪਣਾ ਸੰਸਕਰਣ ਇਕੱਠਾ ਕਰਦਾ ਹੈ, ਹਰ 30 ਸਕਿੰਟਾਂ ਵਿੱਚ ਇੱਕ ਵਾਰ ਗ੍ਰੇਫਾਈਟ ਨੂੰ ਡੇਟਾ ਲਿਖਦਾ ਹੈ, ਪੁਰਾਣੇ ਅੰਤਰਾਲ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਦਾ ਹੈ (ਇਹ ਗ੍ਰੇਫਾਈਟ ਵਾਲੇ ਪਾਸੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ)। ਜੇਕਰ ਇੱਕ ਸਰਵਰ ਅਚਾਨਕ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਹਮੇਸ਼ਾ ਇੱਕ ਦੂਸਰਾ ਹੁੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇਸਦੀ ਆਪਣੀ ਕਾਪੀ ਹੈ। ਪਰ ਇੱਥੇ ਸਮੱਸਿਆ ਹੈ: ਜੇਕਰ ਸਰਵਰ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਗ੍ਰਾਫਾਂ 'ਤੇ ਇੱਕ "ਆਰਾ" ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਇਹ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਹੈ ਕਿ ਬਰੂਬੇਕ ਦੇ 30-ਸਕਿੰਟ ਦੇ ਅੰਤਰਾਲਾਂ ਨੂੰ ਸਮਕਾਲੀ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਰੈਸ਼ ਦੇ ਸਮੇਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਓਵਰਰਾਈਟ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਦੂਜਾ ਸਰਵਰ ਚਾਲੂ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਹੀ ਚੀਜ਼ ਵਾਪਰਦੀ ਹੈ. ਕਾਫ਼ੀ ਸਹਿਣਯੋਗ, ਪਰ ਮੈਂ ਬਿਹਤਰ ਚਾਹੁੰਦਾ ਹਾਂ! ਸਕੇਲੇਬਿਲਟੀ ਦੀ ਸਮੱਸਿਆ ਵੀ ਦੂਰ ਨਹੀਂ ਹੋਈ ਹੈ। ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਅਜੇ ਵੀ ਇੱਕ ਸਿੰਗਲ ਸਰਵਰ 'ਤੇ "ਉੱਡਦੇ ਹਨ", ਅਤੇ ਇਸਲਈ ਅਸੀਂ ਨੈੱਟਵਰਕ ਪੱਧਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਉਸੇ 2-4 ਮਿਲੀਅਨ MPS ਤੱਕ ਸੀਮਿਤ ਹਾਂ।

ਜੇ ਤੁਸੀਂ ਸਮੱਸਿਆ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ ਸੋਚਦੇ ਹੋ ਅਤੇ ਉਸੇ ਸਮੇਂ ਇੱਕ ਬੇਲਚਾ ਨਾਲ ਬਰਫ਼ ਨੂੰ ਖੋਦਦੇ ਹੋ, ਤਾਂ ਹੇਠਾਂ ਦਿੱਤਾ ਸਪੱਸ਼ਟ ਵਿਚਾਰ ਮਨ ਵਿੱਚ ਆ ਸਕਦਾ ਹੈ: ਤੁਹਾਨੂੰ ਇੱਕ ਸਟੈਟਸਡੀ ਦੀ ਲੋੜ ਹੈ ਜੋ ਵਿਤਰਿਤ ਮੋਡ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ. ਉਹ ਹੈ, ਜੋ ਸਮੇਂ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਨੋਡਾਂ ਵਿਚਕਾਰ ਸਮਕਾਲੀਕਰਨ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। "ਬੇਸ਼ੱਕ, ਅਜਿਹਾ ਹੱਲ ਸ਼ਾਇਦ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ," ਅਸੀਂ ਕਿਹਾ ਅਤੇ ਗੂਗਲ 'ਤੇ ਗਏ …. ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਕੁਝ ਨਹੀਂ ਮਿਲਿਆ. ਵੱਖ-ਵੱਖ ਸਟੈਟਸਡੀ ਲਈ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਦੇਖਣ ਤੋਂ ਬਾਅਦ (https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017 ਦਸੰਬਰ, XNUMX ਤੱਕ), ਸਾਨੂੰ ਬਿਲਕੁਲ ਕੁਝ ਨਹੀਂ ਮਿਲਿਆ। ਜ਼ਾਹਰ ਹੈ, ਨਾ ਤਾਂ ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਨਾ ਹੀ ਇਹਨਾਂ ਹੱਲਾਂ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਅਜੇ ਤੱਕ ਬਹੁਤ ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਉਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕੁਝ ਲੈ ਕੇ ਆਉਣਗੇ.

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

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

ਕਿਸ ਉੱਤੇ ਲਿਖਣਾ ਹੈ? ਬੇਸ਼ੱਕ, ਜੰਗਾਲ ਵਿੱਚ. ਕਿਉਂ?

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

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

ਸਮਾਂ ਬੀਤ ਗਿਆ...

ਅੰਤ ਵਿੱਚ, ਕਈ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ਾਂ ਦੇ ਬਾਅਦ, ਪਹਿਲਾ ਕਾਰਜਸ਼ੀਲ ਸੰਸਕਰਣ ਤਿਆਰ ਹੋ ਗਿਆ ਸੀ। ਕੀ ਹੋਇਆ? ਅਜਿਹਾ ਹੀ ਹੋਇਆ ਹੈ।

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

ਮੈਟ੍ਰਿਕਸ ਵਾਲੇ UDP ਪੈਕੇਟ ਇੱਕ ਸਧਾਰਨ ਰਾਉਂਡ ਰੌਬਿਨ ਦੁਆਰਾ ਨੈਟਵਰਕ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਤੇ ਨੋਡਾਂ ਵਿਚਕਾਰ ਅਸੰਤੁਲਿਤ ਹੁੰਦੇ ਹਨ। ਬੇਸ਼ੱਕ, ਨੈੱਟਵਰਕ ਹਾਰਡਵੇਅਰ ਪੈਕੇਟਾਂ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਪਾਰਸ ਨਹੀਂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਲਈ 4M ਪੈਕੇਟ ਪ੍ਰਤੀ ਸਕਿੰਟ ਤੋਂ ਵੱਧ ਖਿੱਚ ਸਕਦਾ ਹੈ, ਉਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਦਾ ਜ਼ਿਕਰ ਨਾ ਕਰਨਾ ਜਿਸ ਬਾਰੇ ਇਹ ਕੁਝ ਵੀ ਨਹੀਂ ਜਾਣਦਾ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਇਸ ਗੱਲ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹਾਂ ਕਿ ਹਰੇਕ ਪੈਕੇਟ ਵਿੱਚ ਮੈਟ੍ਰਿਕਸ ਇੱਕ ਵਾਰ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਅਸੀਂ ਇਸ ਥਾਂ 'ਤੇ ਕਿਸੇ ਵੀ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਦਾ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਗਾਉਂਦੇ ਹਾਂ। ਜੇਕਰ ਕੋਈ ਸਰਵਰ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਨੈੱਟਵਰਕ ਡਿਵਾਈਸ ਤੇਜ਼ੀ ਨਾਲ (1-2 ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ) ਇਸ ਤੱਥ ਦਾ ਪਤਾ ਲਗਾਉਂਦੀ ਹੈ ਅਤੇ ਕਰੈਸ਼ ਹੋਏ ਸਰਵਰ ਨੂੰ ਰੋਟੇਸ਼ਨ ਤੋਂ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਇਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਪੈਸਿਵ (ਅਰਥਾਤ, ਗੈਰ-ਲੀਡਰ) ਨੋਡਾਂ ਨੂੰ ਚਾਰਟ 'ਤੇ ਡਰਾਅਡਾਊਨ ਨੂੰ ਧਿਆਨ ਵਿਚ ਰੱਖੇ ਬਿਨਾਂ ਅਮਲੀ ਤੌਰ 'ਤੇ ਚਾਲੂ ਅਤੇ ਬੰਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਵੱਧ ਤੋਂ ਵੱਧ ਜੋ ਅਸੀਂ ਗੁਆਉਂਦੇ ਹਾਂ ਉਹ ਮੈਟ੍ਰਿਕਸ ਦਾ ਹਿੱਸਾ ਹੈ ਜੋ ਆਖਰੀ ਸਕਿੰਟ ਵਿੱਚ ਆਇਆ ਸੀ। ਲੀਡਰ ਦਾ ਅਚਾਨਕ ਨੁਕਸਾਨ/ਬੰਦ/ਸਵਿੱਚ ਅਜੇ ਵੀ ਇੱਕ ਮਾਮੂਲੀ ਵਿਗਾੜ ਪੈਦਾ ਕਰੇਗਾ (30 ਸਕਿੰਟ ਦਾ ਅੰਤਰਾਲ ਅਜੇ ਵੀ ਸਿੰਕ ਤੋਂ ਬਾਹਰ ਹੈ), ਪਰ ਜੇਕਰ ਨੋਡਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਘੱਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਸਮਕਾਲੀਕਰਨ ਪੈਕੇਟ ਭੇਜ ਕੇ। .

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

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

ਵਿਕਾਸ ਦੇ ਦੌਰਾਨ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਨੈਟਵਰਕ ਹਿੱਸੇ ਕਾਰਨ ਹੋਈਆਂ ਸਨ। ਨੈਟਵਰਕ ਦੇ ਵਹਾਅ ਨੂੰ ਵੱਖਰੀਆਂ ਸੰਸਥਾਵਾਂ ਵਿੱਚ ਵੱਖ ਕਰਨ ਦਾ ਮੁੱਖ ਟੀਚਾ ਇੱਕ ਪ੍ਰਵਾਹ ਦੁਆਰਾ ਖਰਚਣ ਵਾਲੇ ਸਮੇਂ ਨੂੰ ਘਟਾਉਣ ਦੀ ਇੱਛਾ ਸੀ। ਨਾ ਸਾਕਟ ਤੋਂ ਡਾਟਾ ਪੜ੍ਹਨ ਲਈ। ਅਸਿੰਕਰੋਨਸ UDP ਅਤੇ ਨਿਯਮਤ recvmsg ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਵਿਕਲਪ ਤੇਜ਼ੀ ਨਾਲ ਗਾਇਬ ਹੋ ਗਏ: ਪਹਿਲਾ ਇਵੈਂਟ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਉਪਭੋਗਤਾ-ਸਪੇਸ CPU ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ, ਦੂਜੇ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਸੰਦਰਭ ਸਵਿੱਚਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ ਇਹ ਹੁਣ ਵਰਤਿਆ ਗਿਆ ਹੈ recvmmsg ਵੱਡੇ ਬਫਰਾਂ ਨਾਲ (ਅਤੇ ਬਫਰ, ਸੱਜਣ ਅਫਸਰ, ਤੁਹਾਡੇ ਲਈ ਕੁਝ ਨਹੀਂ ਹਨ!) ਰੈਗੂਲਰ UDP ਲਈ ਸਮਰਥਨ ਹਲਕੇ ਕੇਸਾਂ ਲਈ ਰਾਖਵਾਂ ਹੈ ਜਿੱਥੇ recvmmsg ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਮਲਟੀਮੈਸੇਜ ਮੋਡ ਵਿੱਚ, ਮੁੱਖ ਚੀਜ਼ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸੰਭਵ ਹੈ: ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ, ਨੈਟਵਰਕ ਥ੍ਰੈੱਡ OS ਕਤਾਰ ਨੂੰ ਰੇਕ ਕਰਦਾ ਹੈ - ਸਾਕਟ ਤੋਂ ਡੇਟਾ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਯੂਜ਼ਰਸਪੇਸ ਬਫਰ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਦਾ ਹੈ, ਸਿਰਫ ਕਦੇ-ਕਦਾਈਂ ਭਰੇ ਹੋਏ ਬਫਰ ਨੂੰ ਦੇਣ ਲਈ ਬਦਲਦਾ ਹੈ ਐਗਰੀਗੇਟਰ ਸਾਕਟ ਵਿੱਚ ਕਤਾਰ ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਕੱਠੀ ਨਹੀਂ ਹੁੰਦੀ, ਡਿੱਗੇ ਹੋਏ ਪੈਕੇਟਾਂ ਦੀ ਗਿਣਤੀ ਅਮਲੀ ਤੌਰ 'ਤੇ ਨਹੀਂ ਵਧਦੀ।

ਟਿੱਪਣੀ

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

ਅੰਤ ਵਿੱਚ, ਚਾਰਟ ਪ੍ਰੇਮੀਆਂ ਲਈ ਕੁਝ ਚਾਰਟ.

ਹਰੇਕ ਸਰਵਰ ਲਈ ਆਉਣ ਵਾਲੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਸੰਖਿਆ 'ਤੇ ਅੰਕੜੇ: 2 ਮਿਲੀਅਨ ਤੋਂ ਵੱਧ MPS।

ਨੋਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਅਯੋਗ ਕਰਨਾ ਅਤੇ ਆਉਣ ਵਾਲੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਮੁੜ ਵੰਡਣਾ।

ਆਊਟਗੋਇੰਗ ਮੈਟ੍ਰਿਕਸ 'ਤੇ ਅੰਕੜੇ: ਸਿਰਫ ਇੱਕ ਨੋਡ ਹਮੇਸ਼ਾ ਭੇਜਦਾ ਹੈ - ਰੇਡ ਬੌਸ.

ਹਰੇਕ ਨੋਡ ਦੇ ਸੰਚਾਲਨ ਦੇ ਅੰਕੜੇ, ਵੱਖ-ਵੱਖ ਸਿਸਟਮ ਮੋਡੀਊਲਾਂ ਵਿੱਚ ਗਲਤੀਆਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ।

ਆਉਣ ਵਾਲੇ ਮੈਟ੍ਰਿਕਸ ਦਾ ਵੇਰਵਾ (ਮੈਟ੍ਰਿਕ ਨਾਮ ਲੁਕਾਏ ਗਏ ਹਨ)।

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

ਬੇਸ਼ੱਕ, ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਹਰ ਕਿਸੇ ਦਾ ਸੁਆਗਤ ਹੈ: ਪੀਆਰ ਬਣਾਓ, ਮੁੱਦੇ, ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਅਸੀਂ ਜਵਾਬ ਦੇਵਾਂਗੇ, ਸੁਧਾਰ ਕਰਾਂਗੇ, ਆਦਿ।

ਇਹ ਕਿਹਾ ਜਾ ਰਿਹਾ ਹੈ, ਇਹ ਸਭ ਲੋਕੋ, ਸਾਡੇ ਹਾਥੀ ਖਰੀਦੋ!

ਸਰੋਤ: www.habr.com