Claude Code ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਜਾਂਚ: ਇੱਕ ਮਾਪਿਆ ਗਿਆ ਵਰਕਫਲੋ

ਮਾਪਣ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਕਿਉਂ ਗਲਤ ਹੁੰਦਾ ਹੈ

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

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

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

ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਵਾਦ-ਵਿਵਾਦ ਵਾਂਗ ਨਾ ਸਮਝੋ; ਇਸਨੂੰ ਇਕ ਐਕਸਪੇਰੀਮੈਂਟ ਮੰਨੋ। ਲੂਪ ਸਧਾਰਣ ਅਤੇ ਦੁਹਰਾਯੋਗ ਹੈ:

• ਉਸ ਇੱਕ ਮੈਟ੍ਰਿਕ ਨੂੰ ਚੁਣੋ ਜੋ ਦਰਦ ਦਿਖਾਂਦਾ ਹੈ (latency, throughput, CPU, memory, DB time).
• ਇਕੋ ਹੀ ਸ਼ਰਤਾਂ ਹੇਠਾਂ ਬੇਸਲਾਈਨ ਲਓ।
• ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਗਲ ਬਦਲੋ।
• ਦੁਬਾਰਾ ਮਾਪੋ ਅਤੇ ਤੁਲਨਾ ਕਰੋ।

ਕਈ ਜਿੱਤ ਨੱਝੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: p95 latency ਤੋਂ 8% ਘਟਾਉਣਾ, ਪੀਕ ਮੈਮੋਰੀ 50 MB ਘੱਟ ਕਰਨਾ, ਜਾਂ ਇੱਕ DB ਕਾਨੂੰਰੀ ਨੂੰ ਕੱਟਣਾ। ਇਹ ਜਿੱਤ ਮਹਤਵਪੂਰਨ ਹਨ — ਪਰ ਸਿਰਫ ਜਦ ਉਹ ਮਾਪੇ, ਪੁਸ਼ਟੀ ਕੀਤੇ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਹਨ।

ਵਰਕਫਲੋ: ਮਾਪੋ, ਹਿਪੋਥੈਸਾਈਜ਼ ਕਰੋ, ਬਦਲੋ, ਦੁਬਾਰਾ ਮਾਪੋ

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

ਸਪੱਸ਼ਟ ਕ੍ਰਮ:

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

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

"ਡਨ" ਕੋਈ ਭਾਵਨਾ ਨਹੀਂ। ਇਸ ਨਤੀਜਾ ਹੈ: ਟਾਰਗਿਟ ਮੈਟ੍ਰਿਕ ਸਹੀ ਦਿਸ਼ਾ ਵਿੱਚ ਹਿਲਿਆ, ਅਤੇ ਬਦਲਾਅ ਨੇ ਸਪੱਸ਼ਟ ਰਿਗ੍ਰੈਸ਼ਨ (errors, ਵੱਧ ਮੈਮੋਰੀ, খਰਾਬ p95 latency, ਜਾਂ ਨੇੜਲੇ endpoint ਧੀਮੇ ਹੋਣਾ) ਨਹੀਂ ਉਪਜਾਏ।

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

ਮੈਟ੍ਰਿਕ ਚੁਣੋ ਅਤੇ ਬੇਸਲਾਈਨ ਲਾਕ ਕਰੋ

ਜੇ ਤੁਸੀਂ ਇਕੋ ਵਾਰੀ ਵਿੱਚ ਪੰਜ ਚੀਜ਼ਾਂ ਮਾਪੋਂਗੇ ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਲਗੇਗਾ ਕਿ ਕੀ ਸੁਧਰਿਆ। ਇਸ ਜਾਂਚ ਲਈ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕ ਚੁਣੋ ਅਤੇ ਬਾਕੀ ਨੂੰ ਸਹਾਇਕ ਸੰਕੇਤ ਸਮਝੋ। ਕਈ ਯੂਜ਼ਰ-ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਲਈ ਇਹ ਮੈਟ੍ਰਿਕ latency ਹੁੰਦੀ ਹੈ। ਬੈਚ ਕੰਮ ਲਈ ਇਹ throughput, CPU ਟਾਈਮ, ਮੈਮੋਰੀ ਵਰਤੋਂ, ਜਾਂ ਕਪਰ ਰਣ-ਖਰਚ ਹੋ ਸਕਦਾ ਹੈ।

ਸਨੀਨਾਰਿਓ ਬਹੁਤ ਵਿਸ਼ੇਸ਼ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। "API ਧੀਮਾ ਹੈ" ਬਹੁਤ ਢਿੱਲਾ ਹੈ। "POST /checkout ਇੱਕ ਆਮ ਕਾਰਟ 3 ਆਈਟਮ ਨਾਲ" ਮਾਪ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਨਪੁੱਟ ਨੂੰ ਸਥਿਰ ਰੱਖੋ ਤਾਂ ਜੋ ਨੰਬਰਾਂ ਦੀ ਵਿਆਖਿਆ ਹੋ ਸਕੇ।

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

