14 ਦਸੰ 2025·8 ਮਿੰਟ
Go + Postgres ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ: ਇੱਕ ਕੇਂਦ੍ਰਿਤ API ਪਲੇਬੁੱਕ
Go + Postgres ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ ਪਲੇਬੁੱਕ (AI-ਜਨਰੇਟ ਕੀਤੀਆਂ APIs ਲਈ): ਪੁਲ ਕਨੈਕਸ਼ਨ, EXPLAIN ਦੇਖੋ, ਸਮਾਰਟ ਇੰਡੈਕਸ, ਸੁਰੱਖਿਅਤ ਪੇਜੀਨੇਸ਼ਨ, ਤੇਜ਼ JSON ਆਕਾਰ।
Go APIs ਤੇ Postgres ਲਈ “ਧੀਮਾ” ਕਿਵੇਂ ਲੱਗਦਾ ਹੈ
AI-ਜਨਰੇਟ ਕੀਤੀਆਂ APIs ਸ਼ੁਰੂਆਤੀ ਟੈਸਟਿੰਗ ਵਿੱਚ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਇੱਕ ਐਂਡਪਾਏਂਟ ਕੁਝ ਵਾਰੀ ਹਿੱਟ ਕਰਦੇ ਹੋ, ਡੇਟਾਸੇਟ ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਬੇਨਤੀਆਂ ਇਕ-ਇਕ ਆਉਂਦੀਆਂ ਹਨ। ਫਿਰ ਅਸਲ ਟ੍ਰੈਫਿਕ ਆਉਂਦਾ ਹੈ: ਮਿਕਸਡ ਐਂਡਪਾਇੰਟ, ਬਰਸਟੀ ਲੋਡ, ਠੰਡੀਆਂ ਕੈਸ਼ਾਂ, ਅਤੇ ਅੰਕੜੇ ਜ਼ਿਆਦਾ। ਉਹੀ ਕੋਡ ਬੇਬੇਕ ਕਦੇ-ਕਦੇ ਧੀਮਾਪਨ ਦਿਖਾ ਸਕਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਕੁਝ ਤੂਟਿਆ ਨਹੀਂ।
ਧੀਮਾ ਅਕਸਰ ਕੁਝ ਤਰੀਕਿਆਂ ਨਾਲ ਵਰਕਦਾ ਹੈ: ਲੈਟਨਸੀ ਸਪਾਈਕ (ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਠੀਕ ਹਨ, ਪਰ ਕੁਝ 5x-50x ਲੰਮੇ ਲੱਗਦੀਆਂ ਹਨ), ਟਾਇਮਆਉਟ (ਛੋਟਾ ਪ੍ਰਤੀਸ਼ਤ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ), ਜਾਂ CPU ਗਰਮ ਚੱਲਣਾ (ਕਵੇਰੀ ਕੰਮ ਕਰਕੇ Postgres CPU, ਜਾਂ JSON, ਗੋਰੋਟੀਨਜ਼, ਲੌਗਿੰਗ ਅਤੇ ਰੀਟ੍ਰਾਈਜ਼ ਕਾਰਨ Go CPU)।
ਆਮ ਸਥਿਤੀ ਹੋ ਸਕਦੀ ਹੈ: ਇੱਕ ਲਿਸਟ ਐਂਡਪਾਇੰਟ ਜਿਸ ਵਿੱਚ ਲਚਕੀਲਾ ਖੋਜ ਫਿਲਟਰ ਹੈ ਅਤੇ ਵੱਡਾ JSON ਰਿਪਲਾਈ ਕਰਦਾ ਹੈ। ਟੈਸਟ ਡੇਟਾਬੇਸ ਵਿੱਚ ਇਹ ਕੁਝ ਹਜ਼ਾਰ ਰੋਜ਼ ਸਕੈਨ ਕਰਕੇ ਤੇਜ਼ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਇਹ ਕਈ ਮਿਲੀਅਨ ਰੋਜ਼ ਸਕੈਨ ਕਰਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ sort ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ LIMIT ਲਗਾਉਂਦਾ ਹੈ। API ਅਜੇ ਵੀ "ਚੱਲਦਾ" ਹੈ, ਪਰ p95 ਲੈਟਨਸੀ ਫੱਟਿਆ ਜਾਂਦੀ ਹੈ ਅਤੇ ਬਰਸਟ ਦੌਰਾਨ ਕੁਝ ਬੇਨਤੀਆਂ ਟਾਇਮਆਉਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਡਾਟਾਬੇਸ ਧੀਮਾਪਨ ਨੂੰ ਐਪ ਧੀਮਾਪਨ ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ ਮਨੋভাব ਸਧਾਰਨ ਰੱਖੋ।
ਜੇ ਡਾਟਾਬੇਸ ਧੀਮਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ Go ਹੈਂਡਲਰ ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ ਕਵੇਰੀ ਦੀ ਉਡੀਕ ਵਿੱਚ ਬਿਤਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਹੋ ਸਕਦਾ ਹੈ ਵੱਖ-ਵੱਖ ਬੇਨਤੀਆਂ ਨੂੰ "in flight" ਫਸਿਆ ਹੋਇਆ ਵੇਖੋ ਜਦ ਕਿ Go CPU ਸਧਾਰਨ ਰਹਿੰਦਾ ਹੈ।
ਜੇ ਐਪ ਧੀਮਾ ਹੈ, ਤਾਂ ਕਵੇਰੀ ਤੇਜ਼ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਪਰ ਕਵੇਰੀ ਦੇ ਬਾਅਦ ਸਮਾਂ ਲੁੱਟਦਾ ਹੈ: ਵੱਡੇ ਰਿਸਪਾਂਸ ਆਬਜੈਕਟ ਬਣਾਉਣਾ, JSON ਮਾਰਸ਼ਲ ਕਰਨਾ, ਪ੍ਰਤੀ-ਰੋਜ਼ ਹੋਰ ਕਵੇਰੀ ਚਲਾਉਣਾ, ਜਾਂ ਇੱਕ-ਰਿਕੈਸਟ 'ਤੇ ਬਹੁਤ ਕੰਮ ਕਰਨਾ। Go CPU ਅਤੇ ਮੈਮੋਰੀ ਵੱਧਦੇ ਹਨ ਅਤੇ ਲੈਟਨਸੀ ਜਵਾਬ ਦੇ ਆਕਾਰ ਨਾਲ ਵਧਦੀ ਹੈ।
ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ "ਚੰਗਾ ਕਾਫੀ" ਪ੍ਰਦਰਸ਼ਨ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ ਹੁੰਦਾ। ਕਈ CRUD ਐਂਡਪਾਇੰਟਾਂ ਲਈ, ਲਕਸ਼ ਹੈ: ਸਥਿਰ p95 ਲੈਟਨਸੀ (ਸਿਰਫ ਔਸਤ ਨਹੀਂ), ਬਰਸਟ ਦੇ ਦੌਰਾਨ ਪੇਸ਼ਗੀਯੋਗ ਬਿਹੈਵੀਅਰ, ਅਤੇ ਉਮੀਦਸ਼ੁਦਾ ਪੀਕ 'ਤੇ ਕੋਈ ਟਾਇਮਆਉਟ ਨਾ ਹੋਣਾ। ਟੀਚਾ ਸਪਸ਼ਟ ਹੈ: ਜਦੋਂ ਡੇਟਾ ਅਤੇ ਟ੍ਰੈਫਿਕ ਵਧੇ ਤਾਂ ਅਚਾਨਕ ਧੀਮੀ ਬੇਨਤੀ ਨਾ ਹੋਵੇ, ਅਤੇ ਜਦੋਂ ਕੁਝ ਡਰਿਫਟ ਹੋਏ ਤਾਂ ਸਪਸ਼ਟ ਸਿਗਨਲ ਮਿਲਣ।
ਪਹਿਲਾਂ ਬੇਸਲਾਈਨ: ਕੁਝ ਮੁੱਖ ਨੰਬਰ
ਕੁਝ ਵੀ ਟਿਊਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਹਾਡੀ API ਲਈ "ਚੰਗਾ" ਕੀ ਹੈ। ਬੇਸਲਾਈਨ ਤੋਂ ਬਿਨਾਂ, ਘੰਟਿਆਂ ਸੈਟਿੰਗਾਂ ਬਦਲਣ ਤੇ ਵੀ ਤੁਹਾਨੂੰ ਨਹੀ ਪਤਾ ਚੱਲੇਗਾ ਕਿ ਤੁਸੀਂ ਬਿਹਤਰੀ ਕੀਤੀ ਕਿ ਨਹੀਂ।
ਤਿੰਨ ਨੰਬਰ ਆਮਤੌਰ ਤੇ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ:
- p95 ਬੇਨਤੀ ਲੈਟਨਸੀ (ਔਸਤ ਨਹੀਂ)
- ਐਰਰ ਰੇਟ (HTTP 5xx, ਟਾਇਮਆਉਟ, ਕੈਂਸਲ)
- DB ਸਮਾਂ ਪ੍ਰਤੀ ਬੇਨਤੀ (ਹਰ ਬੇਨਤੀ Postgres ਉਤੇ ਕਿੰਨਾ ਸਮਾਂ ਉਡੀਕਦੀ ਹੈ)
p95 "ਖਰਾਬ ਦਿਨ" ਮੈਟ੍ਰਿਕ ਹੈ। ਜੇ p95 ਉੱਚਾ ਹੈ ਪਰ ਔਸਤ ਠੀਕ ਹੈ, ਤਾਂ ਕੁਝ ਛੋਟੀ ਬੇਨਤੀਆਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹਨ, ਲਾਕਾਂ 'ਤੇ ਫਸ ਰਹੀਆਂ ਹਨ, ਜਾਂ ਧੀਮੇ ਪਲਾਨ ਟ੍ਰਿਗਰ ਹੋ ਰਹੇ ਹਨ।
ਧੀਮੀ ਕਵੇਰੀਆਂ ਨੂੰ ਜਲਦੀ ਵਿਖਾਓ। Postgres ਵਿੱਚ ਪ੍ਰੀ-ਲਾਂਚ ਟੈਸਟਿੰਗ ਲਈ slow query logging ਘੱਟ ਥਰੇਸ਼ਹੋਲਡ ਨਾਲ ਚਾਲੂ ਕਰੋ (ਉਦਾਹਰਣ 100–200 ms) ਅਤੇ ਪੂਰਾ ਬਿਆਨ ਲੌਗ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਸਨੂੰ SQL ਕਲਾਇੰਟ ਵਿੱਚ ਕਾਪੀ ਕਰ ਸਕੋ। ਇਹ ਅਰਥਕਾਲੀ ਰੱਖੋ — ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਹਰ slow query ਲੌਗ ਕਰਨ ਨਾਲ ਸ਼ੋਰ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧਦਾ ਹੈ।
ਅਗਲੇ ਕਦਮ ਲਈ ਅਸਲੀ ਵਰਗੀ ਬੇਨਤੀਆਂ ਨਾਲ ਟੈਸਟ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ ਇੱਕ "hello world" ਰੂਟ। ਇੱਕ ਛੋਟਾ ਸੈੱਟ ਕਾਫੀ ਹੈ ਜੇ ਇਹ ਉਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਕਰਨਗੇ: ਫਿਲਟਰ ਅਤੇ ਸੋਰਟ ਵਾਲੀ ਲਿਸਟ ਕਾਲ, ਕੁਝ ਜੋਇਨਸ ਵਾਲਾ ਡੀਟੇਲ ਪੇਜ, ਵੈਲੀਡੇਸ਼ਨ ਨਾਲ ਇਕ ਬਣਾਉ/ਅਪਡੇਟ, ਅਤੇ ਪਾਰਸ਼ਲ ਮੈਚਜ਼ ਵਾਲੀ ਖੋਜ-ਸ਼ੈਲੀ ਕਵੇਰੀ।
ਜੇ ਤੁਸੀਂ ਸਪੈਕ ਤੋਂ ਐਂਡਪਾਇੰਟ ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ (ਉਦਾਹਰਣ Koder.ai ਵਰਗੀਆਂ ਟੂਲਾਂ ਨਾਲ), ਤਾਂ ਉਹੀ ਹੱਥ-ਕੰਮ ਵਾਲਾ ਸੈੱਟ ਮੁੜ-ਮੁੜ ਚਲਾਓ। ਇਸ ਤਰ੍ਹਾਂ ਇੰਡੀਕਸ, ਪੇਜੀਨੇਸ਼ਨ ਕੁਨਫਿਗ ਦਰਸ਼ਨੀ ਬਦਲਾਵਾਂ ਨੂੰ ਮਾਪ ਪਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਆਖਿਰ ਵਿੱਚ, ਇੱਕ ਉਮਰਦਾਰ ਲਕਸ਼ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਜਵਾਨ ਕਰ ਸਕੋ। ਉਦਾਹਰਣ: "ਅਧਿਕਤਰ ਬੇਨਤੀਆਂ 50 concurrent users 'ਤੇ p95 200 ms ਤਹਿਤ ਰਹਿਣ, ਅਤੇ ਐਰਰ 0.5% ਤੋਂ ਘੱਟ ਰਹਿਣ।" ਸਪਸ਼ਟ ਨੰਬਰ ਅਨੰਤ ਵਧ-ਚੜ੍ਹਾਈ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।
Postgres ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਲਈ ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ
ਕਨੈਕਸ਼ਨ ਪੂਲ ਇੱਕ ਸੀਮਿਤ ਗਿਣਤੀ ਖੁੱਲ੍ਹੀਆਂ ਡਾਟਾਬੇਸ ਕਨੈਕਸ਼ਨਾਂ ਰੱਖਦਾ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਮੁੜ ਵਰਤਦਾ ਹੈ। ਪੁਲ ਤੋਂ ਬਿਨਾਂ, ਹਰ ਬੇਨਤੀ ਇੱਕ ਨਵੀਂ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹ ਸਕਦੀ ਹੈ, ਅਤੇ Postgres ਸੈਸ਼ਨਾਂ ਪ੍ਰਬੰਧਨ ਕਰਕੇ ਸਮਾਂ ਅਤੇ ਮੈਮੋਰੀ ਖਰਚ ਕਰਦਾ ਹੈ।
ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ Postgres ਨੂੰ ਲੋੜੀਮੰਦ ਕੰਮ ਕਰਵਾਓ, ਨਾ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਕਨੈਕਸ਼ਨਾਂ ਵਿੱਚ context-switching ਕਰਨ ਦਿਓ। ਇਹ ਅਕਸਰ ਪਹਿਲਾ ਅਰਥਪੂਰਨ ਫਾਇਦਾ ਹੈ, ਵਿਸ਼ੇਸ਼ ਕਰਕੇ AI-ਜਨਰੇਟ ਕੀਤੀਆਂ APIs ਲਈ ਜੋ ਚੁਪਚਾਪ ਚੈਟੀ ਐਂਡਪਾਇੰਟ ਬਣ ਸਕਦੀਆਂ ਹਨ।
ਸਧਾਰਨ ਸ਼ੁਰੂਆਤੀ ਸੈਟਿੰਗਾਂ
Go ਵਿੱਚ ਤੁਸੀਂ ਆਮਤੌਰ 'ਤੇ max open connections, max idle connections, ਅਤੇ connection lifetime ਟਿਊਨ ਕਰਦੇ ਹੋ। ਛੋਟੇ APIs ਲਈ ਇੱਕ ਸੁਰੱਖਿਅਤ ਸ਼ੁਰੂਆਤ ਬਹੁਤ ਵਾਰੀ CPU ਕੋਰਾਂ ਦਾ ਛੋਟਾ ਗੁਣਾ ਹੁੰਦਾ ਹੈ (ਅਕਸਰ 5 ਤੋਂ 20 ਕਨੈਕਸ਼ਨ), ਇਨ੍ਹਾਂ ਦੇ ਨੇੜੇ idle ਗਿਣਤੀ, ਅਤੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਰੀਸਾਇਕਲ ਕਰਨਾ (ਉਦਾਹਰਣ 30–60 ਮਿੰਟ)।
ਜੇ ਤੁਸੀਂ ਕਈ API ਇੰਸਟੈਂਸ ਚਲਾ ਰਹੇ ਹੋ, ਯਾਦ ਰੱਖੋ ਕਿ ਪੂਲ ਗੁਣਾ ਹੋ ਜਾਂਦਾ ਹੈ। 20 ਕਨੈਕਸ਼ਨਾਂ ਵਾਲਾ ਪੂਲ 10 ਇੰਸਟੈਂਸਾਂ 'ਤੇ 200 ਕਨੈਕਸ਼ਨਾਂ ਬਣ ਜਾਂਦਾ ਹੈ — ਇਹੀ ਕਈ ਟੀਮਾਂ ਨੂੰ ਅਣਧਿਆਨਤ ਰੂਪ ਵਿੱਚ ਕਨੈਕਸ਼ਨ ਸੀਮਾਵਾਂ 'ਚ ਰੁਕਾਓ ਪੈਦਾ ਕਰ ਦਿੰਦਾ ਹੈ।
ਪੂਲ ਸਮੱਸਿਆ ਹੈ ਕਿ ਨਹੀਂ — ਪਛਾਣਣ ਦੇ ਤਰੀਕੇ
ਪੂਲ ਸਮੱਸਿਆਵਾਂ SQL ਦੇ ਧੀਮੇ ਹੋਣ ਤੋਂ ਵੱਖ ਦਿਸਦੀਆਂ ਹਨ।
-
ਜੇ ਪੂਲ ਬਹੁਤ ਛੋਟਾ ਹੈ, ਤਾਂ ਬੇਨਤੀਆਂ Postgres ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਉਡੀਕ ਕਰਨ ਲੱਗਦੀਆਂ ਹਨ। ਲੈਟਨਸੀ ਸਪਾਈਕ ਹੁੰਦੇ ਹਨ, ਪਰ ਡੀਬੀ CPU ਅਤੇ ਕਵੇਰੀ ਸਮਾਂ ਠੀਕ ਦਿਖ ਸਕਦੇ ਹਨ।
-
ਜੇ ਪੂਲ ਬਹੁਤ ਵੱਡਾ ਹੈ, ਤਾਂ Postgres ਓਵਰਲੋਡ ਹੋ ਜਾਂਦਾ ਹੈ: ਬਹੁਤ ਸਾਰੇ ਐਕਟਿਵ ਸੈਸ਼ਨ, ਮੈਮੋਰੀ ਦਬਾਅ, ਅਤੇ ਐਂਡਪਾਇੰਟਾਂ 'ਚ ਅਨਿਯਮਤ ਲੈਟਨਸੀ।
ਇਕ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਵੱਖ ਕਰਨ ਲਈ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ DB ਕਾਲਾਂ ਨੂੰ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਟਾਈਮ ਕਰੋ: ਕਿੰਨਾ ਸਮਾਂ ਕਨੈਕਸ਼ਨ ਲਈ ਉਡੀਕ ਹੋਈ ਅਤੇ ਕਿੰਨਾ ਸਮਾਂ ਕਵੇਰੀ ਚੱਲਣ ਵਿੱਚ ਲੱਗਾ। ਜੇ ਜ਼ਿਆਦਾ ਸਮਾਂ "ਉਡੀਕ" ਵਿੱਚ ਹੈ, ਤਾਂ ਪੂਲ ਬੋਤਲ-ਨੈਕ ਹੈ। ਜੇ ਜ਼ਿਆਦਾ ਸਮਾਂ "ਕਵੇਰੀ" ਵਿੱਚ ਹੈ, ਤਾਂ SQL ਅਤੇ ਇੰਡੀੈਕਸ 'ਤੇ ਧਿਆਨ ਦਿਓ।
ਫਟਾਫਟ ਚੈਕ:
- ਪੁਲ ਸਟੈਟਸ (open, in-use, idle) ਲੌਗ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕਿ in-use ਮੈਕਸ 'ਤੇ ਫਸਿਆ ਹੋਇਆ ਹੈ ਕਿ ਨਹੀਂ।
- ਕਨੈਕਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਨ 'ਤੇ timeout ਲਾਓ ਤਾਂ ਕਿ staging ਵਿੱਚ ਉਡੀਕ ਤੇਜ਼ੀ ਨਾਲ fail ਹੋ ਜਾਵੇ।
- Postgres ਵਿੱਚ active connections ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ ਅਤੇ
max_connectionsਦੇ ਨੇੜੇ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। - ਹਰ ਬੇਨਤੀ rows ਬੰਦ ਕਰਕੇ ਕਨੈਕਸ਼ਨ ਜਲਦੀ ਰੀਲੀਜ਼ ਕਰਦੀ ਹੋਈ ਯਕੀਨੀ ਬਣਾਓ।
- ਉਨ੍ਹਾਂ ਐਪ ਇੰਸਟੈਂਸਾਂ ਦੀ ਗਿਣਤੀ ਨਾਲ ਲੋਡ ਟੈਸਟ ਚਲਾਓ ਜੋ ਤੁਸੀਂ ਚਲਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਹੈ।
pgxpool vs database/sql
ਜੇ ਤੁਸੀਂ pgxpool ਵਰਤਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ Postgres-ਕੇਂਦ੍ਰਿਤ ਪੁਲ ਮਿਲਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਸਪਸ਼ਟ ਸਟੈਟਸ ਅਤੇ ਚੰਗੇ ਡੀਫੌਲਟ ਹੁੰਦੇ ਹਨ। database/sql ਇੱਕ ਸਟੈਂਡਰਡ ਇੰਟਰਫੇਸ ਦਿੰਦਾ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸਾਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਪੁਲ ਸੈਟਿੰਗਾਂ ਅਤੇ ਡਰਾਇਵਰ ਵਿਹੈਵਿਅਰ ਬਾਰੇ ਵਿਸਥਾਰਪੂਰਕ ਹੋਣਾ ਪੈਂਦਾ ਹੈ।
ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਪੂਰੇ ਤੌਰ 'ਤੇ Postgres 'ਤੇ ਹੋ ਅਤੇ ਸਿੱਧੇ ਕੰਟਰੋਲ ਚਾਹੁੰਦੇ ਹੋ, pgxpool ਅਕਸਰ ਸੁਧਰ ਹੈ। ਜੇ ਤੁਸੀਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਰਤਦੇ ਹੋ ਜੋ database/sql ਦੀ ਉਮੀਦ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਉਸੇ ਨੂੰ ਰੱਖੋ, ਪੁਲ ਸੈਟ explicit ਕਰੋ, ਅਤੇ ਉਡੀਕਾਂ ਨੂੰ ਮੈਜ਼ਰ ਕਰੋ।
ਉਦਾਹਰਣ: ਇੱਕ ਐਂਡਪਾਇੰਟ ਜੋ 20 ms ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਪਰ 100 concurrent users 'ਤੇ 2 s ਤੱਕ ਛੱਲ ਜਾਂਦਾ ਹੈ। ਜੇ ਲੌਗ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ 1.9 s ਕਨੈਕਸ਼ਨ ਲਈ ਉਡੀਕ ਸੀ, ਤਾਂ ਪੁਲ ਅਤੇ ਕੁੱਲ Postgres ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਠੀਕ ਕੀਤੇ ਬਿਨਾਂ ਕਵੇਰੀ ਟਿਊਨਿੰਗ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ।
Query planning: EXPLAIN ਆਉਟਪੁਟ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹਨਾ
ਜਦੋਂ ਕੋਈ ਐਂਡਪਾਇੰਟ ਧੀਮਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਵੇਖੋ ਕਿ Postgres ਅਸਲ ਵਿੱਚ ਕੀ ਕਰ ਰਿਹਾ ਹੈ। EXPLAIN ਦਾ ਇੱਕ ਛੋਟਾ ਜਾਹਲ-ਪੜ੍ਹਾਈ ਅਕਸਰ ਮਿੰਟਾਂ ਵਿੱਚ ਮੁਰੰਮਤ ਦੀ ਦਿਸ਼ਾ ਦਿੰਦਾ ਹੈ।
ਆਪਣੀ API ਵੱਲੋਂ ਭੇਜੇ ਗਏ ਬਿਲਕੁਲ ਇੱਕੋ SQL 'ਤੇ ਇਹ ਚਲਾਓ:
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, status, created_at
FROM orders
WHERE user_id = $1 AND status = $2
ORDER BY created_at DESC
LIMIT 50;
ਕੁਝ ਲਾਈਨਾਂ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ। ਊਪਰਲਾ ਨੋਡ (ਜੋ Postgres ਨੇ ਚੁਣਿਆ) ਅਤੇ ਨੀਵੇਂ totals (ਕਿੰਨਾ ਸਮਾਂ ਲੱਗਿਆ) ਦੇਖੋ। ਫਿਰ ਅਨੁਮਾਨਤ ਅਤੇ ਅਸਲ ਰੋਜ਼ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਵੱਡੇ ਫਰਕ ਅਕਸਰ planner ਦੀ ਗਲਤ ਅਨੁਮਾਨੀ ਦਰਸਾਉਂਦੇ ਹਨ।
ਮੁੱਖ ਲਾਈਨਾਂ ਦਾ ਸਧਾਰਨ ਮਤਲਬ
- Index Scan ਜਾਂ Index Only Scan: Postgres ਇੰਡੈਕਸ ਵਰਤ ਰਿਹਾ ਹੈ — ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੀ ਚੀਜ਼।
- Bitmap Heap Scan: ਮੱਧ-ਸਾਈਜ਼ ਮੇਚ ਲਈ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ।
- Seq Scan: ਪੂਰੀ ਟੇਬਲ ਪੜ੍ਹੀ ਗਈ — ਜਦ ਟੇਬਲ ਛੋਟੀ ਹੋਵੇ ਜਾਂ ਲਗਭਗ ਹਰ ਰਿਕਾਰਡ ਮੇਚ ਕਰ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਠੀਕ ਹੈ।
ਲਾਲ ਝੰਡੇ:
- ਵੱਡੀ ਟੇਬਲ 'ਤੇ Seq Scan
- ਅਨੁਮਾਨਤ ਰੋਜ਼ ਅਤੇ ਅਸਲ ਰੋਜ਼ ਵਿੱਚ ਵੱਡਾ ਫਰਕ
ORDER BYਨਾਲ ਜੁੜਿਆ Sort ਜੋ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈ ਰਿਹਾ ਹੈ- "Filter:" ਬਾਅਦ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਰੋਜ਼ ਹਟਾਏ ਜਾ ਰਹੇ ਹਨ
- BUFFERS ਵਿੱਚ ਉੱਚ shared read blocks (ਵੱਡਾ ਡੇਟਾ ਪੜ੍ਹਿਆ ਗਿਆ)
ਪਲਾਨ ਕਿਉਂ ਗਲਤ ਹੋ ਜਾਂਦੇ ਹਨ (ਅਤੇ ਆਸਾਨ ਫਿਕਸ)
ਧੀਮੇ ਪਲਾਨ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਨਮੂਨਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ:
- ਤੁਹਾਡੇ
WHERE+ORDER BYਪੈਟਰਨ ਲਈ ਗੁੰਮ ਇੰਡੈਕਸ - ਟਾਈਪਾਂ ਦਾ ਮਿਲਾਪ ਨਾ ਹੋਣਾ (ਉਦਾਹਰਣ, UUID ਕਾਲਮ ਦੀ ਤੁਲਨਾ text ਪੈਰਾਮੀਟਰ ਨਾਲ), ਜਿਸ ਨਾਲ ਇੰਡੈਕਸ ਵਰਤੋਂ ਰੁਕ ਸਕਦੀ ਹੈ
WHEREਵਿੱਚ ਫੰਕਸ਼ਨਾਂ ਦਾ ਉਪਯੋਗ (ਉਦਾਹਰਣWHERE lower(email) = $1), ਜਿਹੜੇ scans ਨੂੰ ਮਜਬੂਰ ਕਰ ਦਿੰਦੇ ਹਨ ਜਦ ਤਕ ਤੁਸੀਂ ਮਿਲਦਾ-ਜੁਲਦਾ expression index ਨਾ ਜੋੜੋ
ਜੇ ਪਲਾਨ ਅਜੀਬ ਲੱਗਦਾ ਹੈ ਅਤੇ ਅਨੁਮਾਨ ਬਹੁਤ ਘੁੱਟ ਜਾਂ ਵੱਧ ਹਨ, ਤਾਂ stats ਅਕਸਰ stale ਹੁੰਦੇ ਹਨ। ANALYZE ਚਲਾਓ (ਜਾਂ autovacuum ਨੂੰ catch up ਕਰਨ ਦਿਓ) ਤਾਂ ਕਿ Postgres ਮੌਜੂਦਾ ਰੋਜ਼ ਗਿਣਤੀ ਅਤੇ value distribution ਸਿੱਖ ਲਏ। ਇਹ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਬੜੀ ਇੰਪੋਰਟਾਂ ਜਾਂ ਨਵੇਂ ਐਂਡਪਾਇੰਟਾਂ ਦੇ ਓਲੇਖ 'ਤੇ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।
ਉਹ ਕਿਵੇਂ ਇੰਡੀੈਕਸ ਬਣਾਓ ਜੋ ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਜਾਂ
ਬਿਲਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰदਰਸ਼ਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ
ਕੋਡ ਜਨਰੇਟ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਫਿਲਟਰ, ਸੋਰਟ ਅਤੇ ਪੇਜੀਨੇਸ਼ਨ ਨਿਰਧਾਰਿਤ ਕਰਨ ਲਈ Planning Mode ਵਰਤੋਂ।
ਇੰਡੀੈਕਸ ਕੇਵਲ ਉਸ ਸਮੇਂ ਫਾਇਦਾ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਤੁਹਾਡੇ API ਦੀ ਪ੍ਰਸ਼ਨ-ਸ਼ੈਲੀ ਨਾਲ ਮਿਲਦੇ ਹਨ। ਅਨੁਮਾਨ ਤੇ ਆਧਾਰਿਤ ਇੰਡੀੈਕਸ ਬਣਾਉਣ ਨਾਲ ਤੁਹਾਡੇ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੋਹਾਂ 'ਤੇ ਨੁਕਸਾਨ ਹੋ ਸਕਦਾ ਹੈ।
ਇੱਕ ਵਰਤੋਂਯੋਗ ਸੋਚ ਇਹ ਹੈ: ਇੱਕ ਇੰਡੀੈਕਸ ਇੱਕ ਖਾਸ ਸਵਾਲ ਲਈ شارਟਕਟ ਹੈ। ਜੇ ਤੁਹਾਡੀ API ਵੱਖਰਾ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ, Postgres ਉਹ شارਟਕਟ ਅਣਦੇਖਾ ਕਰ ਦੇਵੇਗਾ।
ਫਿਲਟਰ + ਸੋਰਟ ਆਧਾਰ 'ਤੇ ਇੰਡੀੈਕਸ ਬਣਾਓ
ਜੇ ਇੱਕ ਐਂਡਪਾਇੰਟ account_id 'ਤੇ ਫਿਲਟਰ ਕਰਦਾ ਹੈ ਅਤੇ created_at DESC ਨਾਲ ਸੋਰਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਕੰਪੋਜ਼ਿਟ ਇੰਡੈਕਸ ਅਕਸਰ ਦੋ ਵੱਖ-ਵੱਖ ਇੰਡੈਕਸਾਂ ਤੋਂ ਵਧੀਆ ਹੁੰਦਾ ਹੈ। ਇਹ Postgres ਨੂੰ ਘੱਟ ਕੰਮ ਵਿੱਚ ਠੀਕ ਰੋਜ਼ ਲੱਭਣ ਅਤੇ ਠੀਕ ਕ੍ਰਮ 'ਚ ਵਾਪਸ ਕਰਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਰੂਲ ਆਮ ਤੌਰ 'ਤੇ:
- ਉਹ ਕਾਲਮ ਇੰਡੈਕਸ ਕਰੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਵੱਧ ਫਿਲਟਰ ਕਰਦੇ ਹੋ, ਫਿਰ ਜੋ ਕਾਲਮ ਸੋਰਟ ਕਰਦਾ ਹੈ ਉਹ ਜੋੜੋ।
- ਕੰਪੋਜ਼ਿਟ ਇੰਡੈਕਸ ਛੋਟੇ ਰੱਖੋ। 2 ਕਾਲਮ ਆਮ, 3 ਕਦੇ-ਕਦੇ; ਬੇਸ਼ਕ ਹੋਰ ਵੱਧ ਹੋਣ 'ਤੇ ਸੰਦੇਹਜਨਕ ਹੈ।
- ਸਭ ਤੋਂ ਸਿਲੈਕਟਿਵ ਫਿਲਟਰ ਪਹਿਲੇ ਰੱਖੋ।
- ਉਹਨਾਂ ਅਲੱਗ ਇੰਡੈਕਸਾਂ ਤੋਂ ਬਚੋ ਜਿਹੜੇ ਇੱਕ ਬਹੁਤ ਚੰਗੇ ਕੰਪੋਜ਼ਿਟ ਇੰਡੈਕਸ ਨਾਲ ਕਵਰ ਹੋ ਸਕਦੇ ਹਨ।
- ਇੱਕ ਚੰਗਾ ਚੁਣਿਆ ਹੋਇਆ ਇੰਡੈਕਸ ਕਈ "ਸ਼ਾਇਦ ਲਾਭ" ਵਾਲੇ ਇੰਡੈਕਸਾਂ ਤੋਂ ਬਿਹਤਰ ਹੈ।
ਉਦਾਹਰਣ: ਜੇ ਤੁਹਾਡੀ API GET /orders?status=paid ਕਰਦੀ ਹੈ ਅਤੇ ਹਮੇਸ਼ਾ ਸਭ ਤੋਂ ਨਵੇਂ ਦਿਖਾਉਂਦੀ ਹੈ, ਤਾਂ (status, created_at DESC) ਵਰਗਾ ਇੰਡੀੈਕਸ ਅਚ্ছে ਨਾਲ ਫਿੱਟ ਹੁੰਦਾ ਹੈ। ਜੇ ਅਕਸਰ ਲੁੜਾਈ customer_id ਨਾਲ ਵੀ ਹੋਵੇ, ਤਾਂ (customer_id, status, created_at) ਵਧੀਆ ਹੋ ਸਕਦਾ ਹੈ — ਪਰ ਇਹ ਸਿਰਫ਼ ਉਹਨਾਂ ਹੀ ਹਾਲਤਾਂ ਵਿੱਚ ਹੈ ਜਦੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਅਸਲ ਕਵੇਰੀ ਅਜਿਹਾ ਚਲਦੀ ਹੈ।
ਆਮ ਫਾਇਦੇ ਲਈ partial indexes
ਜੇ ਜ਼ਿਆਦਾਤਰ ਟ੍ਰੈਫਿਕ ਇੱਕ ਤੰਗ ਸਲਾਈਸ ਨੂੰ ਹਿੱਟ ਕਰਦਾ ਹੈ, ਤਾਂ partial index ਸਸਤਾ ਅਤੇ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ, ਜੇ ਤੁਹਾਡੀ ਐਪ ਮੁੱਖ ਤੌਰ active ਰਿਕਾਰਡ ਪੜ੍ਹਦੀ ਹੈ, ਤਾਂ ਸਿਰਫ਼ WHERE active = true ਵਾਲਾ ਇੰਡੀੈਕਸ ਛੋਟਾ ਰਹੇਗਾ ਅਤੇ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿਣ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧੇਗੀ।
ਇੰਡੀੈਕਸ ਮਦਦਗਾਰ ਹੈ ਕਿ ਨਹੀਂ, ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ: EXPLAIN ਚਲਾਓ ਅਤੇ ਦੇਖੋ ਕਿ ਇੰਡੈਕਸ ਸਕੈਨ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਉਹੀ ਕੰਵੇਂਸ਼ਨ ਅਨੁਸਾਰ ਆ ਰਿਹਾ ਹੈ ਕਿ ਨਹੀਂ।
ਬਿਨ ਲੋੜ ਦੇ ਇੰਡੈਕਸ ਧੀਰੇ-ਧੀਰੇ ਹਟਾਓ। ਵਰਤੋਂ ਸਟੈਟਸ ਜਾਂ ਇਸਦੀ ਸਕੈਨ ਰਹਿਤਤਾ ਚੈਕ ਕਰੋ। ਇੱਕ-ਇੱਕ ਕਰਕੇ ਡਰੌਪ ਕਰੋ ਅਤੇ ਨੀචੇ-ਰਿਸਕ ਬਿਨਾਂ ਵਿੰਡੋ 'ਤੇ ਕਰੋ, ਅਤੇ ਰੋਲਬੈਕ ਯੋਜਨਾ ਰੱਖੋ। ਅਣਵਰਤ ਇੰਡੈਕਸ ਨਿਰਾਥਕ ਨਹੀਂ — ਉਹ writes (inserts/updates) ਕ ਨੂੰ ਹਰੇਕ ਲਿਖਾਈ ਤੇ ਸਲੋ ਕਰਦੇ ਹਨ।
ਪੇਜੀਨੇਸ਼ਨ ਪੈਟਰਨ ਜੋ ਸਮੇਂ ਨਾਲ ਧੀਮੇ ਨਹੀਂ ਪੈਂਦੇ
ਪੇਜੀਨੇਸ਼ਨ ਅਕਸਰ ਉਹ ਜਗ੍ਹਾ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਇੱਕ ਤੇਜ਼ API ਧੀਮਾ ਮਹਿਸੂਸ ਹੋਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਡਾਟਾਬੇਸ ਸਿਹਤਮੰਦ ਹੋਵੇ। ਪੇਜੀਨੇਸ਼ਨ ਨੂੰ UI ਵੇਰਵਾ ਦੀ ਥਾਂ ਕਵੇਰੀ ਡਿਜ਼ਾਈਨ ਸਮਝੋ।
LIMIT/OFFSET ਕਿਉਂ ধੀਮਾ ਹੋ ਜਾਂਦਾ ਹੈ
LIMIT/OFFSET ਸਧਾਰਨ ਲੱਗਦਾ ਹੈ, ਪਰ ਡੂੰਘੀਆਂ ਪੇਜਾਂ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਖ਼ਰਚੀਲੀ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। Postgres ਨੂੰ ਉਹਨਾਂ ਰੋਜ਼ਾਂ ਦੇ ਕੋਲੋਂ ਗੁਜ਼ਰਨਾ ਪੈਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸਕਿਪ ਕਰ ਰਹੇ ਹੋ। ਪੇਜ 1 ਕੁਝ ਦਰਜਨ ਰੋਜ਼ ਹਿੱਟ ਕਰ ਸਕਦੀ ਹੈ; ਪੇਜ 500 ਨੂੰ ਵਾਪਸ 20 ਰਿਜ਼ਲਟ ਦੇਣ ਲਈ ਦਸ ਹਜ਼ਾਰਾਂ ਰੋਜ਼ਾਂ ਪੜ੍ਹਣ ਅਤੇ ਡਿਸਕਾਰਡ ਕਰਨੇ ਪੈ ਸਕਦੇ ਹਨ।
ਇਸ ਨਾਲ ਨਤੀਜੇ ਅਸਥਿਰ ਵੀ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਦਰਮਿਆਨ ਰਿਕਾਰਡ ਸ਼ਾਮਲ ਜਾਂ ਹਟਾਏ ਜਾਂਦੇ ਹਨ—ਯੂਜ਼ਰਜ਼ ਨੂੰ ਦੁਹਰਾਏ ਜਾਂ ਛੱਡੇ ਆਈਟਮ ਦਿਸ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ "row 10,000" ਦੀ ਮਾਇਨੇ ਬਦਲ ਜਾਂਦੀ ਹੈ।
Keyset pagination (cursor) — "last seen" ਉਦਾਹਰਣ
Keyset pagination ਇੱਕ ਵੱਖਰਾ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ: "ਮੈਨੂੰ ਉਹ ਅਗਲੇ 20 ਰੋਜ਼ ਦੇ ਦਿਓ ਜੋ ਮੈਂ ਅਖੀਰ ਵਿੱਚ ਵੇਖੇ ਸਨ।" ਇਸ ਨਾਲ ਡੇਟਾਬੇਸ ਇੱਕ ਛੋਟਾ, ਸਥਿਰ ਸਲਾਈਸ ਕੰਮ ਕਰਦਾ ਹੈ।
ਸਧਾਰਣ ਵਰਜ਼ਨ ਇੱਕ ਵਧਦੇ id ਵਰਤਦਾ ਹੈ:
SELECT id, created_at, title
FROM posts
WHERE id > $1
ORDER BY id
LIMIT 20;
API next_cursor ਵਾਪਸ ਕਰਦਾ ਹੈ ਜੋ ਪੇਜ਼ ਵਿੱਚ ਆਖਰੀ id ਦੇ ਬਰਾਬਰ ਹੁੰਦਾ ਹੈ। ਅਗਲੀ ਬੇਨਤੀ ਉਹੀ $1 ਵਰਤਦੀ ਹੈ।
ਸਮੇਂ-ਆਧਾਰਿਤ ਸੋਰਟਿੰਗ ਲਈ, ਇੱਕ ਸਥਿਰ ਕ੍ਰਮ ਅਤੇ tie-breaker ਵਰਤੋ। created_at ਇਕੱਲਾ ਕਦੇ ਕਦੇ ਕਾਫੀ ਨਹੀਂ ਹੁੰਦਾ ਜੇ ਦੋ ਰਿਕਾਰਡਾਂ ਦਾ ਸਮਾਂ ਇਕੋ ਜਿਹਾ ਹੋਵੇ। ਇੱਕ ਸੰਯੁਕਤ ਕਰਸਰ ਵਰਗਾ:
WHERE (created_at, id) < ($1, $2)
ORDER BY created_at DESC, id DESC
LIMIT 20;
ਕੁਝ ਨਿਯਮ duplicates ਅਤੇ missing rows ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ:
- ਹਮੇਸ਼ਾ
ORDER BYਵਿੱਚ ਇਕ ਯੂਨੀਕ tie-breaker ਸ਼ਾਮਲ ਕਰੋ (ਆਮ ਤੌਰ 'ਤੇid)। - ਹਰ ਬੇਨਤੀ ਲਈ sort order ਇੱਕੋ ਜਿਹਾ ਰੱਖੋ।
- ਕਰਸਰ ਨੂੰ ਕਲਾਇੰਟਾਂ ਲਈ opaque ਰੱਖੋ (created_at ਅਤੇ id ਨੂੰ ਇੱਕਠੇ encode ਕਰੋ)।
- ਜੇ ਯੂਜ਼ਰ ਫਿਲਟਰ ਕਰ ਸਕਦੇ ਹਨ, ਤਾਂ ਹਰੇਕ ਪੰਨੀ 'ਤੇ ਉਹੀ ਫਿਲਟਰ ਲਾਗੂ ਕਰੋ।
- ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਅਪਰਿਵਰਤਨੀ (immutable) ਸੋਰਟ ਫੀਲਡਾਂ ਵਰਤੋਂ (created time)mutable (status, score) ਤੋਂ ਉੱਤੇ ਤਰਜੀਹ ਦਿਓ।
JSON ਸ਼ੇਪਿੰਗ: ਛੋਟੇ ਪੇਲੋਡ ਨਾਲ ਤੇਜ਼ ਜਵਾਬ
ਤੇਜ਼ੀ ਨਾਲ Go API ਬਣਾਓ
ਆਪਣੇ ਐਂਡਪਇੰਟ ਵਰਣਨ ਕਰੋ ਅਤੇ ਉਹ Go + Postgres ਸਰਵਿਸ ਪ੍ਰਾਪਤ ਕਰੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਅਸਲ ਟ੍ਰੈਫਿਕ ਨਾਲ ਟਿਊਨ ਕਰ ਸਕੋ।
ਹਰ ਵਾਰੀ ਡਾਟਾਬੇਸ ਹੀ ਕਾਰਨ ਨਹੀਂ ਹੁੰਦਾ। ਵੱਡਾ JSON ਬਣਾਉਣਾ, ਭੇਜਣਾ ਤੇ ਕਲਾਇੰਟ ਵਲੋਂ ਪਾਰਸ ਕਰਵਾਉਣਾ ਲੰਮਾ ਸਮਾਂ ਲੈਂਦਾ ਹੈ। ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲਣ ਵਾਲਾ ਨਤੀਜਾ ਅਕਸਰ ਘੱਟ ਵਾਪਸ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।
ਆਪਣੇ SELECT ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਐਂਡਪਾਇੰਟ ਨੂੰ ਸਿਰਫ਼ id, name, ਅਤੇ status ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਉਹੀ ਕਾਲਮ ਮੰਗੋ। SELECT * ਟੇਬਲ ਤੇ ਲੰਮੇ ਟੈਕਸਟ, JSON ਬਲੌਬ, ਅਤੇ ਆਡਿਟ ਕਾਲਮਾਂ ਦੇ ਨਾਲ ਸਮੇਂ ਦੇ ਨਾਲ ਭਾਰੀ ਹੋ ਜਾਂਦਾ ਹੈ।
ਹੋਰ ਘੰਟੀ ਵਾਲਾ ਧੀਮਾਪਨ N+1 ਰਿਸਪਾਂਸ ਬਣਾਣਾ ਹੈ: ਤੁਸੀਂ 50 ਆਈਟਮ ਲਿਆਉਂਦੇ ਹੋ, ਫਿਰ 50 ਹੋਰ ਕਵੇਰੀਆਂ ਚਲਾਉਂਦੇ ਹੋ ਸੰਬੰਧਿਤ ਡੇਟਾ ਲਈ। ਇਹ ਟੈਸਟ ਪਾਸ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਅਸਲ ਟ੍ਰੈਫਿਕ ਹੇਠ ਢਹਿ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਇਕਲ ਕਵੇਰੀ ਜੋ ਤੁਹਾਨੂੰ ਜ਼ਰੂਰੀ ਡੇਟਾ ਦਿੰਦੀ ਹੈ (ਧਿਆਨ ਨਾਲ joins), ਜਾਂ IDs ਨਾਲ ਦੂਜੀ ਬੈਚ ਕਵੇਰੀ ਪਸੰਦ ਕਰੋ।
payload ਛੋਟਾ ਰੱਖਣ ਦੇ ਕੁਝ ਤਰੀਕੇ:
include=ਫਲੈਗ ਜਾਂfields=ਮਾਸਕ ਵਰਤੋਂ ਤਾਂ ਕਿ ਲਿਸਟ ਜਵਾਬ ਹਲਕਾ ਰਹੇ ਅਤੇ детали ਓਪਟ-ਇਨ ਹੋਣ।- nested arrays ਨੂੰ ਕੈਪ ਕਰੋ (ਜਿਵੇਂ ਸਿਰਫ਼ ਨਵੇਂ 10 events) ਅਤੇ ਪੂਰੀ history ਲਈ ਵੱਖਰਾ ਐਂਡਪਾਇੰਟ ਦਿਓ।
- ਜੇ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸਿਰਫ਼ ਕੁਝ ਕੀ-ਵੈਲਯੂਜ਼ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਅੰਦਰੂਨੀ JSON ਕਾਲਮ ਰੀਟਰਨ ਨਾ ਕਰੋ।
- ਲੰਮੇ labels ਦੀ ਦੁਹਰਾਈ ਦੀ ਥਾਂ ਛੋਟੇ ਕੋਡ ਵਰਤੋਂ।
Postgres ਵਿੱਚ JSON ਬਣਾਉਣਾ ਜਾਂ Go ਵਿੱਚ?
ਦੋਹਾਂ ਤੇਜ਼ ਹੋ ਸਕਦੇ ਹਨ। ਕਿਹੜੇ ਲਈ ਚੁਣੋ ਇਹ ਇਸ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਚੀਜ਼ ਲਈ ਟਿਊਨ ਕਰ ਰਹੇ ਹੋ।
Postgres JSON functions (jsonb_build_object, json_agg) ਉਪਯੋਗੀ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਘੱਟ ਰਾਊਂਡ ਟ੍ਰਿਪਸ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਇੱਕ ਕਵੇਰੀ ਤੋਂ ਪਿਛੋਕੜ ਆਕਾਰ ਦੀ ਉਮੀਦ ਹੈ। Go ਵਿੱਚ ਸ਼ੇਪਿੰਗ ਉਨ੍ਹਾਂ ਹਾਲਤਾਂ ਲਈ ਚੰਗੀ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਸ਼ਰਤਾਂ ਤੇ ਆਧਾਰਿਤ ਤਰਕ (conditional logic), struct reuse, ਜਾਂ ਸੌਖਾ SQL ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਜੇ SQL ਵਿੱਚ JSON-ਬਿਲਡਿੰਗ ਬਹੁਤ ਔਖਾ ਹੋ ਜਾਵੇ, ਤਾਂ ਉਹ ਟਿਊਨ ਕਰਨਾ ਵੀ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਚੰਗਾ ਰੀਅਲ-ਵਰਕ ਰੂਲ: Postgres ਨੂੰ ਫਿਲਟਰ, ਸੋਰਟ ਅਤੇ aggregate ਕਰਨ ਦਿਓ। ਫਿਰ Go ਨੂੰ ਅਖੀਰੀ ਪ੍ਰਸਤੁਤੀ ਹੱਥ ਵਿੱਚ ਦਿਓ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ APIs ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ (ਉਦਾਹਰਣ Koder.ai), ਤਾਂ ਸ਼ੁਰੂ ਵਿੱਚ include flags ਜੋੜਨਾ endpoints ਨੂੰ ਭਾਰੀਆ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਫੀਲਡਸ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਹਰ ਜਵਾਬ ਨੂੰ ਭਾਰੀ ਬਣਾਉਂਦੇ।
ਪਹਿਲੇ ਯੂਜ਼ਰਾਂ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਕਦਮ-ਦਰ-ਕਦਮ ਟਿਊਨ ਪਾਸ
ਤੁਹਾਨੂੰ ਵੱਡਾ ਲੈਬ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਦਰਸ਼ਨ ਮੁੱਿਆਂ ਨੂੰ ਫੜ ਸਕੋ। ਇੱਕ ਛੋਟਾ, ਦੁਹਰਾਅਯੋਗ ਪਾਸ ਉਹ ਸਮੱਸਿਆਵਾਂ(surface) ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਟ੍ਰੈਫਿਕ ਆਉਣ 'ਤੇ ਆਉਟੇਜ ਬਣ ਸਕਦੀਆਂ ਹਨ, ਖ਼ਾਸਕਰ ਜਦੋਂ ਮੁਢਲਾ ਕੋਡ ਜਨਰੇਟ ਕੀਤਾ ਗਿਆ ਹੋਵੇ।
ਕੁਝ ਮੂਲ ਬੇਸਲਾਈਨ ਲਿਖੋ:
- ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਵਿਆਸਤ ਐਂਡਪਾਇੰਟਾਂ ਲਈ p95 ਅਤੇ p99 ਲੈਟਨਸੀ
- ਐਰਰ ਰੇਟ ਅਤੇ ਟਾਇਮਆਉਟ
- ਡੇਟਾਬੇਸ CPU ਅਤੇ ਐਕਟਿਵ ਕਨੈਕਸ਼ਨ
- ਕੁੱਲ ਸਮੇਂ ਦੇ ਆਧਾਰ 'ਤੇ ਸਭ ਤੋਂ ਧੀਮੀਆਂ 5 ਕਵੇਰੀਆਂ
ਟਿਊਨ ਪਾਸ
-
10-15 ਮਿੰਟ ਦਾ ਲੋਡ ਟੈਸਟ ਚਲਾਓ ਜੋ ਅਸਲੀ ਵਰਤੋਂ ਵਰਗਾ ਲੱਗੇ। ਉਨ੍ਹਾਂ ਐਂਡਪਾਇੰਟਾਂ 'ਤੇ ਹਿੱਟ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਪਹਿਲੇ ਯੂਜ਼ਰ ਹਿੱਟ ਕਰਨਗੇ (login, list pages, search, create)। ਫਿਰ routes ਨੂੰ p95 ਲੈਟਨਸੀ ਅਤੇ ਕੁੱਲ ਸਮੇਂ ਅਨੁਸਾਰ ਛਾਂਟੋ।
-
SQL ਟਿਊਨਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਕਨੈਕਸ਼ਨ ਦਬਾਅ ਦੀ ਜਾਂਚ ਕਰੋ। ਇਕ ਵੱਡਾ ਪੁਲ Postgres ਨੂੰ ਓਵਰਵਹਲਮ ਕਰ ਸਕਦਾ ਹੈ; ਛੋਟਾ ਪੁਲ ਉਡੀਕ ਬਣਾਉਂਦਾ ਹੈ। ਉਡੀਕ ਸਮਾਂ ਜੀ ਵਿੱਚ ਵੱਧਣ 'ਤੇ ਪੁਲ ਅਤੇ idle ਲਿਮਿਟਸ ਐਡਜਸਟ ਕਰੋ, ਫਿਰ ਮੁੜ ਟੈਸਟ ਕਰੋ।
-
ਸਭ ਤੋਂ ਧੀਮੀ ਕਵੇਰੀਆਂ
EXPLAINਕਰੋ ਅਤੇ ਸਭ ਤੋਂ ਵੱਡੇ ਲਾਲ ਝੰਡੇ ਨੂੰ ਠੀਕ ਕਰੋ। ਆਮ ਦੋਸ਼: ਵੱਡੀਆਂ ਟੇਬਲਾਂ 'ਤੇ ਫੁੱਲ ਸਕੈਨ, ਵੱਡੇ ਰਿਜ਼ਲਟ ਸੈੱਟਾਂ 'ਤੇ sorts, ਅਤੇ joins ਜੋ ਰੋਜ਼ ਗਿਣਤੀ ਨੂੰ ਫਾਹਾੜ ਦਿੰਦੇ ਹਨ। ਇੱਕ-ਇੱਕ ਕਰਕੇ ਸਭ ਤੋਂ ਵੱਡੀ ਕਵੇਰੀ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਬੋਰੀੰਗ (ਸਧਾਰਨ ਤੇ ਭਰੋਸੇਯੋਗ) ਬਣਾਓ। -
ਇੱਕ ਇੰਡੈਕਸ ਜੋੜੋ ਜਾਂ ਢੁੰਗ ਬਦਲੋ, ਫਿਰ ਮੁੜ ਟੈਸਟ ਕਰੋ। ਇੰਡੈਕਸ ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਤੁਹਾਡੇ
WHEREਅਤੇORDER BYਨਾਲ ਮਿਲਦੇ ਹਨ। ਪੰਜ ਇੰਡੀੈਕਸ ਇਕੱਠੇ ਨਾ ਜੋੜੋ — ਇੱਕ-ਇੱਕ ਕਰੋ ਅਤੇ ਪ੍ਰਭਾਵ ਮਾਪੋ। -
ਰਿਸਪਾਂਸਾਂ ਅਤੇ ਪੇਜੀਨੇਸ਼ਨ ਨੂੰ ਤਿੱਖਾ ਕਰੋ, ਫਿਰ ਮੁੜ ਟੈਸਟ ਕਰੋ। ਜੇ ਕੋਈ ਐਂਡਪਾਇੰਟ 50 ਰੋਜ਼ ਵੱਡੇ JSON ਬਲੌਬ ਰਿਹਾ ਹੈ, ਤਾਂ ਡੀਬੀ, ਨੈਟਵਰਕ ਅਤੇ ਕਲਾਇੰਟ ਤਿੰਨੋਂ ਨੂੰ ਖ਼ਰਚ ਮਿਲੇਗਾ। ਸਿਰਫ਼ UI ਲਈ ਲੋੜੀਦੇ ਫੀਲਡ ਰਿਟਰਨ ਕਰੋ, ਅਤੇ ਉਹ ਪੇਜੀਨੇਸ਼ਨ ਪਹੁੰਚ ਪ੍ਰਯੋਗ ਕਰੋ ਜੋ ਟੇਬਲ ਵਧਣ ਤੇ ਧੀਮੀ ਨਾ ਹੋਵੇ।
ਸਧਾਰਨ ਚੇਨਲੌਗ ਰੱਖੋ: ਕਿਹੜੀ ਬਦਲਾਅ ਕੀਤੀ, ਕਿਉਂ ਕੀਤੀ, ਅਤੇ p95 'ਚ ਕੀ ਬਦਲਿਆ। ਜੇ ਕੋਈ ਬਦਲਾਅ ਤੁਹਾਡੇ ਬੇਸਲਾਈਨ ਨੂੰ ਸੁਧਾਰਦਾ ਨਹੀਂ, ਤਾਂ ਵਾਪਸ ਲੈ ਜਾਓ ਅਤੇ ਅੱਗੇ ਵਧੋ।
ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਜਾਲ ਜਿਨ੍ਹਾਂ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ
ਬੇਫਿਕਰਤਾ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰੋ
ਇੰਡੈਕਸ ਜਾਂ ਕਵੇਰੀ ਬਦਲੋ, p95 ਮਾਪੋ, ਅਤੇ ਜੇ ਇਹ ਹੋਰ ਰੂਟਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪੁੰਚਾਏ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਲੈ ਜਾਓ।
ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ Go APIs ਤੇ Postgres 'ਤੇ ਆਪਣੇ ਬਣਾਏ ਹੋਏ ਹੁੰਦੀਆਂ ਹਨ। ਚੰਗੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕੁਝ ਚੈੱਕ ਜ਼ਿਆਦਾ ਤਰ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਫੜ ਲੈਂਦੇ ਹਨ।
ਇੱਕ ਕਲਾਸਿਕ ਜਾਲ ਹੈ ਪੁਲ ਸਾਈਜ਼ ਨੂੰ "ਤੇਜ਼ੀ ਕਨੋਬ" ਵਾਂਗ ਵਰਤਣਾ। ਇਸਨੂੰ "ਜਿੰਨਾ ਵੱਡਾ ਹੋ ਸਕਦਾ" ਰੱਖਣਾ ਅਕਸਰ ਸਭ ਕੁਝ ਹੋਰ ਧੀਮਾ ਕਰ ਦਿੰਦਾ। Postgres ਵੱਧ ਸਮਾਂ ਸੈਸ਼ਨਾਂ, ਮੈਮੋਰੀ, ਅਤੇ ਲੌਕਾਂ ਵਿੱਚ ਗੁਜਾਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਲਹਿਰਾਂ ਵਿੱਚ ਟਾਇਮਆਉਟ ਹੋਣ ਲੱਗਦੀ ਹੈ। ਇੱਕ ਛੋਟਾ, ਸਥਿਰ ਪੁਲ ਜਿਸਦੀ concurrency ਅਨੁਮਾਨਯੋਗ ਹੈ ਅਕਸਰ ਜਿੱਤਦਾ ਹੈ।
ਹੋਰ ਆਮ ਗਲਤੀ "ਹਰ ਚੀਜ਼ ਨੂੰ ਇੰਡੀੈਕਸ ਕਰੋ" ਹੈ। ਵਾਧੂ ਇੰਡੀੈਕਸ ਪੜ੍ਹਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਲਿਖਾਈਆਂ ਨੂੰ ਸੈੰਕਦੇ ਹਨ ਅਤੇ ਕਦੇ-ਕਦੇ ਕਵੇਰੀ ਪਲਾਨ ਨੂੰ ਅਚਾਨਕ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ API ਬਹੁਤ ਲਿਖਦੀ ਹੈ (inserts/updates), ਤਾਂ ਹਰ ਨਵੇਂ ਇੰਡੈਕਸ ਨਾਲ ਲਿਖਾਈ ਦਾ ਕੰਮ ਵੱਧਦਾ ਹੈ। ਮਾਪੋ ਪਹਿਲਾਂ ਅਤੇ ਇੰਡੈਕਸ ਜੋੜਨ ਤੋਂ ਬਾਦ plans ਰੀ-ਚੈੱਕ ਕਰੋ।
ਪੇਜੀਨੇਸ਼ਨ ਜੋਨਾਂ ਧੀਰੇ-ਧੀਰੇ ਆਉਂਦੀ ਹੈ। OFFSET ਪੇਜੀਨੇਸ਼ਨ ਸ਼ੁਰੂ 'ਚ ਠੀਕ ਲੱਗਦੀ ਹੈ, ਪਰ ਸਮੇਂ ਨਾਲ p95 ਵਧਦਾ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਵੱਧ ਰੋਜ਼ਾਂ ਪਾਸ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
JSON payload ਆਕਾਰ ਇੱਕ ਹੋਰ ਛੁਪਿਆ ਟੈਕਸ ਹੈ। ਕੰਪ੍ਰੈਸ਼ਨ ਬੈਂਡਵਿਡਥ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਬੜੇ ਆਬਜੈਕਟ ਬਣਾਉਣ ਅਤੇ ਪਾਰਸ ਕਰਨ ਦੀ ਲਾਗਤ ਨਹੀਂ ਹਟਾਉਂਦਾ। ਖੇਤਰ ਘਟਾਓ, ਡੀਪ ਨੈਸਟਿੰਗ ਤੋਂ ਬਚੋ, ਅਤੇ ਸਿਰਫ਼ ਜੋ ਸਕ੍ਰੀਨ ਨੂੰ ਲੋੜੀਦਾ ਹੈ ਉਹੀ ਵਾਪਸ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਔਸਤ ਲੈਟਨਸੀ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਸ ਜਗ੍ਹਾ ਨੂੰ ਛੱਡ ਦਿਓ ਜਿੱਥੇ ਅਸਲ ਯੂਜ਼ਰ ਦਰਦ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। p95 (ਅਤੇ ਕਈ ਵਾਰੀ p99) ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਪੁਲ ਸੈਚੁਰੇਸ਼ਨ, ਲਾਕ ਵੇਟ, ਅਤੇ ਧੀਮੇ ਪਲਾਨ ਪਹਿਲਾਂ ਦਿਖਦੇ ਹਨ।
ਇੱਕ ਛੋਟਾ ਪ੍ਰੀ-ਲਾਂਚ ਸਵੈ-ਚੈੱਕ:
- ਇੱਕ ਛੋਟੇ ਲੋਡ ਟੈਸਟ ਦੌਰਾਨ ਪੁਲ ਵੈਟ ਸਮਾਂ ਅਤੇ Postgres ਕਨੈਕਸ਼ਨ ਗਿਣਤੀ ਵੇਖੋ।
- ਇਕੋ ਐਂਡਪਾਇੰਟ ਲਈ ਔਸਤ ਅਤੇ p95 ਲੈਟਨਸੀ ਦੀ ਤੁਲਨਾ ਕਰੋ।
- ਪੱਕਾ ਕਰੋ ਕਿ ਪੇਜੀਨੇਸ਼ਨ 10x ਵੱਡੀ ਟੇਬਲ 'ਤੇ ਵੀ degrade ਨਹੀਂ ਹੁੰਦੀ।
- ਲਿਸਟ ਐਂਡਪਾਇੰਟਾਂ ਲਈ ਰਿਸਪਾਂਸ ਆਕਾਰ ਜਾਂਚੋ (ਬਾਈਟ ਮਹੱਤਵਪੂਰਨ ਹਨ)।
- ਇੰਡੈਕਸ ਜੋੜਨ ਜਾਂ ਫਿਲਟਰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ
EXPLAINਮੁੜ ਚਲਾਓ।
ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ ਅਤੇ ਅਗਲਾ ਕਦਮ
ਅਸਲ ਯੂਜ਼ਰਾਂ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਸੀਂ ਇਹ ਸਬੂਤ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਤੁਹਾਡੀ API ਸਟਰੈਸ ਹੇਠ ਪੇਸ਼ਗੀਯੋਗ ਰਹੇਗੀ। ਟੀਚਾ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ — ਉਹ ਕੁਝ ਮੁੱਦੇ ਫੜਨਾ ਜਿਹੜੇ ਟਾਇਮਆਉਟ, ਸਪਾਈਕ, ਜਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਨਵਾਂ ਕੰਮ ਲੈਣ ਤੋਂ ਰੋਕਦੇ ਹਨ।
ਸਟੇਜਿੰਗ ਵਿੱਚ ਚੈੱਕ ਚਲਾਓ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਵਰਗੀ ਹੋਵੇ (ਡੇਟਾਬੇਸ ਦਾ ਆਕਾਰ, ਇਕੋ ਇੰਡੀਕਸ, ਇਕੋ ਪੁਲ ਸੈਟਿੰਗ): ਮੁਖ ਐਂਡਪਾਇੰਟਾਂ ਦੇ ਨਿਪੁੰਨ p95 ਲੈਟਨਸੀ ਨੂੰ ਮੈਜ਼ਰ ਕਰੋ, ਸਭ ਤੋਂ ਧੀਮੀਆਂ ਕਵੇਰੀਆਂ ਕੈਪਚਰ ਕਰੋ, ਪੂਰੀ ਤਰੀਕੇ ਨਾਲ worst query EXPLAIN (ANALYZE, BUFFERS) ਚਲਾਓ ਤਾਂ ਜੋ ਪੱਕਾ ਹੋਵੇ ਕਿ ਇਹ ਉਹ ਇੰਡੈਕਸ ਵਰਤ ਰਿਹਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਅਤੇ busiest routes ਦੇ payload ਸਾਈਜ਼ ਚੈਕ ਕਰੋ।
ਫਿਰ ਇੱਕ worst-case ਰਨ ਕਰੋ ਜੋ ਉਤਪਾਦ ਕਿਵੇਂ ਟੁੱਟਦਾ ਹੈ: ਡੂੰਘੀ ਪੇਜ ਦੀ ਬੇਨਤੀ ਕਰੋ, ਸਭ ਤੋਂ ਵਿਆਪਕ filter ਲਗਾਓ, ਅਤੇ cold start ਨਾਲ ਕੋਸ਼ਿਸ਼ ਕਰੋ (API ਰੀਸਟਰਟ ਕਰਕੇ ਇਕੋ ਹੀ ਬੇਨਤੀ ਪਹਿਲੀ ਵਾਰੀ ਕਰੋ)। ਜੇ ਡੂੰਘੀ ਪੇਜੀਨੇਸ਼ਨ ਹਰ ਪੰਨੀ ਤੇ ਧੀਮੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ cursor-based pagination 'ਤੇ ਸਵਿੱਚ ਕਰੋ।
ਆਪਣੇ default ਲਿਖੋ ਤਾਂ ਜੋ ਟੀਮ ਅੱਗੇ ਸਥਿਰ ਫ਼ੈਸਲੇ ਲਏ: ਪੁਲ limits ਅਤੇ timeouts, pagination ਨਿਯਮ (max page size, offset ਦੀ ਆਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ, cursor ਫਾਰਮੈਟ), ਕਵੇਰੀ ਨਿਯਮ (ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਕਾਲਮ ਚੁਣੋ, SELECT * ਤੋਂ ਬਚੋ, expensive filters ਨੂੰ cap ਕਰੋ), ਅਤੇ ਲੌਗਿੰਗ ਨਿਯਮ (slow query threshold, ਨਮੂਨੇ ਕਿੰਨੇ ਸਮੇਂ ਰੱਖਣੇ, endpoints ਨੂੰ ਕਿਵੇਂ ਲੇਬਲ ਕਰਨਾ)।
ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ Go + Postgres ਸਰਵਿਸ ਬਣਾਉਂਦੇ ਅਤੇ ਐਕਸਪੋਰਟ ਕਰਦੇ ਹੋ, ਤਾਂ deployment ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ ਯੋਜਨਾ ਪਾਸ ਕ_filters, pagination, ਅਤੇ response shapes ਨੂੰ ਇਰਾਦੇ ਨਾਲ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇੰਡੈਕਸ ਅਤੇ ਕਵੇਰੀ ਸ਼ੇਪਸ 'ਤੇ ਟਿਊਨਿੰਗ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, snapshots ਅਤੇ rollback ਇੱਕ ਠੀਕ ਤਰੀਕਾ ਦਿੰਦੇ ਹਨ ਓਸ "ਫਿਕਸ" ਨੂੰ ਇੱਕ ਐਂਡਪਾਇੰਟ ਲਈ ਫਾਇਦੇਮੰਦ ਪਰ ਹੋਰਾਂ ਲਈ ਨੁਕਸਾਨਦਾਇਕ ਹੋਣ ਤੇ ਵਾਪਸ ਰਹਿਤ ਲਈ। ਜੇ ਤੁਸੀਂ ਉਸ workflow ਨੂੰ ਇੱਕ ਥਾਂ 'ਤੇ ਦੁਹਰਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਤੇ koder.ai ਉਹਨਾਂ ਸਰਵਿਸਾਂ ਨੂੰ générate ਅਤੇ refine ਕਰਨ ਲਈ ਚੈਟ ਆਧਾਰਤ ਤਰੀਕਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸੋর্স ਨਿਰਯਾਤ ਕਰਨ ਦੀ ਸੁਵਿਧਾ ਦਿੰਦਾ ਹੈ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
ਮੇਰੀ Go API ਧੀਮੀ ਕਿਉਂ ਹੈ — Postgres ਕਰਕੇ ਜਾਂ ਕੋਡ ਕਰਕੇ? (ਤੇਜ਼ ਤਰੀਕਾ ਕਿਵੇਂ ਪਤਾ ਕਰਾਂ?)
ਸਭ ਤੋਂ ਪਹਿਲਾਂ DB انتظار ਸਮਾਂ ਨੂੰ ਐਪ ਕੰਮ ਸਮਾਂ ਤੋਂ ਵੱਖਰਾ ਕਰੋ।
- ਜੇ ਡਾਟਾਬੇਸ ਧੀਮਾ ਹੈ, ਹੈਂਡਲਰ ਬਹੁਤ ਵਕਤ ਆਪਣੇ ਕਵੇਰੀ ਦੀ ਉਡੀਕ ਵਿੱਚ ਬਿਤਾਉਂਦਾ ਹੈ। ਇਹ ਸਮੇਂ Go CPU ਆਮਤੌਰ 'ਤੇ ਨਾਰਮਲ ਰਹਿੰਦਾ ਹੈ ਪਰ ਬੇਨਤੀ "in flight" ਇਕੱਠੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।
- ਜੇ ਐਪ ਧੀਮਾ ਹੈ, ਕਵੇਰੀ ਤੇਜ਼ ਆ ਜਾਂਦੀ ਹੈ ਪਰ ਕਾਢ੍ਹਣ, ਪ੍ਰਤੀ-ਪੰਕਤੀ ਹੋਰ ਕੁਏਰੀਆਂ, ਵੱਡਾ JSON ਮਾਰਸ਼ਲਿੰਗ ਜਾਂ ਲੌਗਿੰਗ ਵਿੱਚ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। Go CPU ਅਤੇ ਮੈਮੋਰੀ ਆਮਤੌਰ 'ਤੇ ਜਵਾਬ ਦੇ ਆਕਾਰ ਨਾਲ ਵੱਧਦੇ ਹਨ।
ਸੰਖੇਪ ਜਾਂਚ: “ਕਨੈਕਸ਼ਨ ਲਈ ਉਡੀਕ” ਅਤੇ “ਕਵੇਰੀ ਚਲਾਉਣ” ਲਈ ਸਧਾਰਣ ਟਾਈਮਿੰਗ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਪਤਾ ਲੱਗੇ ਕਿ ਕਿਹੜਾ ਪਾਸਾ ਪ੍ਰਭਾਵਿਤ ਕਰ ਰਿਹਾ ਹੈ।
ਟਿਊਨਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਮੈਨੂੰ ਕਿਹੜੇ ਮੈਟ੍ਰਿਕਸ ਟ੍ਰੈਕ ਕਰਨ ਚਾਹੀਦੇ ਹਨ?
ਦੋਹਾਂ ਚੀਜ਼ਾਂ ਲਈ ਛੋਟੀ ਬੇਨਚਮਾਰਕ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਅ ਸਕੋ:
- p95 ਲੈਟेंसी ਹਰ ਮੁੱਖ ਐਂਡਪੁਆਇੰਟ ਲਈ (ਔਸਤ ਨਹੀਂ)
- ਐਰਰ ਰੇਟ (5xx, ਟਾਇਮਆਉਟ, ਕੈਂਸਲ)
- DB ਸਮਾਂ ਪ੍ਰਤੀ ਬੇਨਤੀ (Postgres ਦੀ ਉਡੀਕ ਵਿੱਚ ਲੱਗਣ ਵਲਾ ਸਮਾਂ)
ਓਹਨਾਂ ਲਈ ਇੱਕ ਸਾਫ ਲਕਸ਼ ਨਿਰਧਾਰਤ ਕਰੋ — ਉਦਾਹਰਣ: “50 ਕਨਕਰਨਟ ਯੂਜ਼ਰਾਂ 'ਤੇ p95 200 ms ਤੋਂ ਘੱਟ, ਅਤੇ ਐਰਰ 0.5% ਤੋਂ ਘੱਟ.” ਫਿਰ ਇੱਕ-ਇੱਕ ਚੀਜ਼ ਬਦਲੋ ਅਤੇ ਵਾਪਸ ਟੈਸਟ ਕਰੋ।
ਕੀ ਮੈਂ Postgres slow query logging ਚਾਲੂ ਕਰਾਂ, ਅਤੇ ਕਿਹੜੀ ਥਰੇਸ਼ਹੋਲਡ ਵਰਤੀ ਜਾਵੇ?
ਪ੍ਰੀ-ਲਾਂਚ ਟੈਸਟਿੰਗ ਲਈ धीਮੀ ਕਵੇਰੀ ਲੋਗਿੰਗ ਛੋਟੀ ਥਰੇਸ਼ਹੋਲਡ ਨਾਲ ਚਾਲੂ ਕਰੋ (ਉਦਾਹਰਣ 100–200 ms) ਅਤੇ ਪੂਰਾ ਸਥੇਟਮੈਂਟ ਲੌਗ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਸਨੂੰ SQL ਕਲਾਇੰਟ ਵਿੱਚ ਕਾਪੀ ਕਰ ਸਕੋ.
ਧਿਆਨ ਰਹੇ:
- ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਇਹ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ੋਰਦਾਰ ਹੋ ਜਾਂਦਾ ਹੈ।
- ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੌਗਿੰਗ ਓਵਰਹੈੱਡ ਵਧਾ ਸਕਦੀ ਹੈ।
ਸਭ ਤੋਂ ਵੱਡੇ offenders ਮਿਲਣ 'ਤੇ ਤੁਸੀਂ ਸੈਂਪਲਿੰਗ 'ਤੇ ਸਵਿੱਚ ਕਰੋ ਜਾਂ ਥਰੇਸ਼ਹੋਲਡ ਵਧਾਓ।
Go API ਲਈ Postgres connection pool ਦੀਆਂ ਸ਼ੁਰੂਆਤੀ ਸੈਟਿੰਗਾਂ ਕੀ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਨੇ?
ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਪ੍ਰਾਟੀਕਲ ਡੀਫੌਲਟ ਹੈ: ਹਰ API ਇੰਸਟੈਂਸ ਲਈ CPU ਕੋਰਾਂ ਦਾ ਛੋਟਾ ਗੁਣਾ — ਅਕਸਰ 5–20 max open connections, ਇਸੇ ਦੇ ਨੇੜੇ max idle connections, ਅਤੇ 30–60 ਮਿੰਟਾਂ 'ਤੇ ਕਨੈਕਸ਼ਨ ਰੀਸਾਇਕਲ ਕਰੋ.
ਦੋ ਆਮ ਫੇਲ ਮੋਡ:
- ਪੂਲ ਬਹੁਤ ਛੋਟਾ: ਬੇਨਤੀਆਂ ਨੂੰ ਕੁਨੈਕਸ਼ਨ ਮਿਲਣ ਲਈ ਉਡੀਕ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਜਦ ਕਿ Postgres ਕਮੇਸ਼ਨ ਨਹੀ ਕਰ ਰਿਹਾ।
- ਪੂਲ ਬਹੁਤ ਵੱਡਾ: ਬਹੁਤ ਸਾਰੇ ਸੈਸ਼ਨ Postgres ਨੂੰ ਓਵਰਲੋਡ ਕਰਦੇ ਹਨ ਅਤੇ ਲੈਟਨਸੀ ਅਨੀਆਮ ਹੋ ਜਾਂਦੀ ਹੈ।
ਯਾਦ ਰੱਖੋ ਕਿ ਪੂਲ ਇੰਸਟੈਂਸਾਂ ਦੇ ਨਾਲ ਗੁਣਾ ਹੋ ਜਾਂਦਾ ਹੈ (20 × 10 = 200) — ਇਹ ਆਮਤੌਰ 'ਤੇ ਕੰਟਰੋਲ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ।
ਕਿਵੇਂ ਪੁਸ਼ਟੀ ਕਰਾਂ ਕਿ ਕਨੈਕਸ਼ਨ ਪੂਲ ਤੇਜ਼ੀ ਦਾ ਬੋਤਲ-ਨੈਕ ਹੈ (ਸਾਡੇ SQL ਵਾਲਾ ਨਹੀਂ)?
DB ਕਾਲ ਨੂੰ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਟਾਈਮ ਕਰੋ:
- ਕਨੈਕਸ਼ਨ ਲਈ ਉਡੀਕ (ਪੂਲ ਵੈਟ)
- ਕਵੇਰੀ ਚਲਾਉਣ ਦਾ ਸਮਾਂ (Postgres ਦਾ ਕੰਮ)
ਜੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਪੂਲ ਵੈਟ ਵਿੱਚ ਜਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਪੂਲ ਸਾਈਜ਼, ਟਾਇਮਆਉਟ ਅਤੇ ਇੰਸਟੈਂਸ ਗਿਣਤੀ ਅਨੁਸਾਰ ਐਡਜਸਟ ਕਰੋ।
ਇਸਦੇ ਨਾਲ-ਨਾਲ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹਰ ਰਿਕਾਰਡ ਰੋਜ਼ (rows) ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਤਾਂ ਜੋ ਕਨੈਕਸ਼ਨ ਨੂੰ ਵਾਪਸ ਪੂਲ ਵਿੱਚ ਛੱਡਿਆ ਜਾ ਸਕੇ।
ਜਦੋਂ ਕੋਈ ਐਂਡਪਾਇੰਟ ਧੀਮਾ ਦਿਸਦਾ ਹੈ ਤਾਂ EXPLAIN ਵਿੱਚ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ?
ਉਸ ਸਥਿਤੀ ਵਿਚ EXPLAIN (ANALYZE, BUFFERS) ਚਲਾਓ ਅਤੇ ਨੀਵੇਂ ਨਤੀਜੇ ਵੇਖੋ:
- ਵੱਡੀ ਟੇਬਲ 'ਤੇ Seq Scan
- ਅਨੁਮਾਨਤ ਰੋਜ਼ vs ਅਸਲ ਰੋਜ਼ ਵਿੱਚ ਵੱਡਾ ਫਰਕ
ORDER BYਕਾਰਨ Sort ਵੱਧ ਸਮਾਂ ਲੈਣਾ- “Rows Removed by Filter” ਬਹੁਤ ਉੱਚਾ ਹੋਣਾ
- BUFFERS ਵਿੱਚ ਵੱਡੀ shared read ਬਲਾਕਸ
ਸਿਰਫ਼ ਸਭ ਤੋਂ ਵੱਡੇ ਮਸਲੇ ਨੂੰ ਪਹਿਲਾਂ ਠੀਕ ਕਰੋ; ਸਭ ਕੁਝ ਬਦਲਣ ਦੀ ਲੋੜ ਨਹੀਂ।
ਲਿਸਟ ਐਂਡਪਾਇੰਟ ਲਈ ਸਹੀ ਇੰਡੀੈਕਸ ਕਿਵੇਂ ਚੁਣੀਏ?
ਇੰਡੀੈਕਸ ਉਹਨਾਂ ਕਵੇਰੀਆਂ ਲਈ ਹੀ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹੋ।
ਚੰਗਾ ਦ੍ਰਿਸ਼ਟੀਕੋਣ:
- ਆਪਣੀ ਆਮ
WHERE+ORDER BYਪੈਟਰਨ ਲਈ ਇੱਕ ਕੰਪੋਜ਼ਿਟ ਇੰਡੀੈਕਸ ਬਣਾਓ। - ਇੰਡੀੈਕਸ ਛੋਟਾ ਰੱਖੋ: 2 ਕਾਲਮ ਆਮ, 3 ਕਦੇ-ਕਦੇ।
- ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸਿਲੈਕਟਿਵ ਫਿਲਟਰ ਪਹਿਲੇ ਰੱਖੋ।
- ਅਲੱਗ-ਅਲੱਗ ਇੰਡੀੈਕਸ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸੋਚੋ — ਇੱਕ ਚੰਗਾ ਕੰਪੋਜ਼ਿਟ ਇੰਡੀੈਕਸ ਕਈ ਛੋਟੀਆਂ ਇੰਡੈਕਸਾਂ ਨੂੰ ਅਵਸ਼ਕਤਾ ਨਹੀਂ ਰਹਿਣ ਦਿੰਦੈ।
ਉਦਾਹਰਣ: ਜੇ ਤੁਸੀਂ user_id ਨਾਲ ਫਿਲਟਰ ਕਰਦੇ ਹੋ ਅਤੇ ਨਵੇਂ ਤੋਂ ਪੁਰਾਣੇ ਦਿਖਾਉਂਦੇ ਹੋ, ਤਾਂ (user_id, created_at DESC) ਅਕਸਰ ਸਹੀ ਚੋਣ ਹੁੰਦੀ ਹੈ।
Postgres ਵਿੱਚ partial index ਕਦੋਂ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ?
ਜਦੋਂ ਜ਼ਿਆਦਾਤਰ ਟ੍ਰੈਫਿਕ ਇੱਕ ਪਤਲਾ ਸੈਠੇ (subset) ਤੇ ਆਉਂਦਾ ਹੈ, partial index ਲਾਭਕਾਰੀ ਹੁੰਦਾ ਹੈ।
ਉਦਾਹਰਣ:
- ਜੇ ਅਕਸਰ ਸਿਰਫ਼
active = trueਵਾਲੇ ਰਿਕਾਰਡ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ... WHERE active = trueਵਾਲਾ ਇੰਡੀੈਕਸ ਛੋਟਾ ਰਹੇਗਾ, ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿਣ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧੇਗੀ ਅਤੇ ਲਿਖਣ 'ਤੇ ਘੱਟ ਓਵਰਹੈੱਡ ਬਣੇਗਾ।
ਹਮੇਸ਼ਾ EXPLAIN ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਉੱਚ-ਟ੍ਰੈਫਿਕ ਕਵੇਰੀ ਇਸਨੂੰ ਵਰਤ ਰਹੀ ਹੈ।
LIMIT/OFFSET ਪੇਜੀਨੇਸ਼ਨ ਕਿਉਂ ਪੇਜ ਬਨਣ 'ਤੇ ਧੀਮਾ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਮੈਨੂੰ ਕੀ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ?
LIMIT/OFFSET ਡੂੰਘੀਆਂ ਪੰਨੀਆਂ 'ਤੇ ਧੀਮਾ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ Postgres ਨੂੰ ਖਾਰਜ ਕੀਤੀਆਂ ਗਈਆਂ ਰੋਜ਼ਾਂ ਨੂੰ ਵੀ ਪਾਸ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਪੇਜ 1 ਛੋਟੇ ਰਿਕਾਰਡ ਤੱਕ ਸੀਮਿਤ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਪੇਜ 500 ਦੇ ਲਈ ਡਿਸਕਾਰਡ ਕਰਨ ਲਈ ਦਸ ਹਜ਼ਾਰਾਂ ਰੋਜ਼ਾਂ ਸਕੈਨ ਹੋ ਸਕਦੀਆਂ ਹਨ।
ਇਸ ਦੀ ਬਜਾਏ keyset (cursor) pagination ਵਰਤੋ:
- ਸਥਿਰ ਸੋਰਟ ਅਤੇ ਯੂਨੀਕ ਟਾਈ-ਬਰੇਕਰ (ਅਮੂਮਨ
id) ਵਰਤੋਂ। - ਹਰ ਬੇਨਤੀ 'ਤੇ ਇੱਕੋ ਹੀ
ORDER BYਰੱਖੋ। (created_at, id)ਵਰਗਾ ਸੰਯੁਕਤ ਕਰਸਰ ਕੋਡ ਕਰਕੇ opaque ਰੱਖੋ।
ਇਸ ਨਾਲ ਹਰ ਪੰਨੀ ਦਾ ਖਰਚ ਪਾਧਰ ਤਕਰੀਬਨ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ।
ਮੇਰੀ DB ਕਵੇਰੀਆਂ ਤੇਜ਼ ਹਨ, ਪਰ ਜਵਾਬ ਫਿਰ ਵੀ ਧੀਮਾ ਹੈ—ਕੀ ਮੈਂ JSON payload ਘਟਾਵਾਂ?
ਹਾਂ — ਆਮਤौर 'ਤੇ ਲਿਸਟ ਐਂਡਪਾਇੰਟਾਂ ਲਈ ਜਵਾਬ ਛਾਂਟੋ।
ਤੱਤਕਾਲੀ ਲਾਭ:
- ਸਿਰਫ਼ ਜ਼ਰੂਰੀ ਕਾਲਮ ਚੁਣੋ (SELECT * ਤੋਂ ਬਚੋ)
include=ਜਾਂfields=ਓਪਸ਼ਨ ਦਿਓ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਭਾਰੀ ਫੀਲਡਾਂ ਦੀ ਮੰਗ ਕਰ ਸਕਣ- nested arrays ਨੂੰ ਸੀਮਤ ਕਰੋ (ਜਿਵੇਂ ਸਿਰਫ਼ ਨਵੇਂ 10 ਘਟਨਾਵਾਂ) ਅਤੇ ਪੂਰੀ ਇਤਿਹਾਸ ਵੱਖਰੇ ਐਂਡਪਾਇੰਟ ਤੇ ਦਿਓ
- N+1 ਪੈਟਰਨ ਤੋਂ ਬਚੋ — ਜੌਇਨ ਜਾਂ ਬੈਚ ਕਵੇਰੀਆਂ ਵਰਤੋਂ
ਅਕਸਰ payload ਘਟਾਉਣਾ Go CPU, ਮੈਮੋਰੀ ਪ੍ਰੈਸ਼ਰ ਅਤੇ ਟੇਲ ਲੈਟਨਸੀ ਵਿੱਚ ਫ਼ੈਸਲਾਕਾਰੀ ਘਟਾਉਂਦਾ ਹੈ।