Meteor 3.5 ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਐਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲ (environment variable) ਨਾਲ SockJS ਨੂੰ ਛੱਡ ਕੇ uWebSockets.js ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿ ਮੈਥਡ ਕਾਲਜ਼ (method calls) 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਨ ਵਾਲੀਆਂ ਐਪਸ ਲਈ CPU, RAM ਅਤੇ ਗਾਰਬੇਜ-ਕਲੈਕਸ਼ਨ (garbage-collection) ਦੀ ਲਾਗਤ ਵਿੱਚ ਕਾਫ਼ੀ ਕਮੀ ਲਿਆਉਣ ਦਾ ਵਾਅਦਾ ਕਰਦਾ ਹੈ।

ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਆਪਣੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਹੀ, Meteor ਨੇ ਹਰ DDP (Distributed Data Protocol) ਮੈਸੇਜ ਨੂੰ SockJS ਰਾਹੀਂ ਰੂਟ ਕੀਤਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ JavaScript ਫਾਲਬੈਕ (fallback) ਹੈ ਜੋ ਹਰ ਜਗ੍ਹਾ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਇਸਨੂੰ ਕਦੇ ਵੀ ਤੇਜ਼ ਰਫ਼ਤਾਰ ਲਈ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਨਵਾਂ ਰਿਲੀਜ਼ ਟ੍ਰਾਂਸਪੋਰਟ ਲੇਅਰ (transport layer) ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਅਜਿਹਾ ਪਲੱਗ-ਇਨ ਪੁਆਇੰਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਵੀ WebSocket ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ ਜੋ DDP ਦੀਆਂ ਉਮੀਦਾਂ ਅਨੁਸਾਰ ਹੋਵੇ। ਲਾਂਚ ਵੇਲੇ DDP_TRANSPORT=uws ਸੈੱਟ ਕਰਨ ਨਾਲ ਡਿਫੌਲਟ ਨੂੰ uWebSockets.js ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਉੱਚ ਥਰੂਪੁੱਟ (high throughput) ਲਈ ਜਾਣਿਆ ਜਾਂਦਾ ਇੱਕ C/C++-ਬੈਕਡ ਸਰਵਰ ਹੈ।

ਪਰਫਾਰਮੈਂਸ ਦਾ ਪੱਖ

ਰਿਲੀਜ਼ ਦੇ ਨਾਲ ਦਿੱਤੇ ਗਏ ਬੈਂਚਮਾਰਕਸ (benchmarks) ਦਿਖਾਉਂਦੇ ਹਨ:

  • CPU ਦੀ ਵਰਤੋਂ 9% ਘੱਟ
  • RAM ਦੀ ਖਪਤ 11% ਘੱਟ
  • ਗਾਰਬੇਜ-ਕਲੈਕਸ਼ਨ ਪੌਜ਼ ਟਾਈਮ (garbage-collection pause time) ਵਿੱਚ 26% ਦੀ ਕਮੀ
  • ਮਾਈਕਰੋ-ਬੈਂਚਮਾਰਕਸ ਵਿੱਚ ਥਰੂਪੁੱਟ 1.6× ਵਧ ਗਿਆ

ਇਹ ਫਾਇਦੇ ਉਦੋਂ ਦੇਖਣ ਨੂੰ ਮਿਲਦੇ ਹਨ ਜਦੋਂ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਬਹੁਤ ਸਾਰੇ RPC-ਸਟਾਈਲ ਮੈਥਡ ਕਾਲਜ਼ ਕਰਦੀ ਹੈ। ਟ੍ਰਾਂਸਪੋਰਟ ਆਪਣੇ ਆਪ ਉਦੋਂ ਹੀ ਬੋਤਲਨੈਕ (bottleneck) ਬਣਦਾ ਹੈ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਬਿਜ਼ਨਸ ਲੌਜਿਕ (business logic) ਨੂੰ ਆਪਟੀਮਾਈਜ਼ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੋਵੇ, ਇਸ ਲਈ ਇਹ ਬਦਲਾਅ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਰਵਰ ਦੀ ਲਾਗਤ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ।