Latency ਲਈ, ਸਿਰਫ ਔਸਤ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ — percentiles 'ਤੇ ਧਿਆਨ ਦਿਓ। p50 ਆਮ ਤਜਰਬਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਦਕਿ p95 ਅਤੇ p99 ਉਨ੍ਹਾਂ ਦਰਦ ਭਰੇ ਟੇਲਾਂ ਨੂੰ ਦਿਖਾਉਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਯੂਜ਼ਰ ਸ਼ਿਕਾਇਤਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਕੋਈ ਬਦਲਾਅ ਜੋ p50 ਨੂੰ ਸੁਧਾਰਦਾ ਪਰ p99 ਨੂੰ ਖਰਾਬ ਕਰਦਾ, ਫੀਲ ਵਿੱਚ ਅਜੇ ਵੀ ਧੀਮਾ ਰਹਿ ਸਕਦਾ ਹੈ।

ਅਰੰਭ ਵਿੱਚ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ "ਮਹੱਤਵਪੂਰਨ" ਦਾ مطلب ਕੀ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸ਼ੋਰ 'ਤੇ ਜਸ਼ਨ ਨਾ ਮਨਾਓ:

• Latency: p95 ਵਿੱਚ ਘੱਟੋ-ਘੱਟ 10% ਸੁਧਾਰ (ਜਾਂ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੀਮਾ ਜਿਵੇਂ 50 ms)
• Throughput: ਇਕੋ error ਦਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ 5% ਵਾਧਾ
• CPU ਜਾਂ ਮੈਮੋਰੀ: ਇੰਨੀ ਕਮੀ ਕਿ ਸਕੇਲ ਕਰਨ ਜਾਂ ਕਰੈਸ਼ ਰੋਕੇ ਜਾ ਸਕੇ
• ਲਾਗਤ: ਪ੍ਰਤੀ ਦੌੜ ਜਾਂ 1,000 ਰਿਕਵੈਸਟ ਪ੍ਰਤੀ ਮਾਪਯੋਗ ਘਟਾਅ

ਇਹ ਨਿਯਮ ਇੱਕ ਵਾਰੀ ਸੈਟ ਹੋਣ 'ਤੇ ਤੁਸੀਂ ਬੇਸਲਾਈਨ ਨੂੰ ਹਿਲਾਏ ਬਿਨਾਂ ਵਿਚਾਰਾਂ ਦੀ ਪਰਖ ਕਰ ਸਕਦੇ ਹੋ।

ਪ੍ਰੋਫਾਈਲਿੰਗ ਅਤੇ ਸਾਦੇ ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਸਬੂਤ ਇਕੱਤਰ ਕਰੋ

ਸਭ ਤੋਂ ਆਸਾਨ ਅਤੇ ਭਰੋਸੇਯੋਗ ਸੰਕੇਤ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਸਿੰਗਲ ਟਾਈਮਿੰਗ ਦੱਸ ਸਕਦੀ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਅਸਲ ਸਮੱਸਿਆ ਹੈ ਅਤੇ ਉਹ ਕਿੰਨੀ ਵੱਡੀ ਹੈ। ਘੇਰੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਨੂੰ صرف ਉਸ ਵੇਲੇ ਸੰਭਾਲੋ ਜਦ ਤੁਹਾਨੂੰ ਦੱਸਣ ਦੀ ਲੋੜ ਹੋ ਕਿ ਕਿਉਂ ਧੀਮਾ ਹੈ।

ਚੰਗਾ ਸਬੂਤ ਆਮ ਤੌਰ 'ਤੇ ਹੇਠਾਂ ਦੇ ਸਰੋਤਾਂ ਦੇ ਮਿਕਸ ਤੋਂ ਆਉਂਦਾ ਹੈ:

• ਐਪ ਲੌਗ (ਰਿਕਵੈਸਟ ਅਵਧੀ, error ਦਰ, ਸਭ ਤੋਂ ਧੀਮੇ endpoints)
• APM ਟਰੇਸ (ਸੇਵਾਵਾਂ ਵਿੱਚ ਸਮਾਂ ਕਿੱਥੇ ਲਗ ਰਿਹਾ ਹੈ)
• ਪ੍ਰੋਫਾਈਲਰ ਆਉਟਪੁੱਟ ਜਾਂ ਫਲੇਮ ਗ੍ਰਾਫ (ਹੋਟ ਫੰਕਸ਼ਨ ਅਤੇ ਕਾਲ ਸਟੈਕ)
• ਡੇਟਾਬੇਸ ਸਟੈਟਸ (ਸੁਸਤ ਕਵੈਰੀਜ਼, ਲਾਕ ਉਡੀਕਾਂ, ਕੈਸ਼ ਹਿਟ ਰੇਟ)
• ਇੰਫਰਾਸਟਰੱਕਚਰ ਮੈਟ੍ਰਿਕਸ (CPU, memory, ਨੈਟਵਰਕ, ਕਨਟੇਨਰ ਰੀਸਟਾਰਟ)

