ನೇಟಿವ್ Polling API ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ PHP RFC ಅನ್ನು ಅನುಮೋದಿಸಲಾಗಿದೆ ಮತ್ತು ಭಾಷೆಯ ಮಾಸ್ಟರ್ ಬ್ರಾಂಚ್‌ಗೆ ವಿಲೀನಗೊಳಿಸಲಾಗಿದೆ, ಇದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗಳನ್ನು (file descriptors) ಪೋಲ್ ಮಾಡಲು ವೇಗವಾದ, OS-ಮಟ್ಟದ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ. ಇತ್ತೀಚೆಗೆ ಸೇರಿಸಲಾದ Fibers ನೊಂದಿಗೆ ಸೇರಿ, PHP ಈಗ ಅಸಿಂಕ್ರೋನಸ್ (asynchronous) ಕೋಡ್‌ಗಾಗಿ ಅಂತರ್ನಿರ್ಮಿತವಾದ, ದಕ್ಷ ಅಡಿಪಾಯವನ್ನು ಹೊಂದಿದೆ—ಈ ಕೊರತೆಯಿಂದಾಗಿ ದೀರ್ಘಕಾಲದವರೆಗೆ ಲೈಬ್ರರಿಗಳು ತಮ್ಮದೇ ಆದ ಪರಿಹಾರಗಳನ್ನು (work-arounds) ಸಿದ್ಧಪಡಿಸಬೇಕಾಗಿ ಬಂದಿತ್ತು.

Fibers ಮತ್ತು event loop, ಪ್ರತ್ಯೇಕವಾಗಿ