ਅੱਜ ਹੀ ਇਸਨੂੰ ਕਿਵੇਂ ਅਜ਼ਮਾਇਆ ਜਾਵੇ

ਕਿਸੇ ਵੱਖਰੇ ਬਾਈਨਰੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ—ਸਿਰਫ਼ Meteor 3.5 ਦੀ ਲੋੜ ਹੈ। ਐਪ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਚਲਾਓ:

DDP_TRANSPORT=uws meteor run

uWebSockets.js ਸਰਵਰ ਆਪਣੇ ਖਾਸ ਪੋਰਟ (ਡਿਫੌਲਟ 5001) 'ਤੇ ਸੁਣਦਾ ਹੈ। ਜਦੋਂ ਕਈ Meteor ਇੰਸਟੈਂਸ ਇੱਕੋ ਹੋਸਟ ਨੂੰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਟਕਰਾਅ (collisions) ਤੋਂ ਬਚਣ ਲਈ METEOR_SETTINGS ਰਾਹੀਂ ਹਰੇਕ ਨੂੰ ਇੱਕ ਵੱਖਰਾ uws.port ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕਿਸ ਨੂੰ ਫਾਇਦਾ ਹੋਵੇਗਾ, ਅਤੇ ਕਿਸ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਫਰਕ ਮਹਿਸੂਸ ਨਹੀਂ ਹੋਵੇਗਾ

  • RPC-ਭਾਰੀ ਵਰਕਲੋਡ (RPC-heavy workloads) – ਉਹ ਸੇਵਾਵਾਂ ਜੋ ਪ੍ਰਤੀ ਰਿਕਵੈਸਟ ਬਹੁਤ ਸਾਰੇ ਮੈਥਡ ਕਾਲ ਕਰਦੀਆਂ ਹਨ, ਉਹ CPU ਸਾਈਕਲ ਅਤੇ ਮੈਮੋਰੀ ਬਚਾ ਸਕਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਸਕੈਲਿੰਗ ਦੇ ਦਬਾਅ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
  • Pub/Sub-ਕੇਂਦਰਿਤ ਐਪਸ (Pub/Sub-centric apps) – ਪਬਲਿਸ਼/ਸਬਸਕ੍ਰਾਈਬ (publish/subscribe) ਪੈਟਰਨਾਂ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਲੇਟੈਂਸੀ (latency) ਡਾਟਾ-ਡਿਫ (data-diff) ਗਣਨਾਵਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਟ੍ਰਾਂਸਪੋਰਟ ਤੋਂ, ਇਸ ਲਈ ਰਫ਼ਤਾਰ ਵਿੱਚ ਵਾਧਾ ਮਾਮੂਲੀ ਹੁੰਦਾ ਹੈ।

ਇਹ ਬਦਲਾਅ ਵਿਕਲਪਿਕ (opt-in) ਹੈ; SockJS ਡਿਫੌਲਟ ਰਹਿੰਦਾ ਹੈ, ਜੋ ਉਹਨਾਂ ਵਾਤਾਵਰਣਾਂ ਨਾਲ ਅਨੁਕੂਲਤਾ (compatibility) ਬਣਾਈ ਰੱਖਦਾ ਹੈ ਜਿੱਥੇ ਨੇਟਿਵ WebSockets ਉਪਲਬਧ ਨਹੀਂ ਹਨ।

ਸਮਝੌਤੇ ਅਤੇ ਸਾਵਧਾਨੀਆਂ

