ਇੱਕ ਗੱਲ੍ਹਾਂ ਵਾਲੀ SQL ਐਪ VPN ਉੱਤੇ ਕਿਉਂ ਹੌਲੀ ਚੱਲਦੀ ਹੈ ਅਤੇ ਕੀ ਬੈਚ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

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

ਲੱਛਣ ਸਕ੍ਰੀਨ ਹੈ, ਕਿਊਰੀ ਨਹੀਂ

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

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

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

ਇੱਕ ਵਰਤੋਂਕਾਰ ਕਾਰਵਾਈ ਵਿੱਚ ਲਗਾਤਾਰ ਉਡੀਕਾਂ ਗਿਣੋ

ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਬਜਾਏ ਕਲਾਇੰਟ ਵਿੱਚ ਮਾਪ ਪਾਓ। psql ਵਿੱਚ \timing on ਹਰ ਬਿਆਨ ਦਾ ਬੀਤਿਆ ਸਮਾਂ ਛਾਪਦਾ ਹੈ, ਅਤੇ EXPLAIN (ANALYZE, BUFFERS) ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਸ ਸਮੇਂ ਵਿੱਚੋਂ ਸਰਵਰ ਨੇ ਅਸਲ ਵਿੱਚ ਕੰਮ ਉੱਤੇ ਕਿੰਨਾ ਲਾਇਆ।

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

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

ਸੁਤੰਤਰ ਕਾਲਾਂ ਬੈਚ ਕਰੋ, ਨਿਰਭਰ ਰੱਖੋ

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

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

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

ਬੈਂਡਵਿਡਥ ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ ਕਨੈਕਸ਼ਨ ਦੁਬਾਰਾ ਵਰਤੋ

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

ADO.NET ਵਿੱਚ ਪੂਲ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਬੰਦ ਕਰਨਾ ਜਾਂ dispose ਕਰਨਾ ਨਵਾਂ ਭੌਤਿਕ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣ ਦੀ ਬਜਾਏ ਇਸਨੂੰ ਦੁਬਾਰਾ ਵਰਤੋਂ ਲਈ ਮੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਲੀਕ ਵਰਗਾ ਦਿਖਣ ਵਾਲਾ ਢਾਂਚਾ ਅਕਸਰ ਸਹੀ ਵਰਤੋਂ ਹੁੰਦਾ ਹੈ। ਪੂਲ ਦਾ ਅਸਲ ਵਿੱਚ ਵਰਤੋਂ ਵਿੱਚ ਹੋਣਾ ਜਾਂਚੋ, ਮੰਨੋ ਨਾ: ਭੌਤਿਕ ਕਨੈਕਸ਼ਨ ਬਣਨ ਦਾ ਲੌਗ ਰੱਖੋ, ਜਾਂ ਸਕ੍ਰੀਨ ਚੱਲਦਿਆਂ ਸਰਵਰ ਉੱਤੇ ਸੈਸ਼ਨ ਗਿਣਤੀ ਦੇਖੋ। SQL ਪ੍ਰਦਰਸ਼ਨ ਮਾਰਗਦਰਸ਼ਨ ਰਾਊਂਡ ਟ੍ਰਿਪ ਘਟਾਉਣ ਅਤੇ ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੀਆਂ ad hoc ਕਾਲਾਂ ਬੈਚ ਕਰਨ ਬਾਰੇ ਇਹੀ ਗੱਲ ਕਹਿੰਦਾ ਹੈ, ਸੇਵਾ-ਖਾਸ ਉਦਾਹਰਨਾਂ ਨਾਲ, ਜੋ ਤੁਹਾਨੂੰ ਆਪਣੀ ਤੈਨਾਤੀ ਉੱਤੇ ਲਾਗੂ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

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

ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨੂੰ ਡੇਟਾ ਦੇ ਨੇੜੇ ਲਿਜਾਣ ਬਾਰੇ ਸੋਚੋ

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

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

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