ਇੱਕ ਡਿਵੈਲਪਰ ਨੇ ਕਲਾਇੰਟ-ਸਾਈਡ ਪੋਲਿੰਗ ਇੰਟਰਵਲ (polling interval) ਨੂੰ 30 ਸੈਕਿੰਡ ਤੋਂ ਵਧਾ ਕੇ 15 ਮਿੰਟ ਕਰਕੇ Neon ਦੇ serverless-database compute ਖਰਚਿਆਂ ਨੂੰ ਘਟਾ ਦਿੱਤਾ। ਲੰਬਾ ਵਿਰਾਮ ਡਾਟਾਬੇਸ ਨੂੰ ਇੰਨੀ ਦੇਰ ਤੱਕ idle ਰਹਿਣ ਦਿੰਦਾ ਹੈ ਕਿ ਉਹ 'scale to zero' ਹੋ ਸਕੇ, ਜਿਸ ਨਾਲ ਉਹ compute credits ਬਚ ਜਾਂਦੇ ਹਨ ਜੋ ਲਗਾਤਾਰ 30-ਸੈਕਿੰਡ ਦੀ ਪੋਲਿੰਗ ਖ਼ਰਚ ਕਰਦੀ ਸੀ।
Neon ਆਪਣੇ compute engine ਦੇ ਚੱਲਣ ਦੇ ਹਰ ਸੈਕਿੰਡ ਲਈ ਬਿੱਲ ਭਰਦਾ ਹੈ। ਇੱਕ ਆਮ serverless setup ਵਿੱਚ, ਕੋਈ ਵੀ request—ਭਾਵੇਂ ਉਹ ਕਿੰਨੀ ਵੀ ਛੋਟੀ ਕਿਉਂ ਨਾ ਹੋਵੇ—engine ਨੂੰ ਚਾਲੂ ਰੱਖਦੀ ਹੈ। ਲੇਖਕ ਦਾ TV dashboard ਹਰ ਅੱਧੇ ਮਿੰਟ ਵਿੱਚ ਡਾਟਾਬੇਸ ਨੂੰ query ਕਰਦਾ ਸੀ, ਭਾਵੇਂ ਦਿਖਾਇਆ ਗਿਆ ਡਾਟਾ ਉਦੋਂ ਹੀ ਬਦਲਦਾ ਸੀ ਜਦੋਂ ਕੋਈ ਯੂਜ਼ਰ ਮੈਨੂਅਲੀ sync ਕਰਦਾ ਸੀ ਜਾਂ ਕੋਈ ਨਵਾਂ broadcast ਸ਼ੁਰੂ ਹੁੰਦਾ ਸੀ। ਉਸ ਪੈਟਰਨ ਨੇ Neon ਦੇ compute pool ਨੂੰ ਕਦੇ ਵੀ ਉਸ 'zero-state' ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਰੋਕਿਆ ਜੋ ਬਿਲਿੰਗ ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ Vercel cost dashboard ਵਿੱਚ ਲਗਾਤਾਰ ਉਛਾਲ (spikes) ਆਉਂਦੇ ਰਹੇ।
ਮੂਲ ਪੋਲਿੰਗ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ
- Dashboard ਪੂਰੀ ਤਰ੍ਹਾਂ ਇੱਕ client-side React component ਸੀ, ਇਸ ਲਈ ਹਰੇਕ browser instance ਸਿੱਧਾ Neon ਨਾਲ ਜੁੜਦਾ ਸੀ।
- Neon ਦੀ ਕੀਮਤ active compute ਸਮੇਂ ਨਾਲ ਜੁੜੀ ਹੋਈ ਹੈ, request ਦੀ ਗਿਣਤੀ ਨਾਲ ਨਹੀਂ, ਇਸ ਲਈ ਹਰ 30 ਸੈਕਿੰਡ ਵਿੱਚ ਇੱਕ hit ਇੱਕ ਬੇਸਲਾਈਨ ਚਾਰਜ ਬਣਾਈ ਰੱਖਦੀ ਸੀ।
- ਲੇਖਕ ਦੇ Vercel monitoring ਨੇ traffic ਅਤੇ Neon compute ਦੀ ਵਰਤੋਂ ਵਿਚਕਾਰ ਇੱਕ ਸਬੰਧ ਦਿਖਾਇਆ, ਜਿਸ ਤੋਂ ਪੁਸ਼ਟੀ ਹੋਈ ਕਿ ਪੋਲਿੰਗ ਡਾਟਾਬੇਸ ਨੂੰ ਚਾਲੂ ਰੱਖ ਰਹੀ ਸੀ।
ਅਸਫਲ ਕੋਸ਼ਿਸ਼ਾਂ
ਇੱਕ ਤੇਜ਼ debounce—ਯਾਨੀ ਆਖਰੀ ਯੂਜ਼ਰ interaction ਤੋਂ ਬਾਅਦ request ਨੂੰ ਦੇਰੀ ਨਾਲ ਭੇਜਣਾ—ਕੋਈ ਮਦਦ ਨਹੀਂ ਕਰ ਸਕਿਆ ਕਿਉਂਕਿ timer ਅਜੇ ਵੀ ਹਰ 30 ਸੈਕਿੰਡ ਬਾਅਦ ਚੱਲਦਾ ਸੀ। ਮੈਂ Vercel Edge Functions ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਵੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਪਰ ਉਸ ਨਾਲ ਗੁੰਝਲਤਾ ਬਹੁਤ ਵਧ ਗਈ।
ਸਧਾਰਨ ਹੱਲ
ਸਿਰਫ਼ ਇੱਕ ਕੋਡ ਬਦਲਾਅ ਦੀ ਲੋੜ ਸੀ, ਉਹ ਸੀ refresh interval ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਵਾਲੇ constant ਨੂੰ ਬਦਲਣਾ:
- 30 ਸੈਕਿੰਡ ਤੋਂ → 5 ਮਿੰਟ
- ਫਿਰ 5 ਮਿੰਟ → 15 ਮਿੰਟ
15 ਮਿੰਟ 'ਤੇ, Neon ਕੋਲ inactivity ਨੂੰ ਪਛਾਣਨ ਅਤੇ ਆਪਣੇ compute resources ਨੂੰ spin down ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਸਮਾਂ ਹੁੰਦਾ ਹੈ। Dashboard ਕਾਰਜਸ਼ੀਲ ਰਹਿੰਦਾ ਹੈ: ਯੂਜ਼ਰਾਂ ਨੂੰ ਅਜੇ ਵੀ ਨਵੀਨਤਮ ਡਾਟਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਮੈਨੂਅਲੀ refresh ਕਰਦੇ ਹਨ, ਅਤੇ ਕਦੇ-ਕਦੇ ਹੋਣ ਵਾਲੀ automatic poll ਬਿਨਾਂ ਲਗਾਤਾਰ ਰੌਲੇ-ਰੱਪੇ ਦੇ ਨਵੇਂ broadcast ਨੂੰ ਫੜ ਲੈਂਦੀ ਹੈ।
ਕਲਾਇੰਟ-ਸਾਈਡ ਪੋਲਿੰਗ ਕਿਉਂ ਰੱਖੀਏ?
- ਸਰਲਤਾ – ਕੋਈ ਵਾਧੂ serverless functions ਜਾਂ build steps ਨਹੀਂ।
- ਯੂਜ਼ਰ ਦੀਆਂ ਉਮੀਦਾਂ – Dashboard ਪਹਿਲਾਂ ਹੀ ਇੱਕ client app ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ; ਮੈਨੂਅਲ ਕਲਿੱਕ ਨਾਲ ਅਜੇ ਵੀ ਤੁਰੰਤ ਅਪਡੇਟ ਮਿਲਦਾ ਹੈ।
- ਲਾਗਤ ਮਾਡਲ ਨਾਲ ਅਨੁਕੂਲਤਾ – Neon compute ਦੇ ਹਰ ਸੈਕਿੰਡ ਲਈ ਚਾਰਜ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਹਰ request ਲਈ, ਇਸ ਲਈ ਫ੍ਰੀਕੁਐਂਸੀ ਘਟਾਉਣ ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਬਿੱਲ ਘਟ ਜਾਂਦਾ ਹੈ।
Serverless ਡਿਵੈਲਪਰਾਂ ਲਈ ਸਬਕ
- ਆਪਣੀ ਡਾਟਾ ਦੀ ਅਸਲ-ਦੁਨੀਆ ਦੀ update cadence ਦੇ ਅਨੁਸਾਰ ਪੋਲਿੰਗ ਫ੍ਰੀਕੁਐਂਸੀ ਨੂੰ ਮਿਲਾਓ। ਜੇਕਰ ਕੋਈ dataset ਘੰਟੇ ਵਿੱਚ ਸਿਰਫ਼ ਕੁਝ ਵਾਰ ਬਦਲਦਾ ਹੈ, ਤਾਂ 15-ਮਿੰਟ ਦਾ ਇੰਟਰਵਲ ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।
- Serverless ਵਾਤਾਵਰਣ ਵਿੱਚ ਵਾਰ-ਵਾਰ ਪੋਲਿੰਗ ਕਰਨਾ ਇੱਕ ਲੁਕਿਆ ਹੋਇਆ ਖਰਚਾ ਵਧਾਉਣ ਵਾਲਾ ਕਾਰਕ ਹੈ; ਪ੍ਰਤੀ ਮਿੰਟ ਇੱਕ ਵਾਧੂ request ਡਾਟਾਬੇਸ ਨੂੰ ਕਦੇ ਵੀ scale down ਹੋਣ ਤੋਂ ਰੋਕ ਸਕਦੀ ਹੈ।
- ਛੋਟੇ ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਾਅ ਬਿਨਾਂ ਕਿਸੇ ਆਰਕੀਟੈਕਚਰਲ ਤਬਦੀਲੀ ਦੇ ਵੱਡੀ ਬਚਤ ਕਰ ਸਕਦੇ ਹਨ।
ਨਿਚੋੜ: ਇੱਕ ਸਿੰਗਲ constant ਬਦਲਾਅ ਨੇ ਲਗਾਤਾਰ ਚਾਲੂ ਰਹਿਣ ਵਾਲੇ ਡਾਟਾਬੇਸ ਨੂੰ ਇੱਕ ਅਸਲ serverless component ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ dashboard ਦੀ ਉਪਯੋਗਤਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋਏ compute ਖਰਚੇ ਨੂੰ ਘਟਾਇਆ ਗਿਆ। Neon ਜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ per-second compute ਸੇਵਾਵਾਂ ਚਲਾਉਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਟੀਮ ਲਈ, poll intervals ਦੀ ਮੁੜ ਜਾਂਚ ਕਰਨਾ ਇੱਕ ਅਜਿਹੀ ਜਿੱਤ ਹੈ ਜਿਸਦਾ ਅੱਜ ਹੀ ਟੈਸਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।