ਸਵਾਲ "ਕੀ ਇਹ ਧੀਮਾ ਹੈ ਅਤੇ ਕਿੰਨਾ?" ਲਈ ਸਾਦੇ ਮੈਟ੍ਰਿਕਸ ਵਰਤੋ। ਜਦ ਸਵਾਲ ਹੋਵੇ "ਸਮਾਂ ਕਿੱਥੇ ਲੱਗ ਰਿਹਾ ਹੈ?" ਤਾਂ ਪ੍ਰੋਫਾਈਲਿੰਗ ਵਰਤੋ। ਜੇ 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 Code ਨੂੰ ਅਟਕਲਾਂ ਵਿੱਚ ਨਹੀਂ ਪਾਉਣ ਦਾ ਤਰੀਕਾ

Claude ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਲਾਭਕਾਰਕ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਸਾਵਧਾਨ ਵਿਸ਼ਲੇਸ਼ਕ ਵਾਂਗ ਵਰਤਦੇ ਹੋ, ਨਾ ਕਿ ਇੱਕ ਓਰੈਕਲ। ਹਰ ਸੁਝਾਅ ਨੂੰ ਜੋ ਤੁਸੀਂ ਮੰਗਦੇ ਹੋ ਉਹ ਮਾਪੇ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹਰ ਕਦਮ ਨੂੰ ਗਲਤ ਸਾਬਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇਸਨੂੰ vague ਵਰਣਨ ਨਾ ਦਿਓ—ਅਸਲ ਇਨਪੁੱਟ ਦਿਓ। ਛੋਟਾ, ਧਿਆਨ ਕੇਂਦਰਿਤ ਸਬੂਤ ਪੇਸਟ ਕਰੋ: ਇੱਕ ਪ੍ਰੋਫਾਈਲਿੰਗ ਸੰਖੇਪ, ਕੁਝ ਲੌਗ ਲਾਈਨਾਂ ਸਲੋਂ, ਇੱਕ ਕਵੈਰੀ ਯੋਜਨਾ, ਅਤੇ ਖਾਸ ਕੋਡ ਪਾਥ। "ਪਹਿਲਾਂ" ਨੰਬਰ (p95 latency, CPU time, DB time) ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਤੁਹਾਡਾ ਬੇਸਲਾਈਨ ਜਾਣ ਸਕੇ।

ਇਸਨੂੰ ਪੁੱਛੋ ਕਿ ਡੇਟਾ ਕੀ ਦਸਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ। ਫਿਰ ਮੁਕਾਬਲੇ ਸਿਰਫ 2-3 ਹਿਪੋਥੈਸਿਸ ਮੰਗੋ ਅਤੇ ਹਰ ਇਕ ਲਈ ਕੀ ਗਲਤ ਸਾਬਤ ਕਰੇਗਾ ਉਹ ਪੁੱਛੋ। ਇੱਕ ਵਧੀਆ ਪ੍ਰੰਪਟ ਅਖੀਰ 'ਤੇ ਲਿਖਿਆ ਹੋਵੇ: "ਮੈਨੂੰ 2-3 ਹਿਪੋਥੈਸਿਸ ਦਿਓ, ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਦੱਸੋ ਕੀ ਉਹ ਨੂੰ ਫਾਲਸਿਫਾਈ ਕਰੇਗਾ।" ਇਹ ਪਹਿਲੀ ਮੰਨਣਯੋਗ ਕਹਾਣੀ 'ਤੇ ਫਸਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

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

ਜੇ ਤੁਸੀਂ ਨਿਰਧਾਰਤ ਫ਼ਾਰਮੈਟ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਪੁੱਛੋ:

• ਸਬੂਤ ਕੀ ਦਿਖਾਉਂਦਾ ਹੈ (ਅਤੇ ਭਰੋਸਾ)
• 2-3 ਹਿਪੋਥੈਸਿਸ ਅਤੇ ਹਰ ਇੱਕ ਲਈ ਫਾਲਸੀਫਿਕੇਸ਼ਨ ਟੈਸਟ
• ਟਾਪ ਹਿਪੋਥੈਸਿਸ ਨੂੰ ਟੈਸਟ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਛੋਟਾ ਕੋਡ ਜਾਂ ਸੰਰਚਨਾ ਬਦਲਾਅ
• ਦੁਬਾਰਾ ਮਾਪਣ ਲਈ ਸਟ੍ਰਿਕਟ ਨਿਰਦੇਸ਼ ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਦਿਸ਼ਾ

ਜੇ ਇਹ ਨਿਰਧਾਰਤ ਮੈਟ੍ਰਿਕ, ਥਾਂ ਅਤੇ ਉਮੀਦਸ਼ੁਦਾ ਨਤੀਜੇ ਨਹੀਂ ਦੱਸ ਸਕਦਾ, ਤਾਂ ਤੁਸੀਂ ਫਿਰ ਵਾਪਸ ਅਟਕਲਾਂ ਵਾਲੇ ਰਾਹ ਤੇ ਹੋ।