Fibers ಎಂಬುದು ಲೋ-ಲೆವೆಲ್ ಕಂಟ್ರೋಲ್-ಫ್ಲೋ ಪ್ರಿಮಿಟಿವ್ ಆಗಿದೆ. ಅವು ಒಂದು ಫಂಕ್ಷನ್ ತನ್ನ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು (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 ನ ಪೋಲಿಂಗ್ ಸೌಲಭ್ಯಗಳ (Linux ನಲ್ಲಿ epoll, BSD/macOS ನಲ್ಲಿ kqueue ಇತ್ಯಾದಿ) ಸುತ್ತ ಒಂದು ತೆಳುವಾದ ವ್ರಾಪ್ಪರ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಈ API Fibers ಅನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ; ಇದು ಕೇವಲ event loop ಗೆ ಅಗತ್ಯವಿರುವ ವೇಗ ಮತ್ತು ಸ್ಕೇಲೆಬಿಲಿಟಿಯನ್ನು ನೀಡುತ್ತದೆ.

ReactPHP, Amp ಮತ್ತು ಸ್ನೇಹಿತರಿಗೆ ಈ ಬದಲಾವಣೆ ಏಕೆ ಮುಖ್ಯ

ReactPHP ಮತ್ತು Amp v3 ತಮ್ಮದೇ ಆದ ಅಬ್‌ಸ್ಟ್ರಾಕ್ಷನ್ ಲೇಯರ್‌ಗಳನ್ನು (abstraction layers) OS ಪೋಲಿಂಗ್ ಮೆಕ್ಯಾನಿಸಮ್‌ಗಳ ಮೇಲೆ ನಿರ್ಮಿಸಿಕೊಂಡಿವೆ. ಆ ಲೇಯರ್‌ಗಳು ನಿರ್ದಿಷ್ಟ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಾಗಿ ಟ್ಯೂನ್ ಮಾಡಲಾದ ಹಲವಾರು ಕೋಡ್ ಪಾತ್‌ಗಳನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಕರ್ನಲ್ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಸಿಂಕ್‌ನಲ್ಲಿ ಇರಿಸಬೇಕಾಗುತ್ತದೆ. ನೇಟಿವ್ Polling API ಯೊಂದಿಗೆ, ಲೈಬ್ರರಿಗಳು ಆ ಹೆಚ್ಚಿನ ಪ್ಲಂಬಿಂಗ್ ಅನ್ನು ಬಿಟ್ಟುಕೊಡಬಹುದು ಮತ್ತು ಕೇವಲ ಒಂದು ಕೋರ್-ಪ್ರೊವೈಡೆಡ್ ಕಾಲ್ ಅನ್ನು ಅವಲಂಬಿಸಬಹುದು.

  • Maintenance – ಕಡಿಮೆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್-ನಿರ್ದಿಷ್ಟ ಬ್ರಾಂಚ್‌ಗಳು ಎಂದರೆ ಕಡಿಮೆ ಬಗ್‌ಗಳು ಮತ್ತು ಸೆಕ್ಯೂರಿಟಿ ರಿವ್ಯೂಗಳಿಗಾಗಿ ಸಣ್ಣ ಸರ್ಫೇಸ್ ಏರಿಯಾ ಎಂದರ್ಥ.
  • Performance – ನೇಟಿವ್ ಕಾಲ್ ನೇರವಾಗಿ epoll/kqueue ಜೊತೆಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ.
  • Portability – "vanilla" PHP ನಲ್ಲಿ ಚಲಿಸುವ ಕೋಡ್ ಈಗ ಯಾವುದೇ ಐಚ್ಛಿಕ ಎಕ್ಸ್‌ಟೆನ್ಷನ್‌ಗಳ ಅಗತ್ಯವಿಲ್ಲದೆ ಎಲ್ಲಾ ಬೆಂಬಲಿತ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಬೇಸ್‌ಲೈನ್ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಅನ್ನು ಪಡೆಯುತ್ತದೆ.

ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, Swoole ತನ್ನದೇ ಆದ event loop ಮತ್ತು ಕೊರೂಟಿನ್ (coroutine) ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೊಂದಿರುವ ಪೂರ್ಣ-ರನ್‌ಟೈಮ್ ರಿಪ್ಲೇಸ್‌ಮೆಂಟ್ ಆಗಿ ಉಳಿದಿದೆ. Polling API ஆனது Swoole ನ ಟ್ರೇಡ್-ಆಫ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ; ಅಲ್ಟ್ರಾ-ಲೋ ಲೇಟೆನ್ಸಿ ಅಥವಾ ಕಸ್ಟಮ್ ಮೆಮೊರಿ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಅಗತ್ಯವಿರುವ ಡೆವಲಪರ್‌ಗಳು ಇದನ್ನು ಇನ್ನೂ ಪ್ರತ್ಯೇಕ ಆಯ್ಕೆಯಾಗಿ ಪರಿಗಣಿಸುತ್ತಾರೆ.

ಒಂದು ಕ್ವಿಕ್ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಕಥೆಯನ್ನು ಹೇಳುತ್ತದೆ

ಒಂದು ಮಿನಿಮಲ್ ಶೆಡ್ಯೂಲರ್ ಒಂದೇ Io\Poll\Context ಅನ್ನು ಬಳಸಿ ಹಲವಾರು ಫೈಬರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಮೂಲಕ ರೊ (raw) ಸಾಕೆಟ್‌ಗಳ ಮೂಲಕ ಹಲವಾರು URLಗಳನ್ನು ಪಡೆದುಕೊಂಡಿತು. ಎರಡು ಅವಲೋಕನಗಳು ಕಂಡುಬಂದವು:

  1. Speed – ಹೆಚ್ಚಿನ ಏಕಕಾಲಿಕ (concurrent) ವಿನಂತಿಗಳನ್ನು ಸೇರಿಸುವುದರಿಂದ ಒಟ್ಟು ගතವಾದ ಸಮಯ ಹೆಚ್ಚಾಗುವುದಿಲ್ಲ; ವಿನಂತಿಗಳ ಬ್ಯಾಚ್ ಅತ್ಯಂತ ನಿಧಾನಗತಿಯ ಏಕೈಕ ವಿನಂತಿಯಷ್ಟೇ ವೇಗವಾಗಿ ಮುಕ್ತಾಯಗೊಳ್ಳುತ್ತದೆ. ಅಂದರೆ, ಕನ್ಕರನ್ಸಿ ಓವರ್‌ಹೆಡ್ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಶೂನ್ಯವಾಗಿದೆ.
  2. CPU cost – stream_select() ಬಳಸಿ ಸ್ಟ್ರೀಮ್‌ಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾದಂತೆ CPU ಬಳಕೆ ಗಮನಾರ್ಹವಾಗಿ ಏರುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ಕಾಲ್‌ನಲ್ಲಿ ಫಂಕ್ಷನ್ ಪ್ರತಿಯೊಂದು ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮೇಲೆ ಇಟರೇಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಕರ್ನಲ್ ಒಂದೇ ಸಿಸ್ಟಮ್ ಕಾಲ್‌ನಲ್ಲಿ ಅನೇಕ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವುದರಿಂದ, Polling API ನ ವೆಚ್ಚವು ಮೂರು ಸ್ಟ್ರೀಮ್‌ಗಳಿಂದ ಮೂವತ್ತು ಸ್ಟ್ರೀಮ್‌ಗಳವರೆಗೆ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ.

ಡೆವಲಪರ್‌ಗಳು ಈಗ ಏನು ಮಾಡಬೇಕು

  • Amp v3 ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ ನೀವು ಹೊಸ API ಗೆ ನೇರವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವ fiber-native ಶೈಲಿಯನ್ನು ಬಯಸಿದರೆ. ಇದರ ಪಬ್ಲಿಕ್ ಇಂಟರ್ಫೇಸ್ ಈಗಾಗಲೇ ಅಂಡರ್‌ಲೈಯಿಂಗ್ ಪೋಲರ್‌ಗೆ ಮ್ಯಾಪ್ ಆಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಮರುಬರೆಯುವ ಅಗತ್ಯವಿಲ್ಲದೆ ಇದರ ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯಬಹುದು.
  • ReactPHP ನೊಂದಿಗೆ ಮುಂದುವರಿಯಿರಿ ನೀವು ಲೂಪ್‌ನ ಲೈಫ್‌ಸೈಕಲ್ ಮೇಲೆ ಸ್ಪಷ್ಟ ನಿಯಂತ್ರಣವನ್ನು ಬಯಸಿದರೆ.
  • ಪ್ರೊಡಕ್ಷನ್ ವರ್ಕ್‌ಲೋಡ್‌ಗಳಿಗಾಗಿ ಕಸ್ಟಮ್ ಶೆಡ್ಯೂಲರ್‌ಗಳನ್ನು ತಪ್ಪಿಸಿ. ಪ್ರೊಡಕ್ಷನ್‌ಗಾಗಿ ನಿಮ್ಮದೇ ಆದ ಶೆಡ್ಯೂಲರ್ ಅನ್ನು ಬರೆಯಬೇಡಿ.