ਟ੍ਰਾਂਸਪੋਰਟ ਬਦਲਣ ਨਾਲ ਇੱਕ ਛੋਟਾ ਕਾਰਜਸ਼ੀਲ ਕਦਮ ਵਧ ਜਾਂਦਾ ਹੈ: ਇੱਕ ਵਾਧੂ ਪੋਰਟ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ ਇਹ ਹੋਰ ਸੇਵਾਵਾਂ ਨਾਲ ਨਾ ਟਕਰਾਵੇ। ਕਿਉਂਕਿ uWebSockets.js ਇੱਕ ਨੇਟਿਵ ਮੋਡੀਊਲ ਹੈ, ਇਸ ਲਈ ਇਹ ਬਾਈਨਰੀ ਡਿਪੈਂਡੈਂਸੀਆਂ (binary dependencies) ਦੀਆਂ ਆਮ ਗੱਲਾਂ ਨਾਲ ਆਉਂਦਾ ਹੈ—ਡਿਪਲਾਈਮੈਂਟ ਹੋਸਟ 'ਤੇ ਬਿਲਡ ਟੂਲਸ (build tools) ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਕਿਸੇ ਵੀ ਭਵਿੱਖੀ ਅੱਪਡੇਟ ਦੀ ਐਪ ਦੇ ਕੋਡਬੇਸ ਦੇ ਵਿਰੁੱਧ ਜਾਂਚ ਕਰਨੀ ਪਵੇਗੀ।

Meteor ਦੀ ਟ੍ਰਾਂਸਪੋਰਟ ਲੇਅਰ ਲਈ ਅੱਗੇ ਕੀ ਹੈ

ਇੱਕ ਸਾਫ਼ ਸੀਮਾ (boundary) ਪ੍ਰਦਾਨ ਕਰਕੇ, Meteor ਹੁਣ ਭਾਈਚਾਰੇ ਨੂੰ ਵਿਕਲਪਿਕ ਟ੍ਰਾਂਸਪੋਰਟਾਂ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨ ਲਈ ਸੱਦਾ ਦਿੰਦਾ ਹੈ—ਚਾਹੇ ਉਹ ਵਿਸ਼ੇਸ਼ ਸੁਰੱਖਿਆ ਲੋੜਾਂ ਲਈ ਹੋਵੇ, ਕਸਟਮ ਪ੍ਰੋਟੋਕੋਲ ਐਕਸਟੈਂਸ਼ਨਾਂ ਲਈ ਹੋਵੇ, ਜਾਂ ਹੋਰ ਪਰਫਾਰਮੈਂਸ ਟਿਊਨਿੰਗ ਲਈ ਹੋਵੇ। ਇਹ ਦੇਖਣਾ ਕਿ ਤੀਜੀ-ਪਾਰਟੀ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ, ਇਹ ਦੱਸੇਗਾ ਕਿ ਕੀ ਇਹ ਪਲੱਗ-ਇਨ ਮਾਡਲ Meteor ਦੇ ਆਰਕੀਟੈਕਚਰ ਦਾ ਇੱਕ ਸਥਾਈ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ।

ਸਿੱਟਾ (Takeaway): Meteor 3.5 ਦਾ ਪਲੱਗ-ਇਨ DDP ਟ੍ਰਾਂਸਪੋਰਟ ਤੁਹਾਨੂੰ ਇੱਕ ਸਿੰਗਲ ਕਮਾਂਡ ਵਿੱਚ ਪੁਰਾਣੇ SockJS ਸਟੈਕ ਨੂੰ uWebSockets.js ਨਾਲ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜੋ RPC-ਭਾਰੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ 1.6× ਤੱਕ ਉੱਚਾ ਥਰੂਪੁੱਟ ਅਤੇ ਮਾਪਣਯੋਗ ਸਰੋਤਾਂ ਦੀ ਬਚਤ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਉਹਨਾਂ ਵਰਕਲੋਡਾਂ ਲਈ ਮੌਜੂਦਾ ਸੈੱਟਅੱਪ ਨੂੰ ਅਛੂਤਾ ਰੱਖਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਸ ਵਾਧੇ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।