ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ — ਪਹਿਲਾਂ ਮਾਪ ਕਰੋ। ਹੌਲੀਪਣ ਕਲਾਇੰਟ, ਨੈੱਟਵਰਕ, ਸਰਵਰ ਜਾਂ ਡੇਟਾਬੇਸ ਤੋਂ ਆ ਸਕਦਾ ਹੈ। ਇੱਕ ਤਰਤੀਬਵਾਰ ਪਹੁੰਚ ਇਹ ਲੱਭਦੀ ਹੈ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਲੱਗਦਾ ਹੈ, ਫਿਰ ਸਭ ਤੋਂ ਵੱਡੇ ਯੋਗਦਾਨ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ ਬਜਾਏ ਬੇ ਤਰਤੀਬ ਅਨੁਕੂਲਨ ਦੇ।
ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ — ਪਹਿਲਾਂ ਮਾਪ ਕਰੋ। ਹੌਲੀਪਣ ਕਲਾਇੰਟ, ਨੈੱਟਵਰਕ, ਸਰਵਰ ਜਾਂ ਡੇਟਾਬੇਸ ਤੋਂ ਆ ਸਕਦਾ ਹੈ। ਇੱਕ ਤਰਤੀਬਵਾਰ ਪਹੁੰਚ ਇਹ ਲੱਭਦੀ ਹੈ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਲੱਗਦਾ ਹੈ, ਫਿਰ ਸਭ ਤੋਂ ਵੱਡੇ ਯੋਗਦਾਨ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ ਬਜਾਏ ਬੇ ਤਰਤੀਬ ਅਨੁਕੂਲਨ ਦੇ।
1. MEASURE → where is the time spent? client render, network, server, DB?
2. REPRODUCE → confirm it reliably (same endpoint, payload, user)
3. TRACE → use APM/distributed traces to find the slow span
4. CHECK RECENT CHANGES → deploys, config, traffic, data growth
5. ISOLATE → layer by layer, narrow to one component
6. FIX the biggest contributor → re-measure to confirm
ਬ੍ਰਾਊਜ਼ਰ ਦੇ Network/Performance ਟੈਬ ਅਤੇ ਸਰਵਰ timing ਦੀ ਵਰਤੋਂ ਕਰੋ ਕੁਲ ਨੂੰ ਵੰਡਣ ਲਈ। ਇੱਕ ਮਫੀਦ ਟੁੱਟਵਾਂ:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
ਪ੍ਰਤੀਸ਼ਤ ਨੂੰ ਦੇਖੋ, ਔਸਤ ਨਹੀਂ: p50 (ਆਮ ਉਪਭੋਗਤਾ) ਬਨਾਮ p99 (ਸਭ ਤੋਂ ਬੁਰੀ ਸਥਿਤੀ)। ਤੇਜ਼ p50 ਅਤੇ ਹੌਲੀ p99 ਅਕਸਰ ਆਉਣ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ — lock contention, ਸਰਦ ਕੈਸ਼, ਇੱਕ ਹੌਲਾ DB replica, ਜਾਂ GC pauses — ਇੱਕ ਯਕਸਾਂ ਸਮੱਸਿਆ ਨਹੀਂ।
APM tools (traces) ਬਿਲਕੁਲ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਸਮਾਂ ਇੱਕ request ਦੇ ਅਨਦਰ ਕਿੱਥੇ ਲੱਗਦਾ ਹੈ:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
Trace ਸਿੱਧਾ ਅਪਰਾਧੀ ਕਾਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਫਿਰ ਹਾਲੀਆ ਤਬਦੀਲੀਆਂ ਦੀ ਜਾਂਚ ਕਰੋ — ਇੱਕ deploy, ਇੱਕ ਖੁੰਨਾ ਹੋਇਆ index, ਜਾਂ 10x ਡੇਟਾ ਦਾ ਵਿਕਾਸ ਅਕਸਰ ਇੱਕ ਅਚਾਨਕ regression ਨੂੰ ਸਮਝਾਉਂਦਾ ਹੈ।
ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਗਲਤ ਪੱਧਰ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਵਿੱਚ ਘੰਟੇ ਬਰਬਾਦ ਕਰਦਾ ਹੈ। ਪਹਿਲਾਂ ਮਾਪ ਕਰਨਾ, ਹੌਲੀ span ਨੂੰ trace ਕਰਨਾ, ਅਤੇ p50 ਬਨਾਮ p99 ਦੇਖਣਾ ਇੱਕ ਅਸਪੱਸ਼ਟ "ਇਹ ਹੌਲਾ ਹੈ" ਨੂੰ ਇੱਕ ਖਾਸ, ਠੀਕ ਕਰਨ ਯੋਗ ਕਾਰਨ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ — ਅਤੇ ਦੁਬਾਰਾ ਮਾਪ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਕਿ ਠੀਕ ਕਰਨਾ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਿਆ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