ਇੱਕ ਨੈਟਿਵ Polling API ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਵਾਲਾ PHP RFC ਮਨਜ਼ੂਰ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ ਅਤੇ ਭਾਸ਼ਾ ਦੀ ਮਾਸਟਰ ਬ੍ਰਾਂਚ ਵਿੱਚ ਮਰਜ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਜੋ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰਾਂ (file descriptors) ਨੂੰ ਪੋਲ ਕਰਨ ਲਈ ਇੱਕ ਤੇਜ਼, OS-ਲੇਵਲ ਦਾ ਤਰੀਕਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਹਾਲ ਹੀ ਵਿੱਚ ਜੋੜੇ ਗਏ Fibers ਦੇ ਨਾਲ, PHP ਕੋਲ ਹੁਣ ਅਸਿੰਕ੍ਰੋਨਸ (asynchronous) ਕੋਡ ਲਈ ਇੱਕ ਬਿਲਟ-ਇਨ, ਕੁਸ਼ਲ ਅਧਾਰ ਹੈ—ਇੱਕ ਅਜਿਹੀ ਘਾਟ ਜਿਸ ਨੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਆਪਣੇ ਵੱਖਰੇ ਤਰੀਕੇ (work-arounds) ਲੱਭਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਹੋਇਆ ਸੀ।

Fibers ਅਤੇ event loop, ਵੱਖਰੇ ਤੌਰ 'ਤੇ

Fibers ਇੱਕ ਲੋ-ਲੇਵਲ ਕੰਟਰੋਲ-ਫਲੋ ਪ੍ਰੀਮੇਟਿਵ (control-flow primitive) ਹਨ। ਉਹ ਕਿਸੇ ਫੰਕਸ਼ਨ ਨੂੰ ਚੁਣੇ ਹੋਏ ਬਿੰਦੂ 'ਤੇ ਆਪਣੀ ਅਮਲ ਪ੍ਰਕਿਰਿਆ (execution) ਨੂੰ ਰੋਕਣ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਉੱਥੇ ਹੀ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਜਿੱਥੇ ਉਹ ਰੁਕੇ ਸਨ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ, ਇੱਕ fiber ਨੂੰ ਸਾਕਟਸ (sockets), ਟਾਈਮਰਾਂ ਜਾਂ ਕਿਸੇ ਹੋਰ I/O ਸਰੋਤ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ; ਇਹ ਸਿਰਫ਼ ਮੰਗ 'ਤੇ ਰੁਕਦਾ ਅਤੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

Event loop ਉਹ ਸ਼ੈਡਿਊਲਰ ਹੈ ਜੋ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਰੁਕੇ ਹੋਏ fiber ਨੂੰ ਕਦੋਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਆਮ async ਸਟੈਕ ਵਿੱਚ, ਲੂਪ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰਾਂ ਦੇ ਇੱਕ ਸਮੂਹ 'ਤੇ ਨਜ਼ਰ ਰੱਖਦਾ ਹੈ, ਉਹਨਾਂ ਦੇ ਪੜ੍ਹਨਯੋਗ (readable) ਜਾਂ ਲਿਖਣਯੋਗ (writable) ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਉਚਿਤ fiber ਨੂੰ ਜਗਾਉਂਦਾ ਹੈ।

PHP ਕੋਲ ਪਹਿਲਾਂ Fibers ਸਨ ਪਰ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਤੋਂ ਇਹ ਪੁੱਛਣ ਲਈ ਕੋਈ ਨੈਟਿਵ ਵਿਧੀ ਨਹੀਂ ਸੀ ਕਿ ਕਿਹੜੇ ਡਿਸਕ੍ਰਿਪਟਰ ਤਿਆਰ ਹਨ। ਇਸ ਦਾ ਨਤੀਜਾ stream_select() ਜਾਂ ਬਾਹਰੀ ਐਕਸਟੈਂਸ਼ਨਾਂ 'ਤੇ ਨਿਰਭਰਤਾ ਸੀ, ਅਤੇ ਹਰ async ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ Linux ਦੇ epoll, BSD ਦੇ kqueue, Windows ਦੇ IOCP, ਆਦਿ ਲਈ ਆਪਣੇ ਵੱਖਰੇ ਬੈਕ-ਐਂਡ ਲਿਖਣੇ ਪਏ।

