ਥੰਬਨੇਲ ਜਨਰੇਸ਼ਨ ਨੂੰ PHP ਬੈਕਐਂਡ ਤੋਂ Cloudflare Workers ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਨਾਲ ਇੱਕ ਵੀਡੀਓ-ਹੋਸਟਿੰਗ ਸਾਈਟ ਲਈ, ਜੋ ਰੋਜ਼ਾਨਾ ਲੱਖਾਂ ਤਸਵੀਰਾਂ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਅੋਰਿਜਿਨ (origin) ਸਰਵਰ 'ਤੇ ਸਾਰਾ CPU ਲੋਡ ਖਤਮ ਹੋ ਗਿਆ। ਇਸ ਤਬਦੀਲੀ ਨੇ ਇਮੇਜ-ਪ੍ਰੋਸੈਸਿੰਗ ਲੇਟੈਂਸੀ (latency) ਨੂੰ ਡਾਟਾ ਸੈਂਟਰ ਤੋਂ ਐਜ (edge) 'ਤੇ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਨਾਲ ਰਿਸਪਾਂਸ ਸਮਾਂ ਘਟ ਗਿਆ ਅਤੇ ਬੈਂਡਵਿਡਥ ਲਾਗਤਾਂ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਨਾ ਆਸਾਨ ਹੋ ਗਿਆ।
ਪੁਰਾਣਾ ਮਾਡਲ ਕਿਉਂ ਫੇਲ ਹੋ ਗਿਆ
ਇਹ ਸਾਈਟ, ਜੋ ਹਜ਼ਾਰਾਂ ਵੀਡੀਓਜ਼ ਦਿਖਾਉਣ ਵਾਲਾ ਇੱਕ ਪਲੇਟਫਾਰਮ ਹੈ, ਇੱਕ ਸਿੰਗਲ ਪੇਜ 'ਤੇ 40 ਤੱਕ ਥੰਬਨੇਲ ਇਨਬੈਡ ਕਰਦੀ ਹੈ। ਹਰੇਕ ਥੰਬਨੇਲ ਨੂੰ ਇੱਕ PHP ਸਕ੍ਰਿਪਟ ਦੁਆਰਾ ਮੰਗ 'ਤੇ ਰੀਸਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਅਸਲ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਦੀ ਹੈ ਅਤੇ ਉਸਨੂੰ ਰੀਸਕੇਲ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਕ੍ਰੌਲਰ (crawlers) ਸਾਈਟ 'ਤੇ ਆਉਂਦੇ ਸਨ, ਤਾਂ ਬੈਕਐਂਡ ਸਰਵਰ ਰੁਕ ਜਾਂਦਾ ਸੀ।
ਐਜ ਪ੍ਰੋਸੈਸਿੰਗ ਪੰਜ ਮੁੱਖ ਲੋੜਾਂ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ
ਇੱਕ ਪ੍ਰੋਡਕਸ਼ਨ-ਗ੍ਰੇਡ ਥੰਬਨੇਲ API ਨੂੰ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ:
- Fan-in – ਕਈ ਥਰਡ-ਪਾਰਟੀ ਹੋਸਟਾਂ ਤੋਂ ਸੋਰਸ ਇਮੇਜਾਂ ਨੂੰ ਖਿੱਚਣਾ।
- Fan-out – ਕਈ ਆਕਾਰਾਂ ਵਿੱਚ ਤਿਆਰ ਕਰਨਾ (ਜਿਵੇਂ ਕਿ 320 px ਕਾਰਡ, 640 px ਹੀਰੋ ਇਮੇਜਾਂ)।
- Format negotiation – ਬੈਂਡਵਿਡਥ ਘਟਾਉਣ ਲਈ WebP ਜਾਂ AVIF ਸਰਵ ਕਰਨਾ ਜਦੋਂ ਬ੍ਰਾਊਜ਼ਰ ਉਹਨਾਂ ਨੂੰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ।
- Cache – ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ ਪਹਿਲੀ ਬੇਨਤੀ ਮਹਿੰਗੀ ਹੋ ਸਕਦੀ ਹੈ ਪਰ ਹਰ ਅਗਲੀ ਬੇਨਤੀ ਮੁਫ਼ਤ ਹੋਵੇ।
- Security – ਕਿਸੇ ਨੂੰ ਵੀ 임ਰਬਿਨਰੀ (arbitrary) ਤਸਵੀਰਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ ਸੇਵਾ ਦੀ ਦੁਰਵਰਤੋਂ ਕਰਨ ਤੋਂ ਰੋਕਣਾ।
Cloudflare Workers ਅੋਰਿਜਿਨ ਦੇ CPU ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਹਰੇਕ ਨੁਕਤੇ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ:
- Proximity – Workers ਉਪਭੋਗਤਾ ਦੇ ਨੇੜੇ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਚੱਲਦੇ ਹਨ, ਇਸ ਲਈ ਪ੍ਰੋਸੈਸ ਕੀਤੀ ਗਈ ਇਮੇਜ ਘੱਟ ਦੂਰੀ ਤੈਅ ਕਰਦੀ ਹੈ।
- Built-in Image Resizing – ਪਲੇਟਫਾਰਮ ਦਾ Image Resizing ਫੀਚਰ ਪਿਕਸਲ ਦਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇੱਕ ਕਸਟਮ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਲੋੜ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ।
- Cache API – Workers ਰੀਸਾਈਜ਼ ਕੀਤੀ ਇਮੇਜ ਨੂੰ ਐਜ 'ਤੇ ਸਟੋਰ ਕਰਦੇ ਹਨ; ਪਹਿਲੀ ਬੇਨਤੀ ਤੋਂ ਬਾਅਦ ਐਜ ਇਸਨੂੰ ਸਿੱਧਾ ਸਰਵ ਕਰਦਾ ਹੈ।
- Programmable security – ਇੱਕ ਛੋਟੀ ਸਕ੍ਰਿਪਟ HMAC ਸਿਗਨੇਚਰਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ, ਹੋਸਟਨਾਮਾਂ ਅਤੇ ਚੌੜਾਈ (widths) ਦੀ ਇੱਕ allow-list ਲਾਗੂ ਕਰਦੀ ਹੈ, ਅਤੇ ਕੈਸ਼ ਪੋਇਜ਼ਨਿੰਗ (cache poisoning) ਤੋਂ ਬਚਣ ਲਈ ਕੈਸ਼ ਕੀਜ਼ (cache keys) ਨੂੰ ਨਾਰਮਲਾਈਜ਼ ਕਰਦੀ ਹੈ।
ਸਿਸਟਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ
- Origin signed URLs ਬਣਾਉਂਦਾ ਹੈ – ਬੈਕ-ਐਂਡ ਇੱਕ ਸੀਕਰੇਟ ਕੀ (secret key) ਰੱਖਦਾ ਹੈ ਅਤੇ ਹਰੇਕ ਥੰਬਨੇਲ ਬੇਨਤੀ ਦੇ ਨਾਲ ਇੱਕ HMAC ਸਿਗਨੇਚਰ ਜੋੜਦਾ ਹੈ। URL ਵਿੱਚ ਲੋੜੀਂਦੀ ਚੌੜਾਈ ਅਤੇ ਫਾਰਮੈਟ ਵੀ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ।
- Worker ਸਿਗਨੇਚਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ – ਪ੍ਰਾਪਤ ਹੋਣ 'ਤੇ, Worker ਸਾਂਝੇ ਸੀਕਰੇਟ ਨਾਲ HMAC ਦੀ ਮੁੜ-ਗਣਨਾ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਸਿਗਨੇਚਰ ਗੁੰਮ ਹੈ ਜਾਂ ਗਲਤ ਹੈ, ਤਾਂ ਬੇਨਤੀ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਦੁਰਵਰਤੋਂ ਰੁਕ ਜਾਂਦੀ ਹੈ।
- Allow-list ਲਾਗੂ ਕਰਨਾ – ਸਕ੍ਰਿਪਟ ਚੈੱਕ ਕਰਦੀ ਹੈ ਕਿ ਸੋਰਸ ਹੋਸਟਨਾਮ ਇੱਕ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਸੂਚੀ ਵਿੱਚ ਹੈ ਅਤੇ ਮੰਗੀ ਗਈ ਚੌੜਾਈ ਸਮਰਥਿਤ ਆਕਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਇਹ ਮਾਲੀਸ਼ੀਆ ਭਰਪੂਰ (malicious) ਹੋਸਟਾਂ ਨੂੰ ਕੈਸ਼ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
- Cache key normalization – ਕੈਸ਼ ਕੀ (cache key) ਵਿੱਚੋਂ ਸਿਗਨੇਚਰ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ; ਕੀ ਵਿੱਚ ਸਿਰਫ਼ ਸੋਰਸ URL, ਚੌੜਾਈ ਅਤੇ ਫਾਰਮੈਟ ਹੁੰਦਾ ਹੈ। ਇਸ ਨਾਲ ਸੰਭਾਵਨਾ ਵਧ ਜਾਂਦੀ ਹੈ ਕਿ ਇੱਕੋ ਤਸਵੀਰ ਦੀ ਮੰਗ ਕਰਨ ਵਾਲੇ ਵੱਖ-ਵੱਖ ਉਪਭੋਗਤਾ ਇੱਕੋ ਕੈਸ਼ਡ ਐਂਟਰੀ ਤੱਕ ਪਹੁੰਚਣ।
- Edge fetch ਅਤੇ resize – ਜੇਕਰ ਇਮੇਜ ਪਹਿਲਾਂ ਤੋਂ ਕੈਸ਼ ਨਹੀਂ ਹੈ, ਤਾਂ Worker ਥਰਡ-ਪਾਰਟੀ ਹੋਸਟ ਤੋਂ ਅਸਲ ਫਾਈਲ ਖਿੱਚਦਾ ਹੈ, Image Resizing API ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਐਜ ਕੈਸ਼ ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ।
- Cache warming – ਹਰੇਕ ਕ੍ਰੌਲ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਹਲਕੀ Python ਸਕ੍ਰਿਪਟ ਨਵੇਂ ਥੰਬਨੇਲ ਲਈ ਪਹਿਲਾਂ ਹੀ ਬੇਨਤੀ ਕਰਦੀ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਪਹਿਲਾ ਅਸਲ ਉਪਭੋਗਤਾ ਰੀਸਾਈਜ਼ ਆਪਰੇਸ਼ਨ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ ਕੈਸ਼ਡ ਰਿਸਪਾਂਸ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।
ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ ਮਾਪਣਯੋਗ ਪ੍ਰਭਾਵ
- ਇਮੇਜਾਂ ਲਈ Origin CPU – ਜ਼ੀਰੋ 'ਤੇ ਆ ਗਿਆ; ਬੈਕ-ਐਂਡ ਹੁਣ ਕਦੇ ਵੀ ਇਮੇਜ ਬਾਈਟਸ ਨੂੰ ਪ੍ਰੋਸੈਸ ਨਹੀਂ ਕਰਦਾ।
- HTML ਸਰਵਿੰਗ ਸਪੀਡ – ਮਹੱਤਵਪੂਰਨ ਰੂਪ ਵਿੱਚ ਸੁਧਰ ਗਈ ਕਿਉਂਕਿ ਸਰਵਰ ਹੁਣ ਇਮੇਜ ਕੰਮ ਕਾਰਨ ਰੁਕਦਾ ਨਹੀਂ ਹੈ।
- Edge cache hit rate – 96% ਤੱਕ ਪਹੁੰਚ ਗਿਆ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਲਗਭਗ ਹਰ ਬੇਨਤੀ ਬੈਕਐਂਡ ਫੈਚ ਤੋਂ ਬਿਨਾਂ ਐਜ ਤੋਂ ਪੂਰੀ ਕੀਤੀ ਗਈ ਸੀ।
- Latency – ਘਟ ਗਈ ਕਿਉਂਕਿ ਹੁਣ ਤਸਵੀਰਾਂ ਕੇਂਦਰੀ ਅੋਰਿਜਿਨ ਦੀ ਬਜਾਏ ਉਪਭੋਗਤਾ ਦੇ ਨੇੜੇ ਡਾਟਾ ਸੈਂਟਰ ਤੋਂ ਸਰਵ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
- ਬੈਂਡਵਿਡਥ ਦੀ ਭਵਿੱਖਬਾਣੀ – ਐਜ ਕੈਸ਼ਿੰਗ ਦੇ ਨਾਲ,