ਘੱਟ ਤੋਂ ਘੱਟ, ਵਾਪਸੀਯੋਗ ਬਦਲਾਅ ਕਰੋ

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

ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਚੀਜ਼ ਬਦਲੋ। ਜੇ ਤੁਸੀਂ ਇੱਕੋ ਕਮਿੱਟ ਵਿੱਚ ਕਵੈਰੀ ਸਮੀਕਰਨ, caching ਅਤੇ ਲੂਪ ਰੀਫੈਕਟਰ ਕਰ ਦਿਓਗੇ ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ ਕਿ ਕੀ ਸਹੀ ਕੀਤਾ। ਇਕੱਲੇ-ਫੈਕਟਰ ਬਦਲਾਅ ਅਗਲੇ ਮਾਪਣ ਨੂੰ ਮਾਨਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।

ਕੋਡ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ ਉਮੀਦ ਕੀ ਲਿਖੋ: ਉਦਾਹਰਨ: "p95 latency 420 ms ਤੋਂ ਘਟ ਕੇ 300 ms ਤੋਂ ਥੱਲੇ ਹੋ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ DB ਸਮਾਂ ਲਗਭਗ 100 ms ਘਟਣਾ ਚਾਹੀਦਾ ਹੈ।" ਜੇ ਨਤੀਜਾ ਇਸ ਟੀਚੇ ਤੱਕ ਨਹੀਂ ਪੁੱਜਦਾ, ਤਾਂ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਹੀ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ ਕਿ ਹਿਪੋਥੈਸਿਸ ਕਮਜ਼ੋਰ ਸੀ।

ਬਦਲਾਅ ਵਾਪਸੀਯੋਗ ਰੱਖੋ:

• ਛੋਟਾ ਡਿਫ ਪਹੁੰਚਯੋਗ ਰੱਖੋ ਜੋ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਰਿਵਰਟ ਕੀਤਾ ਜਾ ਸਕੇ।
• ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਲਦੀ ਬੰਦ ਕਰ ਸਕੋ।
• ਡਰਾਈਵ-ਬਾਈ ਰੀਫੈਕਟਰ ਨੂੰ ਪੈਰਫਾਰਮੈਂਸ ਟਵੀਕ ਨਾਲ ਨਾ ਮਿਲਾਓ।
• ਦਾਇਰਾ ਸਿਫ਼ਤ: ਇੱਕ ਐਂਡਪੌਇੰਟ, ਇੱਕ ਹਾਟ ਪਾਥ, ਇੱਕ ਮਹਿੰਗੀ ਕਾਲ।
• ਕਮਿਟ ਸੁਨੇਹੇ ਵਿੱਚ ਉਮੀਦ/ਪਹਿਲਾਂ-ਬਾਅਦ ਨੰਬਰ ਲਿਖੋ।

"ਘੱਟ" ਦਾ ਮਤਲਬ "ਛੋਟਾ" ਨਹੀਂ, ਇਸਦਾ ਅਰਥ ਹੈ ਫੋਕਸ: ਇੱਕ ਮਹਿੰਗੇ ਫੰਕਸ਼ਨ ਲਈ cached result, ਇੱਕ ਤੰਗ ਲੂਪ ਵਿੱਚ ਇੱਕ ਵਾਰ-ਵਾਰ ਐਲੋਕੇਸ਼ਨ ਹਟਾਉਣਾ, ਜਾਂ ਉਹ ਕੰਮ ਰੋਕਣਾ ਜੋ ਕੁਝ ਰਿਕਵੈਸਟਾਂ ਲਈ ਲੋੜੀਂਦਾ ਨਹੀਂ।

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

ਦੁਬਾਰਾ ਮਾਪੋ ਅਤੇ ਅਗਲਾ ਕਦਮ ਫੈਸਲਾ ਕਰੋ

ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ, ਬੇਸਲਾਈਨ ਲਈ ਵਰਤੇ ਗਏ ਇਕੋ ਹੀ ਸਨੀਨਾਰਿਓ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਓ: ਇਕੋ ਇਨਪੁੱਟ, ਵਾਤਾਵਰਣ, ਅਤੇ ਲੋਡ ਸ਼ੇਪ। ਜੇ ਤੁਹਾਡਾ ਟੈਸਟ ਕੈਸ਼/ਵਾਰਮਅੱਪ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ ਇਹ ਸਪਸ਼ਟ ਰੱਖੋ (ਉਦਾਹਰਨ: "ਪਹਿਲੀ ਦੌੜ ਠੰਢੀ, ਅਗਲੀ 5 ਦੌੜ ਗਰਮ")। ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਐਸੇ ਸੁਧਾਰ ਲੱਭੋਗੇ ਜੋ ਅਸਲ ਵਿੱਚ ਵਕਫ-ਕਿਸਮਤ ਹੋਣਗੇ।

ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਵੇਲੇ ਇਕੋ ਮੈਟ੍ਰਿਕ ਅਤੇ ਇਕੋ percentiles ਵਰਤੋ। ਔਸਤ ਦਰਦ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ p95 ਅਤੇ p99 latency, ਨਾਲ ਹੀ throughput ਅਤੇ CPU ਟਾਈਮ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ। ਨੰਬਰਾਂ ਸਥਿਰ ਹੋਣ ਤੱਕ ਕਾਫੀ ਦੌੜ ਰਨ ਕਰੋ।