ਨਵਾਂ Polling API ਉਸ ਗੁੰਮ ਹੋਈ ਕੜੀ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਇਹ OS ਦੀਆਂ polling ਸਹੂਲਤਾਂ (Linux 'ਤੇ epoll, BSD/macOS 'ਤੇ kqueue, ਆਦਿ) ਦੇ ਆਲੇ-ਦੁਆਲੇ ਇੱਕ ਪਤਲਾ ਵੈਪਰ (wrapper) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ API Fibers ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦਾ; ਇਹ ਸਿਰਫ਼ event loop ਨੂੰ ਉਹ ਗਤੀ ਅਤੇ ਸਕੇਲੇਬਿਲਟੀ (scalability) ਦਿੰਦਾ ਹੈ ਜਿਸਦੀ ਉਸਨੂੰ ਲੋੜ ਹੈ।

ReactPHP, Amp ਅਤੇ ਹੋਰਾਂ ਲਈ ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ReactPHP ਅਤੇ Amp v3 ਨੇ OS polling ਵਿਧੀਆਂ ਦੇ ਉੱਪਰ ਆਪਣੇ ਅਬਸਟਰੈਕਸ਼ਨ ਲੇਅਰ (abstraction layers) ਬਣਾਏ ਹਨ। ਉਹਨਾਂ ਲੇਅਰਾਂ ਵਿੱਚ ਕਈ ਕੋਡ ਪਾਥ ਹੁੰਦੇ ਹਨ, ਜੋ ਹਰੇਕ ਇੱਕ ਖਾਸ ਪਲੇਟਫਾਰਮ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਰਨਲ (kernel) ਦੇ ਬਦਲਾਅਾਂ ਦੇ ਨਾਲ ਸਿੰਕ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ। ਇੱਕ ਨੈਟਿਵ Polling API ਦੇ ਨਾਲ, ਲਾਇਬ੍ਰੇਰੀਆਂ ਉਸ ਜ਼ਿਆਦਾਤਰ ਪਲੰਬਿੰਗ (plumbing) ਨੂੰ ਛੱਡ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕ ਸਿੰਗਲ, ਕੋਰ-ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ ਕਾਲ 'ਤੇ ਨਿਰਭਰ ਕਰ ਸਕਦੀਆਂ ਹਨ।

  • Maintenance (ਰੱਖ-ਰਖਾਅ) – ਘੱਟ ਪਲੇਟਫਾਰਮ-ਵਿਸ਼ੇਸ਼ ਬ੍ਰਾਂਚਾਂ ਦਾ ਮਤਲਬ ਹੈ ਘੱਟ ਬੱਗ (bugs) ਅਤੇ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆਵਾਂ ਲਈ ਇੱਕ ਛੋਟਾ ਖੇਤਰ।
  • Performance (ਕਾਰਗੁਜ਼ਾਰੀ) – ਨੈਟਿਵ ਕਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ epoll/kqueue ਨਾਲ ਗੱਲ ਕਰਦੀ ਹੈ।
  • Portability (ਪੋਰਟੇਬਿਲਟੀ) – "Vanilla" PHP 'ਤੇ ਚੱਲਣ ਵਾਲਾ ਕੋਡ ਹੁਣ ਬਿਨਾਂ ਕਿਸੇ ਵਿਕਲਪਿਕ ਐਕਸਟੈਂਸ਼ਨ ਦੀ ਲੋੜ ਦੇ, ਸਾਰੇ ਸਮਰਥਿਤ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹੀ ਬੇਸਲਾਈਨ ਕਾਰਗੁਜ਼ਾਰੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।

ਇਸਦੇ ਉਲਟ, Swoole ਇੱਕ ਪੂਰਾ ਰਨ-ਟਾਈਮ (runtime) ਬਦਲ ਬਣਿਆ ਹੋਇਆ ਹੈ ਜੋ ਆਪਣਾ ਖੁਦ ਦਾ event loop ਅਤੇ ਕੋਰੂਟੀਨ (coroutine) ਸਿਸਟਮ ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ। Polling API Swoole ਦੇ ਫਾਇਦੇ-ਨੁਕਸਾਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ; ਉਹ ਡਿਵੈਲਪਰ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਲਟਰਾ-ਲੋ ਲੇਟੈਂਸੀ (ultra-low latency) ਜਾਂ ਕਸਟਮ ਮੈਮੋਰੀ ਮੈਨੇਜਮੈਂਟ ਦੀ ਲੋੜ ਹੈ, ਉਹ ਅਜੇ ਵੀ ਇਸਨੂੰ ਇੱਕ ਵੱਖਰੇ ਵਿਕਲਪ ਵਜੋਂ ਵਿਚਾਰਨਗੇ।

