28 ਦਸੰ 2025·8 ਮਿੰਟ
Claude Code ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਜਾਂਚ: ਇੱਕ ਮਾਪਿਆ ਗਿਆ ਵਰਕਫਲੋ
Claude Code ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਜਾਂਚ ਲਈ ਵਰਤੋ ਇੱਕ ਦੁਹਰਾਯੋਗ ਲੂਪ ਨਾਲ: ਮਾਪੋ, ਹਿਪੋਥੈਸਿਸ ਬਣਾਓ, ਛੋਟੀ ਬਦਲਾਅ ਕਰੋ, ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੁਬਾਰਾ ਮਾਪੋ।
Claude Code ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਜਾਂਚ ਲਈ ਵਰਤੋ ਇੱਕ ਦੁਹਰਾਯੋਗ ਲੂਪ ਨਾਲ: ਮਾਪੋ, ਹਿਪੋਥੈਸਿਸ ਬਣਾਓ, ਛੋਟੀ ਬਦਲਾਅ ਕਰੋ, ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੁਬਾਰਾ ਮਾਪੋ।
ਪ੍ਰਦਰਸ਼ਨ ਬੱਗ ਅਟਕਲਾਂ ਨੂੰ ਦੇਵਦੇ ਹਨ। ਕੋਈ ਪੰਨਾ ਧੀਮਾ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ ਜਾਂ ਕੋਈ API ਟਾਇਮਆਊਟ ਹੁੰਦੀ ਹੈ, ਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਕਦਮ ਹੁੰਦਾ ਹੈ ਕੋਡ "ਸਾਫ਼" ਕਰਨਾ, caching ਜੋੜਨਾ, ਜਾਂ ਇੱਕ ਲੂਪ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ। ਮੁੱਦਾ ਇਹ ਹੈ ਕਿ "ਧੀਮਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ" ਕੋਈ ਮੈਟ੍ਰਿਕ ਨਹੀਂ ਹੈ, ਅਤੇ "ਸਾਫ਼" ਕਰਨ ਦਾ ਮਤਲਬ ਤੇਜ਼ ਹੋਣਾ ਨਹੀਂ ਹੁੰਦਾ।
ਮਾਪਣ ਤੋਂ ਬਿਨਾਂ, ਟੀਮਾਂ ਗਲਤ ਚੀਜ਼ਾਂ ਬਦਲਣ ਵਿੱਚ ਘੰਟੇ ਵੱਅਊਂਦੀਆਂ ਹਨ। ਹੌਟ ਪਾਥ ਡੇਟਾਬੇਸ, ਨੈੱਟਵਰਕ, ਜਾਂ ਇੱਕ ਅਣਛਿਹੜੀ ਐਲੋਕੇਸ਼ਨ ਵਿੱਚ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਟੀਮ ਉਹ ਕੋਡ ਚੰਨਦੀ ਹੈ ਜੋ ਥੋੜ੍ਹੀ ਹੀ ਰਨ ਹੁੰਦੀ ਹੈ। ਹੋਰ ਬੁਰਾ, ਇੱਕ ਸਮਰਥਿਤ ਦਿਸਦਾ ਬਦਲਾਅ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਖਰਾਬ ਵੀ ਕਰ ਸਕਦਾ ਹੈ: ਇਕ ਤੰਗ ਲੂਪ ਵਿੱਚ ਵਾਧੂ ਲੌਗਿੰਗ, ਇੱਕ ਕੈਸ਼ ਜੋ ਮੈਮੋਰੀ ਦਬਾਅ ਵਧਾਉਂਦਾ ਹੈ, ਜਾਂ ਪੈਰਾਲਲ ਕੰਮ ਜਿਸ ਨਾਲ ਲਾਕ ਕੰਟੈਨਸ਼ਨ ਬਣਦੀ ਹੈ।
ਅਟਕਲਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਨਾਲ ਵਿਹਾਰ ਟੁੱਟਣ ਦਾ ਖਤਰਾ ਵੀ ਹੁੰਦਾ ਹੈ। ਜਦ ਤੁਸੀਂ ਤੇਜ਼ ਕਰਨ ਲਈ ਕੋਡ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਨਤੀਜੇ, error handling, ਆਰਡਰਿੰਗ, ਜਾਂ ਰੀਟ੍ਰਾਈਜ਼ ਬਦਲ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਸਹੀਤਾ ਅਤੇ ਤੇਜ਼ੀ ਨੂੰ ਇਕੱਠੇ ਦੁਬਾਰਾ ਜਾਂਚਦੇ ਨਹੀਂ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਬੈਂਚਮਾਰਕ "ਜਿੱਤ" ਸਕਦੇ ਹੋ ਪਰ ਇੱਕ ਬੱਗ ਚੁਪਕੇ ਨਾਲ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹੋ।
ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਵਾਦ-ਵਿਵਾਦ ਵਾਂਗ ਨਾ ਸਮਝੋ; ਇਸਨੂੰ ਇਕ ਐਕਸਪੇਰੀਮੈਂਟ ਮੰਨੋ। ਲੂਪ ਸਧਾਰਣ ਅਤੇ ਦੁਹਰਾਯੋਗ ਹੈ:
ਕਈ ਜਿੱਤ ਨੱਝੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: p95 latency ਤੋਂ 8% ਘਟਾਉਣਾ, ਪੀਕ ਮੈਮੋਰੀ 50 MB ਘੱਟ ਕਰਨਾ, ਜਾਂ ਇੱਕ DB ਕਾਨੂੰਰੀ ਨੂੰ ਕੱਟਣਾ। ਇਹ ਜਿੱਤ ਮਹਤਵਪੂਰਨ ਹਨ — ਪਰ ਸਿਰਫ ਜਦ ਉਹ ਮਾਪੇ, ਪੁਸ਼ਟੀ ਕੀਤੇ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਹਨ।
ਇਹ ਇੱਕ ਲੂਪ ਵਜੋਂ ਹੀ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਇਕ ਵਾਰੀ "ਇਸਨੂੰ ਤੇਜ਼ ਕਰੋ" ਦੀ ਬੇਨਤੀ। ਲੂਪ ਤੁਹਾਨੂੰ ਸੱਚਾਈ ਦੇ ਨੇੜੇ ਰੱਖਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਐਕਸ਼ਨ ਸਬੂਤ ਅਤੇ ਇੱਕ ਨੰਬਰ ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ।
ਸਪੱਸ਼ਟ ਕ੍ਰਮ:
ਹਰ ਕਦਮ ਤੁਹਾਨੂੰ ਵੱਖ-ਵੱਖ ਕਿਸਮ ਦੀਆਂ ਧੋਖਿਆਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਪਹਿਲਾਂ ਮਾਪਣ ਤੁਹਾਨੂੰ ਉਸ ਚੀਜ਼ ਨੂੰ "ਠੀਕ" ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜੋ ਅਸਲ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ। ਲਿਖਤੀ ਹਿਪੋਥੈਸਿਸ ਤੁਹਾਨੂੰ ਇੱਕੇ ਵਾਰੀ ਵਿੱਚ ਪੰਜ ਗੱਲਾਂ ਬਦਲਣ ਤੋਂ ਰੋਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਅਟਕਲ ਲਾਉਣ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ। ਘੱਟ-ਤੋਂ-ਘੱਟ ਬਦਲਾਅ ਵਿਹਾਰ ਟੁੱਟਣ ਜਾਂ ਨਵੇਂ ਬੋਤਲਨੇਕ ਬਣਨ ਦੇ ਜੋਖਮ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਦੁਬਾਰਾ ਮਾਪਣ ਪਲੇਸੀਬੋ ਜਿੱਤ (ਜਿਵੇਂ ਗਰਮ ਕੈਸ਼ ਕਾਰਨ ਤੇਜ਼ ਦੌੜ) ਨੂੰ ਬੇਨਕਾਬ ਕਰਦਾ ਹੈ ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਨੂੰ ਉਘਾੜਦਾ ਹੈ।
"ਡਨ" ਕੋਈ ਭਾਵਨਾ ਨਹੀਂ। ਇਸ ਨਤੀਜਾ ਹੈ: ਟਾਰਗਿਟ ਮੈਟ੍ਰਿਕ ਸਹੀ ਦਿਸ਼ਾ ਵਿੱਚ ਹਿਲਿਆ, ਅਤੇ ਬਦਲਾਅ ਨੇ ਸਪੱਸ਼ਟ ਰਿਗ੍ਰੈਸ਼ਨ (errors, ਵੱਧ ਮੈਮੋਰੀ, খਰਾਬ p95 latency, ਜਾਂ ਨੇੜਲੇ endpoint ਧੀਮੇ ਹੋਣਾ) ਨਹੀਂ ਉਪਜਾਏ।
ਰੁਕਣਾ ਕਦੋਂ ਹੈ ਇਹ ਜਾਣਣਾ ਵੀ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਹੈ। ਜਦ ਨਫ਼ਾ ਫਲੈਟ ਹੋ ਜਾਵੇ, ਜਦ ਮੈਟ੍ਰਿਕ ਉਪਭੋਗਤਿਆਂ ਲਈ ਕਾਫ਼ੀ ਹੋਵੇ, ਜਾਂ ਜਦ ਅਗਲਾ ਵਿਚਾਰ ਵੱਡੇ ਰੀਫੈਕਟਰ ਲਈ ਛੋਟਾ ਉਪਕਾਰ ਲਿਆ ਰਹੈ ਹੋਵੇ, ਰੁਕ ਜਾਓ। ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਸਦਾ ਮੌਕੇ ਦੀ ਲਾਗਤ ਰੱਖਦਾ ਹੈ; ਲੂਪ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਜਗ੍ਹਾਂ ਤੇ ਸਮਾਂ ਖ਼ਰਚ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਫਾਇਦੇਮੰਦ ਹੋਵੇ।
ਜੇ ਤੁਸੀਂ ਇਕੋ ਵਾਰੀ ਵਿੱਚ ਪੰਜ ਚੀਜ਼ਾਂ ਮਾਪੋਂਗੇ ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਲਗੇਗਾ ਕਿ ਕੀ ਸੁਧਰਿਆ। ਇਸ ਜਾਂਚ ਲਈ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕ ਚੁਣੋ ਅਤੇ ਬਾਕੀ ਨੂੰ ਸਹਾਇਕ ਸੰਕੇਤ ਸਮਝੋ। ਕਈ ਯੂਜ਼ਰ-ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਲਈ ਇਹ ਮੈਟ੍ਰਿਕ latency ਹੁੰਦੀ ਹੈ। ਬੈਚ ਕੰਮ ਲਈ ਇਹ throughput, CPU ਟਾਈਮ, ਮੈਮੋਰੀ ਵਰਤੋਂ, ਜਾਂ ਕਪਰ ਰਣ-ਖਰਚ ਹੋ ਸਕਦਾ ਹੈ।
ਸਨੀਨਾਰਿਓ ਬਹੁਤ ਵਿਸ਼ੇਸ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। "API ਧੀਮਾ ਹੈ" ਬਹੁਤ ਢਿੱਲਾ ਹੈ। "POST /checkout ਇੱਕ ਆਮ ਕਾਰਟ 3 ਆਈਟਮ ਨਾਲ" ਮਾਪ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਨਪੁੱਟ ਨੂੰ ਸਥਿਰ ਰੱਖੋ ਤਾਂ ਜੋ ਨੰਬਰਾਂ ਦੀ ਵਿਆਖਿਆ ਹੋ ਸਕੇ।
ਕੋਡ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ ਬੇਸਲਾਈਨ ਅਤੇ ਵਾਤਾਵਰਣ ਵੇਰਵੇ ਲਿਖੋ: ਡੇਟਾਸੈਟ ਆਕਾਰ, ਮਸ਼ੀਨ ਕਿਸਮ, ਬਿਲਡ ਮੋਡ, ਫੀਚਰ ਫਲੈਗ, ਕਨਕਰੈਂਸੀ, ਅਤੇ ਵਾਰਮਅੱਪ। ਇਹ ਬੇਸਲਾਈਨ ਤੁਹਾਡਾ ਲੰਗਰ ਹੈ। ਇਸ ਦੇ ਬਗੈਰ, ਹਰ ਬਦਲਾਅ ਤਰੱਕੀ ਨਜ਼ਰ ਆ ਸਕਦੀ ਹੈ।
Latency ਲਈ, ਸਿਰਫ ਔਸਤ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ — percentiles 'ਤੇ ਧਿਆਨ ਦਿਓ। p50 ਆਮ ਤਜਰਬਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਦਕਿ p95 ਅਤੇ p99 ਉਨ੍ਹਾਂ ਦਰਦ ਭਰੇ ਟੇਲਾਂ ਨੂੰ ਦਿਖਾਉਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਯੂਜ਼ਰ ਸ਼ਿਕਾਇਤਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਕੋਈ ਬਦਲਾਅ ਜੋ p50 ਨੂੰ ਸੁਧਾਰਦਾ ਪਰ p99 ਨੂੰ ਖਰਾਬ ਕਰਦਾ, ਫੀਲ ਵਿੱਚ ਅਜੇ ਵੀ ਧੀਮਾ ਰਹਿ ਸਕਦਾ ਹੈ।
ਅਰੰਭ ਵਿੱਚ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ "ਮਹੱਤਵਪੂਰਨ" ਦਾ مطلب ਕੀ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸ਼ੋਰ 'ਤੇ ਜਸ਼ਨ ਨਾ ਮਨਾਓ:
ਇਹ ਨਿਯਮ ਇੱਕ ਵਾਰੀ ਸੈਟ ਹੋਣ 'ਤੇ ਤੁਸੀਂ ਬੇਸਲਾਈਨ ਨੂੰ ਹਿਲਾਏ ਬਿਨਾਂ ਵਿਚਾਰਾਂ ਦੀ ਪਰਖ ਕਰ ਸਕਦੇ ਹੋ।
ਸਭ ਤੋਂ ਆਸਾਨ ਅਤੇ ਭਰੋਸੇਯੋਗ ਸੰਕੇਤ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਸਿੰਗਲ ਟਾਈਮਿੰਗ ਦੱਸ ਸਕਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਅਸਲ ਸਮੱਸਿਆ ਹੈ ਅਤੇ ਉਹ ਕਿੰਨੀ ਵੱਡੀ ਹੈ। ਘੇਰੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਨੂੰ صرف ਉਸ ਵੇਲੇ ਸੰਭਾਲੋ ਜਦ ਤੁਹਾਨੂੰ ਦੱਸਣ ਦੀ ਲੋੜ ਹੋ ਕਿ ਕਿਉਂ ਧੀਮਾ ਹੈ।
ਚੰਗਾ ਸਬੂਤ ਆਮ ਤੌਰ 'ਤੇ ਹੇਠਾਂ ਦੇ ਸਰੋਤਾਂ ਦੇ ਮਿਕਸ ਤੋਂ ਆਉਂਦਾ ਹੈ:
ਸਵਾਲ "ਕੀ ਇਹ ਧੀਮਾ ਹੈ ਅਤੇ ਕਿੰਨਾ?" ਲਈ ਸਾਦੇ ਮੈਟ੍ਰਿਕਸ ਵਰਤੋ। ਜਦ ਸਵਾਲ ਹੋਵੇ "ਸਮਾਂ ਕਿੱਥੇ ਲੱਗ ਰਿਹਾ ਹੈ?" ਤਾਂ ਪ੍ਰੋਫਾਈਲਿੰਗ ਵਰਤੋ। ਜੇ deploy ਤੋਂ ਬਾਅਦ p95 latency ਦੁੱਗਣਾ ਹੋ ਗਿਆ, ਤਾਂ ਠੀਕ ਕਰਨ ਲਈ ਪਹਿਲਾਂ ਟਾਇਮਿੰਗ ਅਤੇ ਲੌਗ ਨਾਲ ਰਿਗ੍ਰੈਸ਼ਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਦਾਇਰਾ ਨਿਰਧਾਰਤ ਕਰੋ। ਜੇ ਟਾਇਮਿੰਗ ਦਿਖਾਂਦੀ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਦੇਰੀ ਤੁਹਾਡੇ ਐਪ ਕੋਡ ਵਿੱਚ ਹੈ (ਡੇਟਾਬੇਸ ਨਹੀਂ), ਤਾਂ CPU ਪ੍ਰੋਫਾਈਲਰ ਜਾਂ ਫਲੇਮ ਗ੍ਰਾਫ ਉਸ ਖਾਸ ਫੰਕਸ਼ਨ ਨੂੰ ਦਰਸਾ ਸਕਦਾ ਹੈ ਜੋ ਵਧ ਗਿਆ ਹੈ।
ਮੈਪਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ। ਵਰਤੋ ਉਹ ਡੇਟਾ ਜੋ ਡੀਬੱਗ ਲਈ ਲੋੜੀਂਦਾ ਹੈ, ਨਾਂ ਕਿ ਯੂਜ਼ਰ ਸਮੱਗਰੀ। aggregates (durations, counts, sizes) ਪ੍ਰਫ਼ਰ ਕਰੋ ਅਤੇ identifiers ਨੂੰ ਡਿਥੇਕਟ/ਰੈਡੈਕਟ ਕਰੋ।
ਸ਼ੋਰ ਅਸਲੀ ਹੈ, ਇਸ ਲਈ ਕਈ ਸੈਂਪਲ ਲਓ ਅਤੇ ਆਊਟਲਾਇਰ ਨੋਟ ਕਰੋ। ਇਕੋ ਹੀ ਰਿਕਵੈਸਟ 10 ਤੋਂ 30 ਵਾਰੀ ਚਲਾਓ, ਅਤੇ ਇੱਕ ਚੰਗਾ ਨਤੀਜਾ ਦੇਖਣ ਲਈ ਮੀਡਿਆਨ ਅਤੇ p95 ਦਰਜ ਕਰੋ ਨਾ ਕਿ ਇੱਕ "ਸਭ ਤੋਂ ਵਧੀਆ" ਦੌੜ।
ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਅਪਨੀ ਟੈਸਟ ਰੇਸੀਪੀ ਲਿਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਦੁਹਰਾ ਸਕੋ: ਵਾਤਾਵਰਣ, ਡੇਟਾਸੈਟ, ਐਂਡਪੌਇੰਟ, ਰਿਕਵੇਸਟ ਬਾਡੀ ਆਕਾਰ, ਕਨਕਰੈਂਸੀ ਪੱਧਰ ਅਤੇ ਤੁਸੀਂ ਨਤੀਜੇ ਕਿਵੇਂ ਕੈਪਚਰ ਕੀਤੇ।
ਲੱਛਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਤੁਸੀਂ ਨਾਮ ਦੇ ਸਕਦੇ ਹੋ: "p95 latency traffic peaks ਦੌਰਾਨ 220 ms ਤੋਂ 900 ms ਹੋ ਜਾਂਦੀ ਹੈ," "CPU ਦੋ ਕੋਰਾਂ 'ਤੇ 95% ਰੁਕ ਜਾਂਦੀ ਹੈ," ਜਾਂ "ਮੈਮੋਰੀ ਪ੍ਰਤੀ ਘੰਟੇ 200 MB ਵੱਧਦੀ ਹੈ।" ਢਿੱਲੇ ਲੱਛਣ ਜਿਵੇਂ "ਇਹ ਧੀਮਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ" ਅਟਕਲਾਂ ਨੂੰ ਜਨਮ ਦਿੰਦੇ ਹਨ।
ਫਿਰ, ਜੋ ਤੁਸੀਂ ਮਾਪਿਆ ਹੈ ਉਸਨੂੰ ਇੱਕ ਸ਼ੱਕੀ ਖੇਤਰ ਵਿੱਚ ਤਰਜਮਾ ਕਰੋ। ਇਕ ਫਲੇਮ ਗ੍ਰਾਫ ਅਕਸਰ ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ JSON encoding ਵਿੱਚ ਹੈ, ਇੱਕ ਟ੍ਰੇਸ ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿ ਇੱਕ ਦੇਰੀ ਕਰਦੀ ਕਾਲ ਪਾਥ ਹੈ, ਜਾਂ ਡੇਟਾਬੇਸ ਸਟੈਟਸ ਦਿਖਾ ਸਕਦੇ ਹਨ ਕਿ ਇੱਕ ਕਵੈਰੀ ਕੁੱਲ ਸਮਾਂ 'ਚ ਵੱਡਾ ਹਿੱਸਾ ਲੈ ਰਹੀ ਹੈ। ਉਸ ਛੋਟੀ ਜਿਹੀ ਜਗ੍ਹਾ ਨੂੰ ਚੁਣੋ ਜੋ ਜ਼ਿਆਦਾ ਲਾਗਤ ਦੱਸਦੀ ਹੈ: ਇੱਕ ਫੰਕਸ਼ਨ, ਇੱਕ SQL ਕਵੈਰੀ, ਜਾਂ ਇੱਕ ਬਾਹਰੀ ਕਾਲ।
ਇੱਕ ਚੰਗੀ ਹਿਪੋਥੈਸਿਸ ਇਕ ਵਾਕੀ ਹੋਵੇ, ਟੈਸਟ ਕਰਨਯੋਗ ਹੋਵੇ, ਅਤੇ ਇਕ ਪੇਸ਼ਗੀ ਅਨੁਮਾਨ ਨਾਲ ਜੁੜੀ ਹੋਵੇ। ਤੁਸੀਂ ਮਦਦ ਮੰਗ ਰਹੇ ਹੋ ਕਿ ਇਕ ਵਿਚਾਰ ਦੀ ਜਾਂਚ ਹੋਵੇ — ਨਾ ਕਿ ਕਿੱਤਾ ਤੋਂ ਸਭ ਕੁਝ ਤੇਜ਼ ਹੋ ਜਾਵੇ।
ਇਸ ਫਾਰਮੈਟ ਦੀ ਵਰਤੋਂ ਕਰੋ:
ਉਦਾਹਰਨ: "ਕਿਉਂਕਿ ਪ੍ਰੋਫਾਇਲ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ CPU ਦਾ 38% SerializeResponse ਵਿੱਚ ਜਾ ਰਿਹਾ ਹੈ, ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ ਨਵਾਂ ਬਫਰ ਐਲੋਕੇਟ ਕਰਨਾ CPU ਸਪਾਈਕ ਕਰਵਾ ਰਿਹਾ ਹੈ। ਜੇ ਅਸੀਂ ਬਫਰ ਦੁਬਾਰਾ ਵਰਤਾਂਗੇ, ਤਾਂ p95 latency ~10-20% ਘਟਣਾ ਚਾਹੀਦਾ ਅਤੇ CPU ਲੋਡ 15% ਘਟਣਾ ਚਾਹੀਦਾ।"
ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਵਿਕਲਪਾਂ ਨੂੰ ਨਾਮ ਦੇ ਕੇ ਆਪਣੇ ਆਪ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖੋ। ਸ਼ਾਇਦ ਧੀਮਾ ਹਿੱਸਾ ਅਸਲ ਵਿੱਚ upstream dependency, lock contention, cache miss rate ਦਾ ਬਦਲਾਅ, ਜਾਂ rollout ਨੇ payload ਆਕਾਰ ਵਧਾ ਦਿੱਤਾ ਹੋਵੇ।
2-3 ਵਿਕਲਪੀਆਂ ਵਜੋਂ ਲਿਖੋ, ਫਿਰ ਉਹ ਚੁਣੋ ਜਿਸਨੂੰ ਤੁਹਾਡੇ ਸਬੂਤ ਸਭ ਤੋਂ ਵਧੀਆ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਬਦਲਾਅ ਮੈਟ੍ਰਿਕ ਨੂੰ ਹਿਲਾਉਂਦਾ ਨਹੀਂ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਅਗਲੀ ਹਿਪੋਥੈਸਿਸ ਤਿਆਰ ਹੋਵੇਗੀ।
Claude ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਲਾਭਕਾਰਕ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਸਾਵਧਾਨ ਵਿਸ਼ਲੇਸ਼ਕ ਵਾਂਗ ਵਰਤਦੇ ਹੋ, ਨਾ ਕਿ ਇੱਕ ਓਰੈਕਲ। ਹਰ ਸੁਝਾਅ ਨੂੰ ਜੋ ਤੁਸੀਂ ਮੰਗਦੇ ਹੋ ਉਹ ਮਾਪੇ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹਰ ਕਦਮ ਨੂੰ ਗਲਤ ਸਾਬਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਇਸਨੂੰ vague ਵਰਣਨ ਨਾ ਦਿਓ—ਅਸਲ ਇਨਪੁੱਟ ਦਿਓ। ਛੋਟਾ, ਧਿਆਨ ਕੇਂਦਰਿਤ ਸਬੂਤ ਪੇਸਟ ਕਰੋ: ਇੱਕ ਪ੍ਰੋਫਾਈਲਿੰਗ ਸੰਖੇਪ, ਕੁਝ ਲੌਗ ਲਾਈਨਾਂ ਸਲੋਂ, ਇੱਕ ਕਵੈਰੀ ਯੋਜਨਾ, ਅਤੇ ਖਾਸ ਕੋਡ ਪਾਥ। "ਪਹਿਲਾਂ" ਨੰਬਰ (p95 latency, CPU time, DB time) ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਤੁਹਾਡਾ ਬੇਸਲਾਈਨ ਜਾਣ ਸਕੇ।
ਇਸਨੂੰ ਪੁੱਛੋ ਕਿ ਡੇਟਾ ਕੀ ਦਸਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ। ਫਿਰ ਮੁਕਾਬਲੇ ਸਿਰਫ 2-3 ਹਿਪੋਥੈਸਿਸ ਮੰਗੋ ਅਤੇ ਹਰ ਇਕ ਲਈ ਕੀ ਗਲਤ ਸਾਬਤ ਕਰੇਗਾ ਉਹ ਪੁੱਛੋ। ਇੱਕ ਵਧੀਆ ਪ੍ਰੰਪਟ ਅਖੀਰ 'ਤੇ ਲਿਖਿਆ ਹੋਵੇ: "ਮੈਨੂੰ 2-3 ਹਿਪੋਥੈਸਿਸ ਦਿਓ, ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਦੱਸੋ ਕੀ ਉਹ ਨੂੰ ਫਾਲਸਿਫਾਈ ਕਰੇਗਾ।" ਇਹ ਪਹਿਲੀ ਮੰਨਣਯੋਗ ਕਹਾਣੀ 'ਤੇ ਫਸਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਕੋਈ ਵੀ ਕੋਡ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ, ਸਭ ਤੋਂ ਛੋਟੀ ਜਾਂਚ ਮੰਗੋ ਜੋ ਪ੍ਰਮੁੱਖ ਹਿਪੋਥੈਸਿਸ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰੇ: ਇੱਕ ਫੰਕਸ਼ਨ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਇੱਕ ਟਾਈਮਰ ਜੋੜੋ, ਇੱਕ ਪ੍ਰੋਫਾਈਲਰ ਫਲੈਗ ਐਨੇਬਲ ਕਰੋ, ਜਾਂ ਇੱਕ ਡੀਬੀ ਕਵੈਰੀ EXPLAIN ਨਾਲ ਚਲਾਓ।
ਜੇ ਤੁਸੀਂ ਨਿਰਧਾਰਤ ਫ਼ਾਰਮੈਟ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਪੁੱਛੋ:
ਜੇ ਇਹ ਨਿਰਧਾਰਤ ਮੈਟ੍ਰਿਕ, ਥਾਂ ਅਤੇ ਉਮੀਦਸ਼ੁਦਾ ਨਤੀਜੇ ਨਹੀਂ ਦੱਸ ਸਕਦਾ, ਤਾਂ ਤੁਸੀਂ ਫਿਰ ਵਾਪਸ ਅਟਕਲਾਂ ਵਾਲੇ ਰਾਹ ਤੇ ਹੋ।
ਸਬੂਤ ਅਤੇ ਹਿਪੋਥੈਸਿਸ ਹੋਣ ਤੋਂ ਬਾਅਦ, "ਸਭ ਕੁਝ ਸਾਫ਼" ਕਰਨ ਦੀ ਲਾਲਚ ਨੂੰ ਰੋਕੋ। ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਲਈ ਕੋਡ ਬਦਲਾਅ ਛੋਟੇ ਅਤੇ ਆਸਾਨ ਵਾਪਸ ਕਰਨਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਚੀਜ਼ ਬਦਲੋ। ਜੇ ਤੁਸੀਂ ਇੱਕੋ ਕਮਿੱਟ ਵਿੱਚ ਕਵੈਰੀ ਸਮੀਕਰਨ, caching ਅਤੇ ਲੂਪ ਰੀਫੈਕਟਰ ਕਰ ਦਿਓਗੇ ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ ਕਿ ਕੀ ਸਹੀ ਕੀਤਾ। ਇਕੱਲੇ-ਫੈਕਟਰ ਬਦਲਾਅ ਅਗਲੇ ਮਾਪਣ ਨੂੰ ਮਾਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਕੋਡ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ ਉਮੀਦ ਕੀ ਲਿਖੋ: ਉਦਾਹਰਨ: "p95 latency 420 ms ਤੋਂ ਘਟ ਕੇ 300 ms ਤੋਂ ਥੱਲੇ ਹੋ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ DB ਸਮਾਂ ਲਗਭਗ 100 ms ਘਟਣਾ ਚਾਹੀਦਾ ਹੈ।" ਜੇ ਨਤੀਜਾ ਇਸ ਟੀਚੇ ਤੱਕ ਨਹੀਂ ਪੁੱਜਦਾ, ਤਾਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਹੀ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ ਕਿ ਹਿਪੋਥੈਸਿਸ ਕਮਜ਼ੋਰ ਸੀ।
ਬਦਲਾਅ ਵਾਪਸੀਯੋਗ ਰੱਖੋ:
"ਘੱਟ" ਦਾ ਮਤਲਬ "ਛੋਟਾ" ਨਹੀਂ, ਇਸਦਾ ਅਰਥ ਹੈ ਫੋਕਸ: ਇੱਕ ਮਹਿੰਗੇ ਫੰਕਸ਼ਨ ਲਈ cached result, ਇੱਕ ਤੰਗ ਲੂਪ ਵਿੱਚ ਇੱਕ ਵਾਰ-ਵਾਰ ਐਲੋਕੇਸ਼ਨ ਹਟਾਉਣਾ, ਜਾਂ ਉਹ ਕੰਮ ਰੋਕਣਾ ਜੋ ਕੁਝ ਰਿਕਵੈਸਟਾਂ ਲਈ ਲੋੜੀਂਦਾ ਨਹੀਂ।
ਉਸ ਸ਼ੱਕੀ ਹਿੱਸੇ 'ਤੇ ਹਲਕੀ ਟਾਈਮਿੰਗ ਜੋੜੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕੋ ਕਿ ਤੁਹਾਡਾ ਬਦਲਾਅ ਸੱਚਮੁੱਚ ਬੋਤਲਨੇਕ 'ਤੇ ਅਸਰ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਸਮਾਂ ਕਿਤੇ ਹੋਰ ਨੂੰ ਸਥਾਣਾਂਤਰਤ ਹੋ ਗਿਆ। ਇੱਕ ਸਿੰਗਲ ਟਾਈਮਸਟੈਂਪ ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਦ ਵਿੱਚ (ਲੌਗ ਕੀਤਾ ਹੋਇਆ ਜਾਂ ਮੈਟ੍ਰਿਕ ਵਜੋਂ) ਪੁਸ਼ਟੀ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਹੀ ਜਗ੍ਹਾ 'ਤੇ ਹਿੱਸਾ ਲਿਆ।
ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ, ਬੇਸਲਾਈਨ ਲਈ ਵਰਤੇ ਗਏ ਇਕੋ ਹੀ ਸਨੀਨਾਰਿਓ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਓ: ਇਕੋ ਇਨਪੁੱਟ, ਵਾਤਾਵਰਣ, ਅਤੇ ਲੋਡ ਸ਼ੇਪ। ਜੇ ਤੁਹਾਡਾ ਟੈਸਟ ਕੈਸ਼/ਵਾਰਮਅੱਪ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਇਹ ਸਪਸ਼ਟ ਰੱਖੋ (ਉਦਾਹਰਨ: "ਪਹਿਲੀ ਦੌੜ ਠੰਢੀ, ਅਗਲੀ 5 ਦੌੜ ਗਰਮ")। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਐਸੇ ਸੁਧਾਰ ਲੱਭੋਗੇ ਜੋ ਅਸਲ ਵਿੱਚ ਵਕਫ-ਕਿਸਮਤ ਹੋਣਗੇ।
ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਵੇਲੇ ਇਕੋ ਮੈਟ੍ਰਿਕ ਅਤੇ ਇਕੋ percentiles ਵਰਤੋ। ਔਸਤ ਦਰਦ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ p95 ਅਤੇ p99 latency, ਨਾਲ ਹੀ throughput ਅਤੇ CPU ਟਾਈਮ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ। ਨੰਬਰਾਂ ਸਥਿਰ ਹੋਣ ਤੱਕ ਕਾਫੀ ਦੌੜ ਰਨ ਕਰੋ।
ਜਸ਼ਨ ਮਨਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਰਿਗ੍ਰੈਸ਼ਨ ਵੀ ਚੈੱਕ ਕਰੋ ਜੋ ਇਕ ਸਿਰਲੇਖ ਨੰਬਰ ਵਿੱਚ ਨਹੀਂ ਦਿਖਦੇ:
ਫਿਰ ਸਬੂਤ ਦੇ ਆਧਾਰ 'ਤੇ ਫੈਸਲਾ ਕਰੋ, ਨਾਂ ਕਿ ਆਸ ਤੇ। ਜੇ ਸੁਧਾਰ ਅਸਲ ਹੈ ਅਤੇ ਤੁਸੀਂ ਰਿਗ੍ਰੈਸ਼ਨ ਨਹੀਂ ਲਿਆਂਦੇ, ਤਾਂ ਫਿਕਸ ਰੱਖੋ। ਜੇ ਨਤੀਜੇ ਮਿਲੇ-ਜੁਲੇ ਜਾਂ ਸ਼ੋਰ ਵਾਲੇ ਹਨ, ਤਾਂ revert ਕਰੋ ਅਤੇ ਨਵੀਂ ਹਿਪੋਥੈਸਿਸ ਬਣਾਓ ਜਾਂ ਬਦਲਾਅ ਨੂੰ ਹੋਰ ਅਲੱਗ ਕਰੋ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਦ ਇੱਕ ਸਨੇਪਸ਼ੌਟ ਲੈ ਕੇ ਪ੍ਰਯੋਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ rollback ਇੱਕ ਕਦਮ ਬਣ ਸਕਦਾ ਹੈ, ਜੋ ਬੋਲਡ ਵਿਚਾਰਾਂ ਦੀ ਸੁਰੱਖਿਅਤ ਜਾਂਚ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਅਖ਼ਿਰਕਾਰ, ਜੋ ਤੁਹਾਨੂੰ ਸਿੱਖਿਆ ਉਸਨੂੰ ਲਿਖੋ: ਬੇਸਲਾਈਨ, ਬਦਲਾਅ, ਨਵੇਂ ਨੰਬਰ, ਅਤੇ ਨਤੀਜਾ। ਇਹ ਛੋਟੀ ਰਿਕਾਰਡ ਅਗਲੇ ਚੱਕਰ ਨੂੰ انہੀ ਮਿਰਾੜਾ ਨਾਲ ਦੁਹਰਾਉਣ ਤੋਂ بچਾਉਂਦਾ ਹੈ।
ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਉਹਸ ਵੇਲੇ ਬਾਹਰ ਚਲਾ ਜਾਂਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਜੋ ਮਾਪਿਆ ਉਸ ਅਤੇ ਜੋ ਬਦਲਿਆ ਉਸ ਵਿਚਕਾਰ ਲੜੀ ਗੁਆ ਬੈਠਦੇ ਹੋ। ਸਾਫ਼ ਸਬੂਤ ਦੀ ਲੜੀ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਇਹ ਪੱਕਾ ਕਹਿ ਸਕੋ ਕਿ ਕੀ ਚੀਜ਼ ਚੰਗੀ ਕੀਤੀ।
ਰੀਪਟੀਟਰ:
ਛੋਟੀ ਉਦਾਹਰਨ: ਇੱਕ ਐਂਡਪੌਇੰਟ ਕਮਜ਼ੋਰ ਲੱਗਦਾ ਹੈ, ਸੋ ਤੁਸੀਂ serializer ਟਿਊਨ ਕਰਦੇ ਹੋ ਕਿਉਂਕਿ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਉਹ ਹਾਟ ਸੀ। ਫਿਰ ਤੁਸੀਂ ਛੋਟੇ ਡੇਟਾਸੈਟ ਨਾਲ ਪੁਨਰਪਰਖ ਕਰਦੇ ਹੋ ਅਤੇ ਇਹ ਤੇਜ਼ ਲੱਗਦਾ ਹੈ। ਪ੍ਰੋਡ ਵਿੱਚ p99 ਖਰਾਬ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਅਜੇ ਵੀ ਬੋਤਲਨੇਕ ਸੀ ਅਤੇ ਤੁਹਾਡੇ ਬਦਲਾਅ ਨੇ payload ਆਕਾਰ ਵਧਾ ਦਿੱਤਾ।
ਜੇ ਤੁਸੀਂ Claude Code ਨੂੰ fix ਸੁਝਾਉਣ ਲਈ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ ਘੁੰਮਾਓ-ਫੇਰਾਓ ਉੱਤੇ ਰੱਖੋ। 1-2 ਘੱਟ ਬਦਲਾਅ ਮੰਗੋ ਜੋ ਤੁਹਾਡੇ ਸਬੂਤ ਨਾਲ ਮਿਲਦੇ ਹੋਣ, ਅਤੇ ਪ੍ਰਤੀ ਬਦਲਾਅ ਦੁਬਾਰਾ ਮਾਪڻ ਦੀ ਯੋਜਨਾ ਮੰਗੋ।
ਸਪੀਡ ਦਾਵੇ ਟੈਸਟ ਫਜ਼ੀ ਹੋਣ 'ਤੇ ਠੁੱਕ ਜਾਂਦੇ ਹਨ। ਜਸ਼ਨ ਮਨਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਕਿੱਦਾ ਮਾਪਿਆ, ਕਿਵੇਂ ਮਾਪਿਆ, ਅਤੇ ਕੀ ਬਦਲਿਆ, ਇਹ ਸਮਝਾ ਸਕਦੇ ਹੋ।
ਪਹਿਲਾਂ ਇੱਕ ਮੈਟ੍ਰਿਕ ਨਾਮ ਲਓ ਅਤੇ ਬੇਸਲਾਈਨ ਨਤੀਜਾ ਲਿਖੋ। ਉਹ ਵੇਰਵੇ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਨੰਬਰ ਬਦਲ ਸਕਦੇ ਹਨ: ਮਸ਼ੀਨ ਕਿਸਮ, CPU ਲੋਡ, ਡੇਟਾਸੈਟ ਆਕਾਰ, ਬਿਲਡ ਮੋਡ (debug vs release), ਫੀਚਰ ਫਲੈਗ, ਕੈਸ਼ ਸਥਿਤੀ, ਅਤੇ ਕਨਕਰੈਂਸੀ। ਜੇ ਤੁਸੀਂ ਕੱਲ੍ਹ ਉਹ ਸੈੱਟਅੱਪ ਦੁਹਰਾਉ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਬੇਸਲਾਈਨ ਨਹੀਂ ਹੈ।
ਚੈੱਕਲਿਸਟ:
ਨੰਬਰਾਂ ਚੰਗੇ ਹੋਣ 'ਤੇ ਤੇਜ਼ ਰਿਗ੍ਰੈਸ਼ਨ ਪਾਸ ਕਰੋ: ਸਹੀਤਾ, ਚੁੱਕਤ ਦਰ, ਅਤੇ ਟਾਈਮਆਊਟ ਜਾਂ payload/ਰਿਸੋਰਸ ਪ੍ਰਭਾਵਾਂ ਤੇ ਨਜ਼ਰ ਰੱਖੋ। p95 latency ਸੁਧਰਦੇ ਹੋਏ ਦੂਜੇ ਖਰਾਬ ਪ੍ਰਭਾਵ (ਜਿਵੇਂ ਦੂਗੁਣਾ ਮੈਮੋਰੀ) ਇੱਕ ਗਲਤ ਵਪਾਰ ਹੋ ਸਕਦੇ ਹਨ।
ਇੱਕ ਟੀਮ ਦੱਸਦੀ ਹੈ ਕਿ GET /orders dev ਵਿੱਚ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਪਰ ਸਟੇਜਿੰਗ ਵਿੱਚ ਮੋਡਰੇਟ ਲੋਡ 'ਤੇ ਧੀਮਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਯੂਜ਼ਰ ਟਾਈਮਆਊਟ ਦੀ ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ, ਪਰ ਔਸਤ ਲੈਟੈਂਸੀ ਅਜੇ ਵੀ "ਠੀਕ" ਲੱਗਦੀ ਹੈ — ਇੱਕ ਆਮ ਫੰਦ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਬੇਸਲਾਈਨ ਸੈੱਟ ਕਰੋ। ਇੱਕ steady load test ਹੇਠਾਂ (ਇਕੋ ਡੇਟਾਸੈਟ, ਇਕੋ ਕਨਕਰੈਂਸੀ, ਇਕੋ ਅਵਧੀ) ඔබ ਦਰਜ ਕਰਦੇ ਹੋ:
ਹੁਣ ਸਬੂਤ ਇਕੱਤਰ ਕਰੋ। ਇੱਕ ਤੇਜ਼ ਟ੍ਰੇਸ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਐਂਡਪੌਇੰਟ ਇੱਕ ਮੁੱਖ ਕਵੈਰੀ ਚਲਾਂਦਾ ਹੈ, ਫਿਰ orders ਪ੍ਰਤੀ ਆਈਟਮ ਲਈ related items ਫੈਚ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇਹ ਵੀ ਦੇਖਦੇ ਹੋ ਕਿ JSON response ਵੱਡਾ ਹੈ, ਪਰ DB ਸਮਾਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤੌਰ 'ਤੇ ਵੱਡਾ ਹੈ।
ਹੁਣ ਇਹਨੂੰ ਟੈਸਟ ਕਰਨ ਯੋਗ ਹਿਪੋਥੈਸਿਸ ਲਿਸਟ ਵਿੱਚ ਬਦਲੋ:
ਸਬ ਤੋਂ ਮਜ਼ਬੂਤ ਸਬੂਤ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਘੱਟੋ-ਘੱਟ ਤਬਦੀਲੀ ਮੰਗੋ: N+1 ਕਾਲ ਨੂੰ ਹਟਾਣ ਲਈ related items ਨੂੰ single query ਵਿੱਚ order IDs ਨਾਲ ਲਿਆਓ (ਜਾਂ ਜੇ slow query plan full scan ਦਿਖਾ ਰਿਹਾ ਹੈ ਤਾਂ ਗੁੰਭੀਰ index ਜੋੜੋ). ਇਸਨੂੰ reversible ਅਤੇ focused commit ਰੱਖੋ।
ਉਸੇ ਲੋਡ ਟੈਸਟ ਨਾਲ ਦੁਬਾਰਾ ਮਾਪੋ। ਨਤੀਜੇ:
ਫੈਸਲਾ: ਫਿਕਸ ਸ਼ਿਪ ਕਰੋ (ਸਾਫ਼ ਜਿੱਤ), ਫਿਰ ਬਾਕੀ ਗੈਪ ਅਤੇ CPU spikes 'ਤੇ ਦੂਜਾ ਚੱਕਰ ਚਲਾਓ ਕਿਉਂਕਿ ਹੁਣ DB ਮੁੱਖ ਰੁਕਾਵਟ ਨਹੀਂ ਰਹੀ।
ਪ੍ਰਦਰਸ਼ਨ ਜਾਂਚ ਵਿੱਚ ਤੇਜ਼ੀ ਲਿਆਉਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਹਰ ਦੌੜ ਨੂੰ ਇੱਕ ਛੋਟੇ ਐਕਸਪੇਰੀਮੈਂਟ ਵਾਂਗ ਟ੍ਰੀਟ ਕਰਨਾ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਉ ਸਕੋ। ਜਦ ਪ੍ਰਕਿਰਿਆ ਇੱਕਸਾਰ ਹੋ ਜਾਦੀ ਹੈ, ਨਤੀਜੇ ਭਰੋਸੇਯੋਗ, ਤੁਲਨਾਤਮਕ ਅਤੇ ਸਾਂਝੇ ਯੋਗ ਬਣ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਣ ਇੱਕ-ਪੇਜ਼ ਟੈਂਪਲੇਟ ਮਦਦਗਾਰ ਹੈ:
ਇਹ ਨੋਟਸ ਕਿਸ ਥਾਂ ਰੱਖਣੇ ਹਨ ਇਹ ਫ਼ੈਸਲਾ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਗੁੰਮ ਨਾ ਹੋਣ: ਸਰਵਿਸ ਦੇ ਕੋਲ ਇੱਕ repo ਫੋਲਡਰ, ਟੀਮ ਡੌਕ, ਜਾਂ ਟਿਕਟ ਨੋਟਸ। ਖ਼ਾਸ ਗੱਲ ਹੈ ਖੋਜਯੋਗਤਾ। ਕਿਸੇ ਨੂੰ ਬਾਦ ਵਿੱਚ "p95 latency spike after caching change" ਮਹੀਨਿਆਂ ਬਾਅਦ ਵੀ ਲੱਭ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸੁਰੱਖਿਅਤ ਪ੍ਰਯੋਗ ਆਦਤ ਬਣਾਓ। snapshots ਅਤੇ ਆਸਾਨ rollback ਵਰਤੋਂ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਕ ਆਈਡੀਆ ਬਿਨਾਂ ਡਰ ਦੇ ਟੈਸਟ ਕਰ ਸਕੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, Planning Mode ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਜਗ੍ਹਾ ਹੋ ਸਕਦੀ ਹੈ ਮਾਪਣ ਯੋਜਨਾ ਲਿਖਣ, ਹਿਪੋਥੈਸਿਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ, ਅਤੇ ਬਦਲਾਅ ਨੂੰ ਸੀਮਿਤ ਰੱਖਣ ਲਈ ਪਹਿਲਾਂ ਤੋਂ।
ਕੈਡੈਂਸ ਸੈੱਟ ਕਰੋ। ਘਟਨਾਵਾਂ ਦੀ ਉਡੀਕ ਨਾ ਕਰੋ। ਛੋਟੇ ਪ੍ਰਦਰਸ਼ਨ ਚੈੱਕ ਜੋੜੋ ਜਿਵੇਂ ਨਵੀਂ ਕਵੈਰੀ, ਨਵਾਂ ਐਂਡਪੌਇੰਟ, ਵੱਡਾ payload, ਜਾਂ dependency ਅਪਗਰੇਡ — 10 ਮਿੰਟ ਦਾ ਬੇਸਲਾਈਨ ਚੈੱਕ ਅੱਜ ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਦਿਨ ਦੇ ਅਟਕਲ-ਛਾਨਬੀਨ ਨੂੰ ਬਚਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਨੰਬਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸ਼ਿਕਾਇਤ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ — ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਖਾਸ ਐਂਡਪੌਇੰਟ ਅਤੇ ਇਨਪੁੱਟ ਲਈ p95 latency। ਇਕੋ ਹੀ ਸ਼ਰਤਾਂ ਹੇਠਾਂ (ਡਾਟਾ ਸਾਈਜ਼, ਕਨਕਰੈਂਸੀ, ਠੰਢਾ/ਗਰਮ ਕੈਸ਼) ਬੇਸਲਾਈਨ ਦਰਜ ਕਰੋ, ਫਿਰ ਇੱਕ ਚੀਜ਼ ਬਦਲੋ ਤੇ ਦੁਬਾਰਾ ਮਾਪੋ。
ਜੇ ਤੁਸੀਂ ਬੇਸਲਾਈਨ ਦੁਹਰਾਉ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਜੇ ਮਾਪ ਨਹੀਂ ਰਹੇ — ਤੁਸੀਂ ਅਟਕਲ ਲਗਾ ਰਹੇ ਹੋ.
ਇੱਕ ਚੰਗੀ ਬੇਸਲਾਈਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੇ:
ਇਸਨੂੰ ਕੋਡ ਨੂੰ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਗੋਲਪੋਸਟ ਨੂੰ ਹਿਲਾਉ ਨਾ ਕਰੋ।
ਪ੍ਰਤੀਸ਼ਤਾਂ (percentiles) ਔਸਤ (average) ਨਾਲੋਂ ਯੂਜ਼ਰ ਦੇ ਤਜਰਬੇ ਨੂੰ ਵਧੀਆ ਦਿਖਾਉਂਦੀਆਂ ਹਨ। p50 ਆਮ ਤਜਰਬਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਯੂਜ਼ਰ ਅਕਸਰ ਬੁਰੀ ਟੇਲ (ਉਦਾਹਰਨ ਲਈ p95/p99) ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ。
ਜੇ p50 ਸੁਧਰਦਾ ਹੈ ਪਰ p99 ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਫੀਲ ਕਰਨ ਵਿੱਚ ਧੀਮਾ ਹੋ ਸਕਦਾ ਹੈ ਭਾਵੇਂ ਔਸਤ ਚੰਗਾ ਲੱਗੇ।
ਸਾਦਾ ਟਾਇਮਿੰਗ/ਲੌਗ ਇਸ ਵਕਤ ਵਰਤੋ ਜਦ ਸਵਾਲ ਹੋਵੇ "ਕੀ ਇਹ ਧੀਮਾ ਹੈ ਅਤੇ ਕਿੰਨਾ ਹੈ?" ਪ੍ਰੋਫਾਈਲਿੰਗ ਉਸ ਵੇਲੇ ਵਰਤੋ ਜਦ ਸਵਾਲ ਹੋਵੇ "ਸਮਾਂ ਕਿੱਥੇ ਲੱਗ ਰਿਹਾ ਹੈ?"
ਵਿਆਵਹਾਰਿਕ ਤਰਤੀਬ: ਪਹਿਲਾਂ ਰਿਕਵੇਸਟ ਟਾਇਮਿੰਗ ਨਾਲ ਰਿਗ੍ਰੈਸ਼ਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਹੀ ਜਦ ਤੁਸੀਂ ਜਾਣ ਲਓ ਕਿ ਮੁੱਦਾ ਹਕੀਕਤ ਹੈ ਅਤੇ ਦਾਇਰਾ ਸਪਸ਼ਟ ਹੈ ਤਾਂ ਪ੍ਰੋਫਾਈਲ ਕਰੋ।
ਇੱਕ ਵਾਰੀ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਮਾਪ ਕੇ ਗੁੰਝਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕ ਚੁਨੋ ਅਤੇ ਬਾਕੀ ਨੂੰ ਗਾਰਡਰੇਲ ਸਮਝੋ। ਆਮ ਤੌਰ ਤੇ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਇਕ ਚਾਰਟ 'ਚ ਜਿੱਤ ਕੇ ਦੂਜੇ ਸਿਸਟਮ ਨੂੰ ਖਰਾਬ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋਵੋਗੇ।
ਇੱਕ-ਵਾਕੀ ਹਿਪੋਥੈਸਿਸ ਲਿਖੋ ਜੋ ਸਬੂਤ ਨਾਲ ਜੁੜੀ ਹੋਵੇ ਅਤੇ ਪੇਸ਼ਗੀ ਅਨੁਮਾਨ ਰੱਖਦੀ ਹੋਵੇ:
ਜੇ ਤੁਸੀਂ ਸਬੂਤ ਅਤੇ ਉਮੀਦਸ਼ੁਦਾ ਮੈਟ੍ਰਿਕ ਨੂੰ ਨਹੀਂ ਨਾਂਬ ਸਕਦੇ, ਤਾਂ ਹਿਪੋਥੈਸਿਸ ਟੈਸਟ ਕਰਨਯੋਗ ਨਹੀਂ ਹੈ।
ਇਹਨਾ ਨਿਯਮਾਂ 'ਤੇ ਅਮਲ ਕਰੋ:
ਛੋਟਾ ਦਿਫਾਅ ਅਸਲ ਵਿੱਚ ਫੋਕਸ ਕੀਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਇਕ ਮਹਿੰਗਾ ਫੰਕਸ਼ਨ ਰਿਜਲਟ ਨੂੰ ਕੈਸ਼ ਕਰੋ, ਇੱਕ ਕੜੀ ਲੂਪ ਤੋਂ ਵਾਰ-ਵਾਰ ਐਲੋਕੇਸ਼ਨ ਹਟਾਓ, ਜਾਂ ਉਹ ਕੰਮ ਰੋਕੋ ਜੋ ਕੁਝ ਰਿਕਵੈਸਟਾਂ ਲਈ ਲੋੜੀਂਦਾ ਨਹੀਂ।
ਤਬਦੀਲੀ ਤੋਂ ਬਾਦ ਓਹੀ ਸਨੀਨਾਰਿਓ ਦੁਹਰਾ ਕੇ ਮਾਪੋ ਜੋ ਬੇਸਲਾਈਨ ਲਈ ਵਰਤੀ ਸੀ: ਇਕੋ ਇਨਪੁੱਟ, ਵਾਤਾਵਰਣ, ਅਤੇ ਲੋਡ ਸ਼ੇਪ। ਜੇ ਤੁਹਾਡਾ ਟੈਸਟ ਕੈਸ਼/ਵਾਰਮਅੱਪ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਉਹ ਸਪਸ਼ਟ ਕਰੋ (ਉਦਾਹਰਨ: "ਪਹਿਲੀ ਦੌੜ ਠੰਢੀ, ਅਗਲੀ 5 ਦੌੜ ਗਰਮ").
ਛੋਟੇ-ਛੋਟੇ ਨਤੀਜੇ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਚੀਜ਼ਾਂ ਵੀ ਚੈੱਕ ਕਰੋ:
ਜੇ ਸੁਧਾਰ ਅਸਲੀ ਹੈ ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਨਹੀਂ ਆਈ, ਤਦ ਇਹ ਫਿਕਸ ਰੱਖੋ। ਨਈਂ ਤਾਂ ਰਿਵਰਟ ਕਰੋ ਅਤੇ ਨਵੀਂ ਹਿਪੋਥੈਸਿਸ ਤੇ ਆਗੇ ਵੱਧੋ।
ਅਕਸਰ ਗਲਤੀਆਂ ਜਦ ਹੋਂਦੀਆਂ ਹਨ ਜਦ ਤੁਸੀਂ ਜੋ ਮਾਪਿਆ ਉਸ ਅਤੇ ਜੋ ਬਦਲਿਆ ਉਸ ਦੇ ਵਿਚਕਾਰ ਧਾਗਾ ਖੋ ਦਿੰਦੇ ਹੋ। ਸਪੱਸ਼ਟ ਸਬੂਤ ਦੀ ਲੜੀ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕਹਿ ਸਕੋ ਕਿ ਕਿਸ ਨੇ ਸੁਧਾਰ ਕੀਤਾ ਜਾਂ ਖਰਾਬ ਕੀਤਾ।
ਆਮ ਗਲਤੀਆਂ:
ਜੇ ਤੁਸੀਂ Claude Code ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਤਾਂ ਉਸ ਨੂੰ ਇੱਕ ਸਾਵਧਾਨ ਵਿਸ਼ਲੇਸ਼ਕ ਵਾਂਗ ਵਰਤੋ: 1-2 ਘੱਟ ਬਦਲਾਅ ਮੰਗੋ ਜੋ ਤੁਹਾਡੇ ਸબੂਤ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹੋ ਅਤੇ ਹਮੇਸ਼ਾ ਦੁਬਾਰਾ ਮਾਪਣ ਦੀ ਯੋਜਨਾ ਮੰਗੋ।
ਟੈਸਟ ਫਜੀ ਹੋਣ 'ਤੇ ਸਪੀਡ ਦਾਵੇ ਢਹਿ ਜਾਂਦੇ ਹਨ। ਮਨਾਂ ਕਰੋ ਤੁਸੀਂ ਇੱਕ ਮੈਟ੍ਰਿਕ ਨਾਂਮ ਅਤੇ ਬੇਸਲਾਈਨ ਦੇ ਨਤੀਜੇ ਲਿਖ ਦਿਓ। ਉਹ ਵੇਰਵੇ ਜਿਹੜੇ ਨੰਬਰ ਬਦਲਦੇ ਹਨ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ: ਮਸ਼ੀਨ ਦੀ ਕਿਸਮ, CPU ਲੋਡ, ਡਾਟਾਸੈਟ ਆਕਾਰ, ਬਿਲਡ ਮੋਡ (debug vs release), ਫੀਚਰ ਫਲੈਗ, ਕੈਸ਼ ਸਥਿਤੀ, ਅਤੇ ਕਨਕਰੈਂਸੀ। ਜੇ ਤੁਸੀਂ ਕੱਲ੍ਹ ਇਹ ਸੈੱਟਅੱਪ ਦੁਹਰਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਬੇਸਲਾਈਨ ਨਹੀਂ ਹੈ।
ਚੈੱਕਲਿਸਟ:
ਨਤੀਜੇ ਚੰਗੇ ਹੋਣ 'ਤੇ ਤੇਜ਼ ਰਿਗ੍ਰੈਸ਼ਨ ਪਾਸ ਕਰ ਲਓ: ਸਹੀਤਾ, ਚੁੱਕਤ ਦਰ, ਟਾਈਮਆਊਟ, ਮੈਮੋਰੀ, CPU, ਜਾਂ DB ਲੋਡ ਦੇ ਦੂਜੇ ਪ੍ਰਭਾਵ ਵੀ ਦੇਖੋ।