ਜਸ਼ਨ ਮਨਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ ਰਿਗ੍ਰੈਸ਼ਨ ਵੀ ਚੈੱਕ ਕਰੋ ਜੋ ਇਕ ਸਿਰਲੇਖ ਨੰਬਰ ਵਿੱਚ ਨਹੀਂ ਦਿਖਦੇ:

• ਸਹੀਤਾ: ਜਵਾਬ ਅਜੇ ਵੀ ਉਮੀਦ ਅਨੁਸਾਰ ਹਨ
• ਚੁੱਕਤ ਦਰ: ਟਾਇਮਆਊਟ, 5xx, ਰੀਟ੍ਰਾਈ
• ਮੈਮੋਰੀ: ਪੀਕ ਜਾਂ ਲਗਾਤਾਰ ਵਾਧਾ
• ਟੇਲ ਲੈਟੈਂਸੀ: p99 ਖਰਾਬ ਹੋਇਆ
• ਰਿਸੋਰਸ ਲਾਗਤ: CPU ਜਾਂ DB ਲੋਡ ਵਿੱਚ spike

ਫਿਰ ਸਬੂਤ ਦੇ ਆਧਾਰ 'ਤੇ ਫੈਸਲਾ ਕਰੋ, ਨਾਂ ਕਿ ਆਸ ਤੇ। ਜੇ ਸੁਧਾਰ ਅਸਲ ਹੈ ਅਤੇ ਤੁਸੀਂ ਰਿਗ੍ਰੈਸ਼ਨ ਨਹੀਂ ਲਿਆਂਦੇ, ਤਾਂ ਫਿਕਸ ਰੱਖੋ। ਜੇ ਨਤੀਜੇ ਮਿਲੇ-ਜੁਲੇ ਜਾਂ ਸ਼ੋਰ ਵਾਲੇ ਹਨ, ਤਾਂ revert ਕਰੋ ਅਤੇ ਨਵੀਂ ਹਿਪੋਥੈਸਿਸ ਬਣਾਓ ਜਾਂ ਬਦਲਾਅ ਨੂੰ ਹੋਰ ਅਲੱਗ ਕਰੋ।

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

ਅਖ਼ਿਰਕਾਰ, ਜੋ ਤੁਹਾਨੂੰ ਸਿੱਖਿਆ ਉਸਨੂੰ ਲਿਖੋ: ਬੇਸਲਾਈਨ, ਬਦਲਾਅ, ਨਵੇਂ ਨੰਬਰ, ਅਤੇ ਨਤੀਜਾ। ਇਹ ਛੋਟੀ ਰਿਕਾਰਡ ਅਗਲੇ ਚੱਕਰ ਨੂੰ انہੀ ਮਿਰਾੜਾ ਨਾਲ ਦੁਹਰਾਉਣ ਤੋਂ بچਾਉਂਦਾ ਹੈ।

ਸਮਾਨ ਗਲਤੀਆਂ ਜੋ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦੀਆਂ ਹਨ

ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਉਹਸ ਵੇਲੇ ਬਾਹਰ ਚਲਾ ਜਾਂਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਜੋ ਮਾਪਿਆ ਉਸ ਅਤੇ ਜੋ ਬਦਲਿਆ ਉਸ ਵਿਚਕਾਰ ਲੜੀ ਗੁਆ ਬੈਠਦੇ ਹੋ। ਸਾਫ਼ ਸਬੂਤ ਦੀ ਲੜੀ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਇਹ ਪੱਕਾ ਕਹਿ ਸਕੋ ਕਿ ਕੀ ਚੀਜ਼ ਚੰਗੀ ਕੀਤੀ।

ਰੀਪਟੀਟਰ:

• ਗਲਤ ਟਾਰਗਟ 'ਤੇ ਕੰਮ: ਤੁਸੀਂ median (p50) ਤੇ ਜਿੱਤ ਮਨਾ ਲੈਂਦੇ ਹੋ ਪਰ tail latency ਬਦੀ ਰਹਿੰਦੀ ਹੈ
• ਇਕੋ ਵਾਰੀ ਵਿੱਚ ਕਈ ਬਦਲਾਅ: ਰੀਫੈਕਟਰ, caching, ਅਤੇ ਕਵੈਰੀ ਟਵੀਕ ਇੱਕ ਕਮਿੱਟ ਵਿੱਚ ਹੋਣ ਨਾਲ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਕੀ ਫਾਇਦਾ ਕੀਤਾ
• ਇੱਕ ਸ਼ੋਰ ਭਰੀ ਦੌੜ ਤੇ ਭਰੋਸਾ: ਲੋਕਲ ਬੈਂਚਮਾਰਕ ਜੋ ਦੌੜਾਂ ਵਿਚ 20% ਹਿਲਦਾ ਹੈ ਪ੍ਰਮਾਣ ਨਹੀਂ
• ਇੱਕ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਪੂਰੀ ਸੱਚਾਈ ਸਮਝ ਲੈਣਾ
• ਅਲਗ-ਅਲਗ ਸਥਿਤੀਆਂ ਦਾ ਤੁਲਨਾ ਕਰਕੇ ਨਤੀਜੇ ਕੱਢਣਾ

