ਰਿਮੋਟ ਤੋਂ ਕੰਮ ਕਰਦੇ ਹੋਏ ਅਸੀਂ ਕੰਮ ਦੇ ਅਚਾਨਕ ਵਾਧੇ ਤੋਂ ਕਿਵੇਂ ਬਚੇ ਅਤੇ ਅਸੀਂ ਕਿਹੜੇ ਸਿੱਟੇ ਕੱਢੇ

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

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

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

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

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

ਸਲੇਵ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲੜਾਈ ਦੀ ਤਿਆਰੀ ਵਿੱਚ ਹੈ।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ਸਿੱਟਾ

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

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

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

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

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

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

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

• 27,8%ਉਹਨਾਂ ਦੇ ਕਾਰਜਾਂ ਦੇ ਸਟੇਟਲੈੱਸ ਸਿਧਾਂਤਾਂ ਦੀ ਉਲੰਘਣਾ 5

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

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

ਸਰੋਤ: www.habr.com