ਅਸੀਂ ਰਿਮੋਟਲੀ x10 ਵਰਕਲੋਡ ਵਾਧੇ ਤੋਂ ਕਿਵੇਂ ਬਚੇ ਅਤੇ ਅਸੀਂ ਕਿਹੜੇ ਸਿੱਟੇ ਕੱਢੇ

ਹੈਲੋ, ਹੈਬਰ! ਅਸੀਂ ਪਿਛਲੇ ਕੁਝ ਮਹੀਨਿਆਂ ਤੋਂ ਇੱਕ ਬਹੁਤ ਹੀ ਦਿਲਚਸਪ ਸਥਿਤੀ ਵਿੱਚ ਰਹਿ ਰਹੇ ਹਾਂ ਅਤੇ ਮੈਂ ਆਪਣੀ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸਕੇਲਿੰਗ ਕਹਾਣੀ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹਾਂਗਾ। ਇਸ ਸਮੇਂ ਦੌਰਾਨ, SberMarket ਨੇ ਆਰਡਰਾਂ ਵਿੱਚ 4 ਗੁਣਾ ਵਾਧਾ ਕੀਤਾ ਹੈ ਅਤੇ 17 ਨਵੇਂ ਸ਼ਹਿਰਾਂ ਵਿੱਚ ਸੇਵਾ ਸ਼ੁਰੂ ਕੀਤੀ ਹੈ। ਕਰਿਆਨੇ ਦੀ ਸਪੁਰਦਗੀ ਦੀ ਮੰਗ ਵਿੱਚ ਵਿਸਫੋਟਕ ਵਾਧੇ ਨੇ ਸਾਨੂੰ ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀ ਲੋੜ ਸੀ। ਕੱਟ ਦੇ ਤਹਿਤ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਅਤੇ ਉਪਯੋਗੀ ਸਿੱਟਿਆਂ ਬਾਰੇ ਪੜ੍ਹੋ।

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

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

ਇੱਕ ਦਿਨ, ਇੱਕ ਗਾਹਕ ਨੇ ਇੱਕ SberMarket ਕੋਰੀਅਰ ਨੂੰ ਕਿਹਾ ਕਿ ਉਹ ਉਸਨੂੰ ਬਿਨਾਂ ਸੰਪਰਕ ਕੀਤੇ - ਬਾਲਕੋਨੀ ਵਿੱਚ ਕਰਿਆਨੇ ਦਾ ਸਮਾਨ ਪਹੁੰਚਾਵੇ।

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

ਗੁਲਾਮ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲੜਾਈ ਦੀ ਤਿਆਰੀ ਵਿੱਚ ਹੈ

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

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

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

ਇੱਕ ਨਿਸ਼ਚਿਤ ਲੋਡ ਪੱਧਰ ਤੱਕ, ਸਾਡੇ ਕੋਲ http ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵੇਲੇ ਲਿਖਣ ਅਤੇ ਪੜ੍ਹਨ ਦੋਵਾਂ ਲਈ ਕਾਫ਼ੀ ਮਾਸਟਰ ਸੀ। ਮਾਰਚ ਦੇ ਅੱਧ ਵਿੱਚ, ਜਦੋਂ Sbermarket ਨੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰਿਮੋਟ ਕੰਮ ਵਿੱਚ ਬਦਲਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਸਾਡਾ RPS ਤੇਜ਼ੀ ਨਾਲ ਵਧਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ। ਸਾਡੇ ਜ਼ਿਆਦਾ ਤੋਂ ਜ਼ਿਆਦਾ ਗਾਹਕ ਸਵੈ-ਅਲੱਗ-ਥਲੱਗ ਹੋ ਗਏ ਜਾਂ ਘਰ ਤੋਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਜਿਸ ਨੇ ਸਾਡੇ ਕੰਮ ਦੇ ਬੋਝ ਦੇ ਸੂਚਕਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।

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

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

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

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

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

ਇੱਕ ਭਾਰੀ ਪੁੱਛਗਿੱਛ ਨੂੰ ਵੀ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਡੇਟਾਬੇਸ ਨੂੰ ਦੁਬਾਰਾ ਜੀਵਨ ਵਿੱਚ ਲਿਆ ਸਕਦਾ ਹੈ

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

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

