ਡਿਵੈਲਪਰ ਦੇਖਦੇ ਹਨ ਕਿ ਉਨ੍ਹਾਂ ਦੀ ਹੁਣੇ ਲਾਂਚ ਕੀਤੀ ਗਈ ਐਪ ਉਦੋਂ ਠੱਪ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਕੁਝ ਹਜ਼ਾਰ ਯੂਜ਼ਰਸ “go” 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਸੁਸਤੀ (slowdown) ਸ਼ਾਇਦ ਕੋਡ ਵਿੱਚ ਕੋਈ ਬੱਗ ਨਹੀਂ ਹੁੰਦੀ – ਇਹ ਸਰਵਰ ਦੇ CPU ਅਤੇ RAM ਦੀ ਜਗ੍ਹਾ ਲਈ ਜੰਗ ਹੁੰਦੀ ਹੈ। ਇਹ ਰੁਕਾਵਟ ਲੰਬੇ ਪੇਜ ਲੋਡ, ਟਾਈਮ-ਆਊਟ, ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕ੍ਰੈਸ਼ ਹੋਣ ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਯੂਜ਼ਰ ਅਨੁਭਵ, ਮਾਲੀਆ (revenue), ਅਤੇ ਬ੍ਰਾਂਡ ਵਿਸ਼ਵਾਸ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀ ਹੈ।

ਕਿਉਂ ਇੱਕ ਸਰਵਰ ਜੋ ਲੈਬ ਵਿੱਚ ਠੀਕ ਚੱਲ ਰਿਹਾ ਸੀ, ਉਹ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਰੁਕ ਸਕਦਾ ਹੈ

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

  • CPU (central processing unit) – ਉਹ ਪ੍ਰੋਸੈਸਰ ਜੋ ਹਰ ਲੂਪ, ਫੰਕਸ਼ਨ ਅਤੇ ਗਣਨਾ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਰਸੋਈਏ ਵਜੋਂ ਸਮਝੋ ਜੋ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਸਿਰਫ ਸੀਮਤ ਗਿਣਤੀ ਵਿੱਚ ਪਕਵਾਨ ਤਿਆਰ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਆਰਡਰ ਤੁਰੰਤ ਮਿਲ ਜਾਂਦਾ ਹੈ; ਸੌ ਆਰਡਰਾਂ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਰਸੋਈਆ ਅਜੇ ਵੀ ਉਸੇ ਰਫਤਾਰ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਖਾਣ ਵਾਲਿਆਂ ਨੂੰ ਲੰਬਾ ਇੰਤਜ਼ਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
  • RAM (random-access memory) – ਰਿਕੁਐਸ ਨੂੰ ਸੰਭਾਲਣ ਦੌਰਾਨ CPU ਨੂੰ ਲੋੜੀਂਦੇ ਡੇਟਾ ਲਈ ਅਸਥਾਈ ਸਟੋਰੇਜ। ਇਹ ਇੱਕ ਮੇਜ਼ ਵਾਂਗ ਹੈ ਜਿੱਥੇ ਰਸੋਈਆ ਹਰੇਕ ਪਕਵਾਨ ਲਈ ਸਮੱਗਰੀ ਰੱਖਦਾ ਹੈ। ਜੇਕਰ ਮੇਜ਼ ਭਰਿਆ ਹੋਇਆ ਹੈ, ਤਾਂ ਰਸੋਈਏ ਨੂੰ ਜਗ੍ਹਾ ਖਾਲੀ ਹੋਣ ਤੱਕ ਨਵੇਂ ਆਰਡਰ ਲੈਣੇ ਬੰਦ ਕਰਨੇ ਪੈਣਗੇ।

ਜਦੋਂ ਹਜ਼ਾਰਾਂ ਯੂਜ਼ਰਸ ਇੱਕੋ ਸਮੇਂ ਲੌਗਇਨ ਕਰਦੇ ਹਨ, ਤਾਂ ਹਰੇਕ ਰਿਕੁਐਸਟ CPU ਸਮੇਂ ਦਾ ਆਪਣਾ ਹਿੱਸਾ ਅਤੇ RAM ਦਾ ਆਪਣਾ ਹਿੱਸਾ ਲੈਂਦੀ ਹੈ। ਸਰਵਰ ਦੇ ਦੋਵਾਂ ਸਰੋਤਾਂ ਦਾ ਸੀਮਤ ਭੰਡਾਰ ਰਿਕੁਐਸਟਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਤਾਰ ਵਧਦੀ ਜਾਂਦੀ ਹੈ। ਸਰਵਰ ਖੁਦ ਹੌਲੀ ਨਹੀਂ ਹੋਇਆ ਹੈ; ਹਰੇਕ ਰਿਕੁਐਸਟ ਲਈ ਇੰਤਜ਼ਾਰ ਦਾ ਸਮਾਂ ਵਧ ਗਿਆ ਹੈ।