ਇੱਕ ਤੇਜ਼ ਬੈਂਚਮਾਰਕ ਕਹਾਣੀ ਦੱਸਦਾ ਹੈ

ਇੱਕ ਨਿਮਨਤਮ (minimal) ਸ਼ੈਡਿਊਲਰ ਨੇ ਕਈ URL ਨੂੰ ਰੋਅ ਸਾਕਟਸ (raw sockets) ਰਾਹੀਂ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਜਿਸ ਵਿੱਚ ਕਈ ਫਾਈਬਰਾਂ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ ਇੱਕ ਸਿੰਗਲ Io\Poll\Context ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ। ਦੋ ਨਿਰੀਖਣ ਸਾਹਮਣੇ ਆਏ:

  1. Speed (ਗਤੀ) – ਵਧੇਰੇ ਸਮਾਂਤਲ (concurrent) ਬੇਨਤੀਆਂ ਜੋੜਨ ਨਾਲ ਕੁੱਲ ਲੱਗਿਆ ਸਮਾਂ ਨਹੀਂ ਵਧਦਾ; ਬੇਨਤੀਆਂ ਦਾ ਸਮੂਹ ਉਨੀ ਹੀ ਤੇਜ਼ੀ ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ ਜਿੰਨੀ ਸਭ ਤੋਂ ਹੌਲੀ ਸਿੰਗਲ ਬੇਨਤੀ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, concurrency overhead ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤੌਰ 'ਤੇ ਜ਼ੀਰੋ ਹੈ।
  2. CPU cost (CPU ਲਾਗਤ) – stream_select() ਦੇ ਨਾਲ, ਜਿਵੇਂ-ਜਿਵੇਂ ਸਟ੍ਰੀਮਾਂ ਦੀ ਗਿਣਤੀ ਵਧਦੀ ਹੈ, CPU ਦੀ ਵਰਤੋਂ ਮਹੱਤਵਪੂਰਨ ਰੂਪ ਵਿੱਚ ਵਧਦੀ ਹੈ, ਕਿਉਂਕਿ ਫੰਕਸ਼ਨ ਨੂੰ ਹਰੇਕ ਕਾਲ 'ਤੇ ਹਰ ਡਿਸਕ੍ਰਿਪਟਰ 'ਤੇ ਜਾਣਾ ਪੈਂਦਾ ਹੈ। Polling API ਦੀ ਲਾਗਤ ਤਿੰਨ ਸਟ੍ਰੀਮਾਂ ਤੋਂ ਤੀਹ ਸਟ੍ਰੀਮਾਂ ਤੱਕ ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਕਰਨਲ ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ ਸਿਸਟਮ ਕਾਲ ਵਿੱਚ ਕਈ ਡਿਸਕ੍ਰਿਪਟਰਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ।

ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਹੁਣ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

  • Amp v3 ਨੂੰ ਅਪਣਾਓ ਜੇਕਰ ਤੁਸੀਂ ਫਾਈਬਰ-ਨੈਟਿਵ ਸ਼ੈਲੀ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹੋ ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਨਵੇਂ API ਦੇ ਅਨੁਕੂਲ ਹੈ। ਇਸਦਾ ਪਬਲਿਕ ਇੰਟਰਫੇਸ ਪਹਿਲਾਂ ਹੀ ਅੰਡਰਲਾਈਂਗ ਪੋਲਰ (underlying poller) ਨਾਲ ਮੈਪ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਆਪਣਾ ਕੋਡ ਦੁਬਾਰਾ ਲਿਖੇ ਬਿਨਾਂ ਇਸਦਾ ਲਾਭ ਮਿਲਦਾ ਹੈ।
  • ReactPHP ਨਾਲ ਜੁੜੇ ਰਹੋ ਜੇਕਰ ਤੁਹਾਨੂੰ ਲੂਪ ਦੇ ਜੀਵਨ ਚੱਕਰ (lifecycle) 'ਤੇ ਸਪੱਸ਼ਟ ਕੰਟਰੋਲ ਪਸੰਦ ਹੈ।
  • ਪ੍ਰੋਡਕਸ਼ਨ ਵਰਕਲੋਡ ਲਈ ਕਸਟਮ ਸ਼ੈਡਿਊਲਰਾਂ ਤੋਂ ਬਚੋ। ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਆਪਣਾ ਸ਼ੈਡਿਊਲਰ ਨਾ ਲਿਖੋ।