ਇੱਕ ਦਿਲਚਸਪ ਪ੍ਰਭਾਵ ਇਹ ਸੀ ਕਿ MySQL, ਸਮਰੱਥਾ ਨਾਲ ਲੋਡ ਕੀਤਾ ਗਿਆ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਇੱਕ ਮਾਮੂਲੀ ਸੁਧਾਰ ਲਈ ਵੀ ਜਵਾਬ ਦਿੱਤਾ. ਕੁੱਲ ਲੋਡ ਦਾ ਸਿਰਫ 5% ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਕੁਝ ਸਵਾਲਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਧਿਆਨ ਦੇਣ ਯੋਗ CPU ਲੋਡ ਦਿਖਾਇਆ ਗਿਆ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਮਾਸਟਰ ਨੂੰ ਡੇਟਾਬੇਸ ਨਾਲ ਕੰਮ ਕਰਨ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਬਹਾਲ ਕਰਨ ਲਈ ਲੋੜੀਂਦਾ ਸਮਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਰੋਤਾਂ ਦੀ ਇੱਕ ਸਵੀਕਾਰਯੋਗ ਸਪਲਾਈ ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਗਏ। 

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

ਸਹਿਭਾਗੀ ਸੇਵਾਵਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਨਿਗਰਾਨੀ ਦਾ ਪ੍ਰਬੰਧ ਕਰੋ

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

ਸਹਿਭਾਗੀ ਸੇਵਾਵਾਂ ਦੇ ਕੋਟੇ ਨੂੰ ਅਣਕਿਆਸੇ ਤੌਰ 'ਤੇ ਪਾਰ ਕਰਨ ਨਾਲ ਤੁਹਾਡੇ ਆਪਣੇ ਲਈ ਡਾਊਨਟਾਈਮ ਹੋ ਸਕਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ API ਉਹਨਾਂ ਗਾਹਕਾਂ ਨੂੰ ਬਲੌਕ ਕਰਦੇ ਹਨ ਜੋ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਇੱਕ ਸਾਥੀ ਦੇ ਉਤਪਾਦਨ ਨੂੰ ਓਵਰਲੋਡ ਕਰ ਸਕਦੀਆਂ ਹਨ। 

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

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

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

ਕਈ ਵਾਰ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ "ਹੋਰ ਸੋਨੇ ਦੀ ਲੋੜ ਹੈ"(c) ਮਦਦ ਨਹੀਂ ਕਰਦਾ

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

ਸੰਭਾਵਿਤ ਪ੍ਰਦਰਸ਼ਨ ਵਾਧੇ ਦੀ ਬਜਾਏ, ਸਰਵਰ ਸਿਰਫ਼ "ਮਰ ਗਿਆ"। ਇਹ ਤੁਰੰਤ 100% 'ਤੇ ਲੋਡ ਹੋਇਆ ਅਤੇ ਹੋਰ ਵੀ ਹੌਲੀ ਹੌਲੀ ਜਵਾਬ ਦਿੱਤਾ। ਸ਼ੁਰੂ ਵਿੱਚ ਸਾਡੇ ਕੋਲ 2 ਕੋਰ ਅਤੇ 2 GB RAM ਸੀ। ਅਸੀਂ ਉਹ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਮਦਦ ਕਰਦਾ ਹੈ - ਅਸੀਂ ਸਰਵਰ ਨੂੰ 8 ਕੋਰ ਅਤੇ 32 ਜੀ.ਬੀ. ਸਭ ਕੁਝ ਬਹੁਤ ਖਰਾਬ ਹੋ ਗਿਆ (ਅਸੀਂ ਤੁਹਾਨੂੰ ਇੱਕ ਵੱਖਰੀ ਪੋਸਟ ਵਿੱਚ ਬਿਲਕੁਲ ਕਿਵੇਂ ਅਤੇ ਕਿਉਂ ਦੱਸਾਂਗੇ)। 

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