"ਬਸ ਇੱਕ ਵੱਡਾ ਬਾਕਸ ਖਰੀਦ ਲਓ" ਦਾ ਲਾਲਚ

ਇੱਕ ਆਮ ਪਹਿਲੀ ਪ੍ਰਤੀਕਿਰਿਆ ਮਸ਼ੀਨ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨਾ ਹੈ – ਜਿਸ ਨੂੰ vertical scaling ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਵਧੇਰੇ CPU ਕੋਰ ਜਾਂ ਵਧੇਰੇ RAM ਜੋੜਨਾ ਸਮਰੱਥਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦਾ ਹੈ: 4 ਕੋਰ ਤੋਂ 16, ਜਾਂ 8 GB ਤੋਂ 64 GB ਤੱਕ ਜਾਣਾ ਕਿਸੇ ਵੀ ਕੋਡ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਟ੍ਰੈਫਿਕ ਦੇ ਵੱਡੇ ਝਟਕੇ ਨੂੰ ਸਹਿ ਸਕਦਾ ਹੈ।

ਹਾਲਾਂਕਿ, vertical scaling ਇੱਕ ਸਖ਼ਤ ਸੀਮਾ 'ਤੇ ਆ ਕੇ ਰੁਕ ਜਾਂਦੀ ਹੈ:

  • ਭੌਤਿਕ ਸੀਮਾਵਾਂ (Physical limits) – ਹਰ ਮਦਰਬੋਰਡ ਵਿੱਚ ਸਿਰਫ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੰਖਿਆ ਵਿੱਚ ਕੋਰ ਅਤੇ ਸੀਮਤ ਮੈਮੋਰੀ ਹੀ ਹੋ ਸਕਦੀ ਹੈ।
  • ਘਟਦਾ ਹੋਇਆ ਲਾਭ (Diminishing returns) – ਹਰੇਕ ਵਾਧੂ ਕੋਰ ਜਾਂ ਗੀਗਾਬਾਈਟ ਪਿਛਲੇ ਵਾਲੇ ਨਾਲੋਂ ਵਧੇਰੇ ਖਰਚਾ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਵਾਧਾ ਘਟਦਾ ਜਾਂਦਾ ਹੈ।

ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਸਰਵਰ ਦੀ ਰਫ਼ਤਾਰ ਦਾ ਹੌਲੀ ਹੋਣਾ ਆਮ ਤੌਰ 'ਤੇ resource-contention ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ, ਕੋਡ ਦੀ ਖ਼ਰਾਬੀ ਨਹੀਂ। CPU cycles ਅਤੇ RAM slots ਸੀਮਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਬਹੁਤ ਸਾਰੀਆਂ requests ਇਕੱਠੀਆਂ ਆਉਂਦੀਆਂ ਹਨ ਤਾਂ ਉਹ queue ਵਿੱਚ ਲੱਗ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ response times ਵਧ ਜਾਂਦੇ ਹਨ। Vertical scaling ਤੁਹਾਨੂੰ ਥੋੜ੍ਹੀ ਹੋਰ headroom ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ ਪਰ ਜਲਦੀ ਹੀ ਇਹ physical ਅਤੇ economic ਸੀਮਾਵਾਂ ਵਿੱਚ ਆ ਜਾਂਦੀ ਹੈ। Horizontal scaling—ਇੱਕ load balancer ਦੇ ਪਿੱਛੇ ਹੋਰ ਛੋਟੇ servers ਜੋੜਨਾ—ਟ੍ਰੈਫਿਕ ਵਧਣ ਦੇ ਨਾਲ ਇੱਕ ਸਸਤਾ ਅਤੇ ਵਧੇਰੇ resilient ਰਸਤਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਜਿਸ ਪਲ ਤੁਹਾਨੂੰ queue ਲੰਬੀ ਹੁੰਦੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਇਹ ਮੁਲਾਂਕਣ ਕਰਨ ਦਾ ਸਮਾਂ ਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਕੁਝ ਹੋਰ cores ਕਾਫ਼ੀ ਹੋਣਗੇ ਜਾਂ ਕੀ ਤੁਹਾਨੂੰ ਕਈ machines 'ਤੇ load ਵੰਡਣਾ ਸ਼ੁਰੂ ਕਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

ਸਰੋਤ: dev.to ਲੇਖ “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”