ਛੋਟੀ ਉਦਾਹਰਨ: ਇੱਕ ਐਂਡਪੌਇੰਟ ਕਮਜ਼ੋਰ ਲੱਗਦਾ ਹੈ, ਸੋ ਤੁਸੀਂ serializer ਟਿਊਨ ਕਰਦੇ ਹੋ ਕਿਉਂਕਿ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਉਹ ਹਾਟ ਸੀ। ਫਿਰ ਤੁਸੀਂ ਛੋਟੇ ਡੇਟਾਸੈਟ ਨਾਲ ਪੁਨਰਪਰਖ ਕਰਦੇ ਹੋ ਅਤੇ ਇਹ ਤੇਜ਼ ਲੱਗਦਾ ਹੈ। ਪ੍ਰੋਡ ਵਿੱਚ p99 ਖਰਾਬ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਅਜੇ ਵੀ ਬੋਤਲਨੇਕ ਸੀ ਅਤੇ ਤੁਹਾਡੇ ਬਦਲਾਅ ਨੇ payload ਆਕਾਰ ਵਧਾ ਦਿੱਤਾ।

ਜੇ ਤੁਸੀਂ Claude Code ਨੂੰ fix ਸੁਝਾਉਣ ਲਈ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਉਸਨੂੰ ਘੁੰਮਾਓ-ਫੇਰਾਓ ਉੱਤੇ ਰੱਖੋ। 1-2 ਘੱਟ ਬਦਲਾਅ ਮੰਗੋ ਜੋ ਤੁਹਾਡੇ ਸਬੂਤ ਨਾਲ ਮਿਲਦੇ ਹੋਣ, ਅਤੇ ਪ੍ਰਤੀ ਬਦਲਾਅ ਦੁਬਾਰਾ ਮਾਪڻ ਦੀ ਯੋਜਨਾ ਮੰਗੋ।

ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ "ਤੇਜ਼" ਕਹੋ

ਸਪੀਡ ਦਾਵੇ ਟੈਸਟ ਫਜ਼ੀ ਹੋਣ 'ਤੇ ਠੁੱਕ ਜਾਂਦੇ ਹਨ। ਜਸ਼ਨ ਮਨਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਕਿੱਦਾ ਮਾਪਿਆ, ਕਿਵੇਂ ਮਾਪਿਆ, ਅਤੇ ਕੀ ਬਦਲਿਆ, ਇਹ ਸਮਝਾ ਸਕਦੇ ਹੋ।

ਪਹਿਲਾਂ ਇੱਕ ਮੈਟ੍ਰਿਕ ਨਾਮ ਲਓ ਅਤੇ ਬੇਸਲਾਈਨ ਨਤੀਜਾ ਲਿਖੋ। ਉਹ ਵੇਰਵੇ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਨੰਬਰ ਬਦਲ ਸਕਦੇ ਹਨ: ਮਸ਼ੀਨ ਕਿਸਮ, CPU ਲੋਡ, ਡੇਟਾਸੈਟ ਆਕਾਰ, ਬਿਲਡ ਮੋਡ (debug vs release), ਫੀਚਰ ਫਲੈਗ, ਕੈਸ਼ ਸਥਿਤੀ, ਅਤੇ ਕਨਕਰੈਂਸੀ। ਜੇ ਤੁਸੀਂ ਕੱਲ੍ਹ ਉਹ ਸੈੱਟਅੱਪ ਦੁਹਰਾਉ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਬੇਸਲਾਈਨ ਨਹੀਂ ਹੈ।

ਚੈੱਕਲਿਸਟ:

• ਮੈਟ੍ਰਿਕ ਅਤੇ ਬੇਸਲਾਈਨ ਵਾਤਾਵਰਣ ਨੋਟਸ ਨਾਲ ਦਰਜ ਕੀਤੇ ਹੋਏ।
• ਟੈਸਟ ਕਦਮ ਲਿਖੇ ਹੋਏ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ।
• ਇੱਕ ਹਿਪੋਥੈਸਿਸ ਅਤੇ ਪੇਸ਼ਗੀ ਅਨੁਮਾਨ (ਉਦਾਹਰਨ: "ਜੇ ਅਸੀਂ N+1 queries ਹਟਾਏਂ, p95 latency ~30% ਘਟੇਗੀ").
• ਇੱਕ ਛੋਟਾ, ਵਾਪਸੀਯੋਗ ਬਦਲਾਅ ਅਤੇ ਉਸ ਦੀ ਤਕਨੀਕੀ ਦਸਤਾਵੇਜ਼ੀ (ਫਾਈਲ, ਫੰਕਸ਼ਨ, ਕਵੈਰੀ, ਸੈਟਿੰਗ)।
• ਕਈ ਸੈਂਪਲ ਨਾਲ ਦੁਬਾਰਾ ਮਾਪਿਆ ਅਤੇ ਇਕੋ-ਜਿਹੇ ਸਥਿਤਾਂ 'ਤੇ ਤੁਲਨਾ ਕੀਤੀ ਗਈ।