ਸਿੱਟਾ: ਮਿਆਰੀ ਢੰਗ ਜਿਵੇਂ ਕਿ "ਹੋਰ ਆਇਰਨ ਸ਼ਾਮਲ ਕਰੋ" ਹਮੇਸ਼ਾ ਕੰਮ ਨਹੀਂ ਕਰਦੇ। ਇਸ ਲਈ ਕਿਸੇ ਵੀ ਸੇਵਾ ਨੂੰ ਸਕੇਲ ਕਰਨ ਵੇਲੇ, ਤੁਹਾਨੂੰ ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਇਹ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਦੀ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਨਵੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਇਸਦੇ ਸੰਚਾਲਨ ਦੀ ਜਾਂਚ ਕਰੋ। 

ਸਟੇਟਲੈੱਸ ਆਸਾਨ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਦੀ ਕੁੰਜੀ ਹੈ

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

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

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

ਤੀਬਰ ਵਿਕਾਸ ਲਈ 7 ਸਿਧਾਂਤ

ਵਾਧੂ ਸਮਰੱਥਾ ਦੀ ਉਪਲਬਧਤਾ ਦੇ ਬਾਵਜੂਦ, ਅਸੀਂ ਵਿਕਾਸ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਕਈ ਗਲਤੀਆਂ 'ਤੇ ਕਦਮ ਰੱਖਿਆ ਹੈ। ਇਸ ਸਮੇਂ ਦੌਰਾਨ, ਆਦੇਸ਼ਾਂ ਦੀ ਗਿਣਤੀ 4 ਗੁਣਾ ਤੋਂ ਵੱਧ ਵਧ ਗਈ. ਹੁਣ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ 17 ਸ਼ਹਿਰਾਂ ਵਿੱਚ ਪ੍ਰਤੀ ਦਿਨ 000 ਤੋਂ ਵੱਧ ਆਰਡਰ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ ਅਤੇ ਭੂਗੋਲ ਨੂੰ ਹੋਰ ਅੱਗੇ ਵਧਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ - 62 ਦੇ ਪਹਿਲੇ ਅੱਧ ਵਿੱਚ ਇਹ ਸੇਵਾ ਪੂਰੇ ਰੂਸ ਵਿੱਚ ਸ਼ੁਰੂ ਹੋਣ ਦੀ ਉਮੀਦ ਹੈ। ਵਧ ਰਹੇ ਕੰਮ ਦੇ ਬੋਝ ਨਾਲ ਸਿੱਝਣ ਲਈ, ਸਾਡੇ ਪਹਿਲਾਂ ਹੀ ਪੂਰੇ ਕੋਨ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਅਸੀਂ ਨਿਰੰਤਰ ਵਿਕਾਸ ਦੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਲਈ 2020 ਬੁਨਿਆਦੀ ਸਿਧਾਂਤ ਵਿਕਸਿਤ ਕੀਤੇ ਹਨ:

1. ਘਟਨਾ ਪ੍ਰਬੰਧਨ. ਅਸੀਂ ਜੀਰਾ ਵਿੱਚ ਇੱਕ ਬੋਰਡ ਬਣਾਇਆ ਹੈ, ਜਿੱਥੇ ਹਰ ਘਟਨਾ ਨੂੰ ਟਿਕਟ ਦੇ ਰੂਪ ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ। ਇਹ ਅਸਲ ਵਿੱਚ ਘਟਨਾ ਨਾਲ ਸਬੰਧਤ ਕੰਮਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇਣ ਅਤੇ ਚਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ। ਆਖਰਕਾਰ, ਅਸਲ ਵਿੱਚ, ਗਲਤੀਆਂ ਕਰਨਾ ਡਰਾਉਣਾ ਨਹੀਂ ਹੈ, ਪਰ ਇੱਕੋ ਮੌਕੇ 'ਤੇ ਦੋ ਵਾਰ ਗਲਤੀਆਂ ਕਰਨਾ ਡਰਾਉਣਾ ਹੈ. ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਲਈ ਜਿੱਥੇ ਕਾਰਨਾਂ ਨੂੰ ਠੀਕ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਘਟਨਾਵਾਂ ਮੁੜ ਵਾਪਰਦੀਆਂ ਹਨ, ਕਾਰਵਾਈ ਲਈ ਨਿਰਦੇਸ਼ ਤਿਆਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਕਿਉਂਕਿ ਭਾਰੀ ਲੋਡ ਦੇ ਸਮੇਂ ਬਿਜਲੀ ਦੀ ਗਤੀ ਨਾਲ ਪ੍ਰਤੀਕ੍ਰਿਆ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ।
2. ਨਿਗਰਾਨੀ ਬਿਨਾਂ ਕਿਸੇ ਅਪਵਾਦ ਦੇ ਸਾਰੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਤੱਤਾਂ ਲਈ ਲੋੜੀਂਦਾ ਹੈ। ਇਹ ਉਸਦਾ ਧੰਨਵਾਦ ਸੀ ਕਿ ਅਸੀਂ ਲੋਡ ਦੇ ਵਾਧੇ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਗਏ ਅਤੇ ਖਾਤਮੇ ਨੂੰ ਤਰਜੀਹ ਦੇਣ ਲਈ "ਅੜਚਣਾਂ" ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਚੁਣਿਆ। ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ, ਉੱਚ ਲੋਡ ਦੇ ਅਧੀਨ, ਉਹ ਸਭ ਕੁਝ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ ਕਦੇ ਨਹੀਂ ਸੋਚਿਆ ਸੀ ਟੁੱਟ ਜਾਵੇਗਾ ਜਾਂ ਹੌਲੀ ਹੋਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇਗਾ. ਇਸ ਲਈ, ਉਹਨਾਂ ਦੀ ਨਿਗਰਾਨੀ ਅਤੇ ਅਨੁਮਾਨ ਲਗਾਉਣ ਲਈ ਪਹਿਲੀਆਂ ਘਟਨਾਵਾਂ ਦੇ ਵਾਪਰਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਨਵੀਆਂ ਚੇਤਾਵਨੀਆਂ ਬਣਾਉਣਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ।
3. ਸਹੀ ਚੇਤਾਵਨੀਆਂ ਬਸ ਜ਼ਰੂਰੀ ਹੈ ਜਦੋਂ ਲੋਡ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦਾ ਹੈ। ਪਹਿਲਾਂ, ਉਹਨਾਂ ਨੂੰ ਇਹ ਰਿਪੋਰਟ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਟੁੱਟਿਆ ਹੈ। ਦੂਜਾ, ਬਹੁਤ ਸਾਰੀਆਂ ਚੇਤਾਵਨੀਆਂ ਨਹੀਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ, ਕਿਉਂਕਿ ਗੈਰ-ਨਾਜ਼ੁਕ ਚੇਤਾਵਨੀਆਂ ਦੀ ਬਹੁਤਾਤ ਸਾਰੀਆਂ ਚੇਤਾਵਨੀਆਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਡਿੱਠ ਕਰਨ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ।
4. ਅਰਜ਼ੀਆਂ ਸਟੇਟ ਰਹਿਤ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਸਾਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਇਸ ਨਿਯਮ ਦਾ ਕੋਈ ਅਪਵਾਦ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਸਾਨੂੰ ਰਨਟਾਈਮ ਵਾਤਾਵਰਨ ਤੋਂ ਪੂਰੀ ਆਜ਼ਾਦੀ ਦੀ ਲੋੜ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਸਾਂਝਾ ਡੇਟਾ ਨੂੰ ਇੱਕ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ, ਉਦਾਹਰਨ ਲਈ, ਸਿੱਧੇ S3 ਵਿੱਚ. ਬਿਹਤਰ ਅਜੇ ਵੀ, ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ. https://12factor.net. ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਤਿੱਖੀ ਵਾਧੇ ਦੇ ਦੌਰਾਨ, ਕੋਡ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਅਤੇ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਨੂੰ ਸਿੱਧੇ ਵਧਾ ਕੇ ਲੋਡ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਵੇਗਾ।
5. ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਦਾ ਕੋਟਾ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ। ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਾਸ ਦੇ ਨਾਲ, ਇੱਕ ਸਮੱਸਿਆ ਨਾ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ, ਸਗੋਂ ਇੱਕ ਬਾਹਰੀ ਸੇਵਾ ਵਿੱਚ ਵੀ ਪੈਦਾ ਹੋ ਸਕਦੀ ਹੈ। ਸਭ ਤੋਂ ਤੰਗ ਕਰਨ ਵਾਲੀ ਗੱਲ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਅਜਿਹਾ ਕਿਸੇ ਅਸਫਲਤਾ ਦੇ ਕਾਰਨ ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਕੋਟੇ ਜਾਂ ਸੀਮਾਵਾਂ ਤੱਕ ਪਹੁੰਚਣ ਕਰਕੇ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਨੂੰ ਤੁਹਾਡੇ ਵਾਂਗ ਸਕੇਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। 
6. ਵੱਖਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਕਤਾਰਾਂ। ਇਹ ਬਹੁਤ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿਸੇ ਗੇਟਵੇ 'ਤੇ ਰੁਕਾਵਟ ਹੁੰਦੀ ਹੈ। ਸਾਨੂੰ ਡਾਟਾ ਟ੍ਰਾਂਸਫਰ ਵਿੱਚ ਦੇਰੀ ਦਾ ਸਾਹਮਣਾ ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ ਜੇਕਰ ਪੂਰੀ SMS ਭੇਜਣ ਵਾਲੀਆਂ ਕਤਾਰਾਂ ਨੇ ਸੂਚਨਾ ਪ੍ਰਣਾਲੀਆਂ ਵਿਚਕਾਰ ਸੂਚਨਾਵਾਂ ਦੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਵਿੱਚ ਦਖਲ ਨਾ ਦਿੱਤਾ ਹੁੰਦਾ। ਅਤੇ ਜੇਕਰ ਉਹ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ ਤਾਂ ਕਰਮਚਾਰੀਆਂ ਦੀ ਗਿਣਤੀ ਵਧਾਉਣਾ ਆਸਾਨ ਹੋਵੇਗਾ.
7. ਵਿੱਤੀ ਅਸਲੀਅਤ. ਜਦੋਂ ਡੇਟਾ ਪ੍ਰਵਾਹ ਵਿੱਚ ਵਿਸਫੋਟਕ ਵਾਧਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਟੈਰਿਫ ਅਤੇ ਗਾਹਕੀ ਬਾਰੇ ਸੋਚਣ ਦਾ ਕੋਈ ਸਮਾਂ ਨਹੀਂ ਹੁੰਦਾ. ਪਰ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਨੂੰ ਯਾਦ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇ ਤੁਸੀਂ ਇੱਕ ਛੋਟੀ ਕੰਪਨੀ ਹੋ. ਕਿਸੇ ਵੀ API ਦੇ ਮਾਲਕ, ਅਤੇ ਨਾਲ ਹੀ ਤੁਹਾਡੇ ਹੋਸਟਿੰਗ ਪ੍ਰਦਾਤਾ, ਇੱਕ ਵੱਡਾ ਬਿੱਲ ਭਰ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਇਕਰਾਰਨਾਮੇ ਨੂੰ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਹੈ।