ਨੰਬਰਾਂ ਚੰਗੇ ਹੋਣ 'ਤੇ ਤੇਜ਼ ਰਿਗ੍ਰੈਸ਼ਨ ਪਾਸ ਕਰੋ: ਸਹੀਤਾ, ਚੁੱਕਤ ਦਰ, ਅਤੇ ਟਾਈਮਆਊਟ ਜਾਂ payload/ਰਿਸੋਰਸ ਪ੍ਰਭਾਵਾਂ ਤੇ ਨਜ਼ਰ ਰੱਖੋ। p95 latency ਸੁਧਰਦੇ ਹੋਏ ਦੂਜੇ ਖਰਾਬ ਪ੍ਰਭਾਵ (ਜਿਵੇਂ ਦੂਗੁਣਾ ਮੈਮੋਰੀ) ਇੱਕ ਗਲਤ ਵਪਾਰ ਹੋ ਸਕਦੇ ਹਨ।

ਉਦਾਹਰਨ: ਇੱਕ ਸਲੋ API ਐਂਡਪੌਇੰਟ ਦੀ ਕਦਮ-ਦਰ-ਕਦਮ ਜਾਂਚ

ਇੱਕ ਟੀਮ ਦੱਸਦੀ ਹੈ ਕਿ GET /orders dev ਵਿੱਚ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਪਰ ਸਟੇਜਿੰਗ ਵਿੱਚ ਮੋਡਰੇਟ ਲੋਡ 'ਤੇ ਧੀਮਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਯੂਜ਼ਰ ਟਾਈਮਆਊਟ ਦੀ ਸ਼ਿਕਾਇਤ ਕਰਦੇ ਹਨ, ਪਰ ਔਸਤ ਲੈਟੈਂਸੀ ਅਜੇ ਵੀ "ਠੀਕ" ਲੱਗਦੀ ਹੈ — ਇੱਕ ਆਮ ਫੰਦ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਬੇਸਲਾਈਨ ਸੈੱਟ ਕਰੋ। ਇੱਕ steady load test ਹੇਠਾਂ (ਇਕੋ ਡੇਟਾਸੈਟ, ਇਕੋ ਕਨਕਰੈਂਸੀ, ਇਕੋ ਅਵਧੀ) ඔබ ਦਰਜ ਕਰਦੇ ਹੋ:

• p95 latency: 1.8s (ਟਾਰਗਿਟ < 600ms)
• API CPU: ~70% ਕੁਝ ਵਾਰ spikes
• DB: ਇੱਕ ਕਵੈਰੀ 900-1100ms ਲੈ ਰਹੀ ਹੈ, ਅਤੇ ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ ਕੁੱਲ ਕਵੈਰੀ ਸਮਾਂ ~1.3s ਹੈ

ਹੁਣ ਸਬੂਤ ਇਕੱਤਰ ਕਰੋ। ਇੱਕ ਤੇਜ਼ ਟ੍ਰੇਸ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਐਂਡਪੌਇੰਟ ਇੱਕ ਮੁੱਖ ਕਵੈਰੀ ਚਲਾਂਦਾ ਹੈ, ਫਿਰ orders ਪ੍ਰਤੀ ਆਈਟਮ ਲਈ related items ਫੈਚ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇਹ ਵੀ ਦੇਖਦੇ ਹੋ ਕਿ JSON response ਵੱਡਾ ਹੈ, ਪਰ DB ਸਮਾਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤੌਰ 'ਤੇ ਵੱਡਾ ਹੈ।

ਹੁਣ ਇਹਨੂੰ ਟੈਸਟ ਕਰਨ ਯੋਗ ਹਿਪੋਥੈਸਿਸ ਲਿਸਟ ਵਿੱਚ ਬਦਲੋ:

• ਇੱਕ slow query ਨੂੰ index ਦੀ ਲੋੜ ਹੈ।
• N+1 queries DB ਸਮਾਂ ਨੂੰ ਗੁਣਾ ਕਰ ਰਹੇ ਹਨ।
• Serialization ਵੱਡੇ payload ਕਰਕੇ ਧੀਮਾ ਹੈ।
• Lock contention reads ਨੂੰ writes ਦੌਰਾਨ ਰੋਕ ਰਹੀ ਹੈ।

ਸਬ ਤੋਂ ਮਜ਼ਬੂਤ ਸਬੂਤ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਘੱਟੋ-ਘੱਟ ਤਬਦੀਲੀ ਮੰਗੋ: N+1 ਕਾਲ ਨੂੰ ਹਟਾਣ ਲਈ related items ਨੂੰ single query ਵਿੱਚ order IDs ਨਾਲ ਲਿਆਓ (ਜਾਂ ਜੇ slow query plan full scan ਦਿਖਾ ਰਿਹਾ ਹੈ ਤਾਂ ਗੁੰਭੀਰ index ਜੋੜੋ). ਇਸਨੂੰ reversible ਅਤੇ focused commit ਰੱਖੋ।

ਉਸੇ ਲੋਡ ਟੈਸਟ ਨਾਲ ਦੁਬਾਰਾ ਮਾਪੋ। ਨਤੀਜੇ:

• p95 latency: 1.8s -> 720ms
• ਕੁੱਲ DB ਸਮਾਂ: ~1.3s -> 420ms
• CPU: ਥੋੜ੍ਹਾ ਘਟਿਆ, ਪਰ ਅਜੇ ਵੀ spikes ਹਨ

ਫੈਸਲਾ: ਫਿਕਸ ਸ਼ਿਪ ਕਰੋ (ਸਾਫ਼ ਜਿੱਤ), ਫਿਰ ਬਾਕੀ ਗੈਪ ਅਤੇ CPU spikes 'ਤੇ ਦੂਜਾ ਚੱਕਰ ਚਲਾਓ ਕਿਉਂਕਿ ਹੁਣ DB ਮੁੱਖ ਰੁਕਾਵਟ ਨਹੀਂ ਰਹੀ।

ਅਗਲੇ ਕਦਮ: ਇਸ ਵਰਕਫਲੋ ਨੂੰ ਰੁਟਿਨ ਬਣਾਓ

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

ਇੱਕ ਸਧਾਰਣ ਇੱਕ-ਪੇਜ਼ ਟੈਂਪਲੇਟ ਮਦਦਗਾਰ ਹੈ:

• ਮੈਟ੍ਰਿਕ + ਇਸਨੂੰ ਕਿਵੇਂ ਮਾਪਦੇ ਹੋ (ਟੂਲ, ਕਮਾਂਡ, ਡੇਟਾਸੈਟ)
• ਬੇਸਲਾਈਨ (ਨੰਬਰ, ਵਾਤਾਵਰਣ, ਕਦੋਂ ਕੈਪਚਰ ਕੀਤਾ)
• ਹਿਪੋਥੈਸਿਸ (ਇੱਕ ਵਾਕ, ਟੈਸਟ ਕਰਨਯੋਗ)
• ਬਦਲਾਅ (ਛੋਟਾ ਡਿਫ, ਕੀ ਛੇੜਿਆ)
• ਨਤੀਜਾ (ਪਹਿਲਾਂ/ਬਾਅਦ, ਫੈਸਲਾ)

ਇਹ ਨੋਟਸ ਕਿਸ ਥਾਂ ਰੱਖਣੇ ਹਨ ਇਹ ਫ਼ੈਸਲਾ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਗੁੰਮ ਨਾ ਹੋਣ: ਸਰਵਿਸ ਦੇ ਕੋਲ ਇੱਕ repo ਫੋਲਡਰ, ਟੀਮ ਡੌਕ, ਜਾਂ ਟਿਕਟ ਨੋਟਸ। ਖ਼ਾਸ ਗੱਲ ਹੈ ਖੋਜਯੋਗਤਾ। ਕਿਸੇ ਨੂੰ ਬਾਦ ਵਿੱਚ "p95 latency spike after caching change" ਮਹੀਨਿਆਂ ਬਾਅਦ ਵੀ ਲੱਭ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ।

ਸੁਰੱਖਿਅਤ ਪ੍ਰਯੋਗ ਆਦਤ ਬਣਾਓ। snapshots ਅਤੇ ਆਸਾਨ rollback ਵਰਤੋਂ ਤਾਂ ਜੋ ਤੁਸੀਂ ਇਕ ਆਈਡੀਆ ਬਿਨਾਂ ਡਰ ਦੇ ਟੈਸਟ ਕਰ ਸਕੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, Planning Mode ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਜਗ੍ਹਾ ਹੋ ਸਕਦੀ ਹੈ ਮਾਪਣ ਯੋਜਨਾ ਲਿਖਣ, ਹਿਪੋਥੈਸਿਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ, ਅਤੇ ਬਦਲਾਅ ਨੂੰ ਸੀਮਿਤ ਰੱਖਣ ਲਈ ਪਹਿਲਾਂ ਤੋਂ।

ਕੈਡੈਂਸ ਸੈੱਟ ਕਰੋ। ਘਟਨਾਵਾਂ ਦੀ ਉਡੀਕ ਨਾ ਕਰੋ। ਛੋਟੇ ਪ੍ਰਦਰਸ਼ਨ ਚੈੱਕ ਜੋੜੋ ਜਿਵੇਂ ਨਵੀਂ ਕਵੈਰੀ, ਨਵਾਂ ਐਂਡਪੌਇੰਟ, ਵੱਡਾ payload, ਜਾਂ dependency ਅਪਗਰੇਡ — 10 ਮਿੰਟ ਦਾ ਬੇਸਲਾਈਨ ਚੈੱਕ ਅੱਜ ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਦਿਨ ਦੇ ਅਟਕਲ-ਛਾਨਬੀਨ ਨੂੰ ਬਚਾ ਸਕਦਾ ਹੈ।