ਸਿੱਟਾ

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

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

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਕੀ ਤੁਸੀਂ ਕਦੇ ਇਹਨਾਂ ਕਾਰਨਾਂ ਕਰਕੇ ਲੋਡ ਵਿੱਚ ਤਿੱਖੀ ਵਾਧੇ ਕਾਰਨ ਸੇਵਾ ਵਿੱਚ ਮੰਦੀ/ਨਿਘਾਰ ਦਾ ਅਨੁਭਵ ਕੀਤਾ ਹੈ:

• 55,6%ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਜੋੜਨ ਵਿੱਚ ਅਸਮਰੱਥਾ 10

• 16,7%ਹੋਸਟਿੰਗ ਪ੍ਰਦਾਤਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਸੀਮਾਵਾਂ3

• 33,3%ਤੀਜੀ-ਧਿਰ APIs ਦੀਆਂ ਸੀਮਾਵਾਂ 6

• 27,8%ਉਹਨਾਂ ਦੀਆਂ ਅਰਜ਼ੀਆਂ ਦੇ ਰਾਜ ਰਹਿਤ ਸਿਧਾਂਤਾਂ ਦੀ ਉਲੰਘਣਾ 5

• 88,9%ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਦਾ ਗੈਰ-ਅਨੁਕੂਲ ਕੋਡ16

18 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 6 ਉਪਭੋਗਤਾ ਬਚੇ ਹੋਏ ਹਨ।

ਸਰੋਤ: www.habr.com