ਰੋਡ ਰਨਰ: PHP ਮਰਨ ਲਈ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਜਾਂ ਬਚਾਅ ਲਈ ਗੋਲੰਗ ਨਹੀਂ ਹੈ

ਹੇ ਹਬਰ! ਅਸੀਂ Badoo 'ਤੇ ਸਰਗਰਮ ਹਾਂ PHP ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਇਸ ਭਾਸ਼ਾ ਵਿੱਚ ਇੱਕ ਕਾਫ਼ੀ ਵੱਡਾ ਸਿਸਟਮ ਹੈ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਮੁੱਦਾ ਇੱਕ ਪੈਸਾ ਬਚਾਉਣ ਵਾਲਾ ਮੁੱਦਾ ਹੈ। ਦਸ ਸਾਲ ਪਹਿਲਾਂ, ਅਸੀਂ ਇਸਦੇ ਲਈ PHP-FPM ਬਣਾਇਆ, ਜੋ ਪਹਿਲਾਂ PHP ਲਈ ਪੈਚਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਸੀ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਅਧਿਕਾਰਤ ਵੰਡ ਵਿੱਚ ਦਾਖਲ ਹੋਇਆ।

ਹਾਲ ਹੀ ਦੇ ਸਾਲਾਂ ਵਿੱਚ, PHP ਨੇ ਬਹੁਤ ਤਰੱਕੀ ਕੀਤੀ ਹੈ: ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲੇ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ ਹੈ, ਸਥਿਰਤਾ ਦਾ ਪੱਧਰ ਵਧਿਆ ਹੈ - ਅੱਜ ਤੁਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ PHP ਵਿੱਚ ਡੈਮਨ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਕ੍ਰਿਪਟਾਂ ਲਿਖ ਸਕਦੇ ਹੋ। ਇਸ ਨੇ ਸਪਿਰਲ ਸਕਾਊਟ ਨੂੰ ਹੋਰ ਅੱਗੇ ਜਾਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ: ਰੋਡ ਰਨਰ, PHP-FPM ਦੇ ਉਲਟ, ਬੇਨਤੀਆਂ ਦੇ ਵਿਚਕਾਰ ਮੈਮੋਰੀ ਨੂੰ ਸਾਫ਼ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਜੋ ਇੱਕ ਵਾਧੂ ਪ੍ਰਦਰਸ਼ਨ ਲਾਭ ਦਿੰਦਾ ਹੈ (ਹਾਲਾਂਕਿ ਇਹ ਪਹੁੰਚ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਂਦੀ ਹੈ)। ਅਸੀਂ ਇਸ ਸਮੇਂ ਇਸ ਟੂਲ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹਾਂ, ਪਰ ਸਾਡੇ ਕੋਲ ਸਾਂਝਾ ਕਰਨ ਲਈ ਅਜੇ ਕੋਈ ਨਤੀਜਾ ਨਹੀਂ ਹੈ। ਉਹਨਾਂ ਦੀ ਉਡੀਕ ਨੂੰ ਹੋਰ ਮਜ਼ੇਦਾਰ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ Spiral Scout ਤੋਂ RoadRunner ਘੋਸ਼ਣਾ ਦਾ ਅਨੁਵਾਦ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਾਂ।

ਲੇਖ ਦੀ ਪਹੁੰਚ ਸਾਡੇ ਨੇੜੇ ਹੈ: ਸਾਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵੇਲੇ, ਅਸੀਂ ਅਕਸਰ PHP ਅਤੇ Go ਦੇ ਇੱਕ ਸਮੂਹ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਦੋਵਾਂ ਭਾਸ਼ਾਵਾਂ ਦੇ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋਏ ਅਤੇ ਇੱਕ ਨੂੰ ਦੂਜੀ ਦੇ ਹੱਕ ਵਿੱਚ ਨਾ ਛੱਡਦੇ ਹੋਏ।

ਮਾਣੋ!

ਪਿਛਲੇ ਦਸ ਸਾਲਾਂ ਵਿੱਚ, ਅਸੀਂ ਸੂਚੀ ਵਿੱਚੋਂ ਕੰਪਨੀਆਂ ਲਈ ਅਰਜ਼ੀਆਂ ਤਿਆਰ ਕੀਤੀਆਂ ਹਨ ਫਾਰਚੂਨ 500, ਅਤੇ 500 ਤੋਂ ਵੱਧ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਦਰਸ਼ਕ ਵਾਲੇ ਕਾਰੋਬਾਰਾਂ ਲਈ। ਇਸ ਸਾਰੇ ਸਮੇਂ, ਸਾਡੇ ਇੰਜੀਨੀਅਰ ਮੁੱਖ ਤੌਰ 'ਤੇ PHP ਵਿੱਚ ਬੈਕਐਂਡ ਦਾ ਵਿਕਾਸ ਕਰ ਰਹੇ ਹਨ। ਪਰ ਦੋ ਸਾਲ ਪਹਿਲਾਂ, ਕਿਸੇ ਚੀਜ਼ ਦਾ ਨਾ ਸਿਰਫ਼ ਸਾਡੇ ਉਤਪਾਦਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ 'ਤੇ, ਸਗੋਂ ਉਹਨਾਂ ਦੀ ਮਾਪਯੋਗਤਾ 'ਤੇ ਵੀ ਵੱਡਾ ਪ੍ਰਭਾਵ ਪਿਆ ਸੀ - ਅਸੀਂ ਗੋਲੰਗ (ਗੋ) ਨੂੰ ਸਾਡੇ ਤਕਨਾਲੋਜੀ ਸਟੈਕ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਸੀ।

ਲਗਭਗ ਤੁਰੰਤ, ਸਾਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ Go ਨੇ ਸਾਨੂੰ 40x ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰਾਂ ਦੇ ਨਾਲ ਵੱਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ। ਇਸਦੇ ਨਾਲ, ਅਸੀਂ ਆਪਣੇ ਮੌਜੂਦਾ PHP ਉਤਪਾਦਾਂ ਨੂੰ ਵਧਾਉਣ ਦੇ ਯੋਗ ਹੋ ਗਏ ਹਾਂ, ਦੋਵਾਂ ਭਾਸ਼ਾਵਾਂ ਦੇ ਲਾਭਾਂ ਨੂੰ ਜੋੜ ਕੇ ਉਹਨਾਂ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕਦੇ ਹਾਂ।

ਅਸੀਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗੇ ਕਿ ਗੋ ਅਤੇ PHP ਦਾ ਸੁਮੇਲ ਅਸਲ ਵਿਕਾਸ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਸਾਡੇ ਲਈ ਇੱਕ ਸਾਧਨ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲ ਗਿਆ ਹੈ ਜੋ ਇਸ ਨਾਲ ਜੁੜੀਆਂ ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾ ਸਕਦਾ ਹੈ। PHP ਮਰਨ ਵਾਲਾ ਮਾਡਲ.

ਤੁਹਾਡਾ ਰੋਜ਼ਾਨਾ PHP ਵਿਕਾਸ ਵਾਤਾਵਰਣ

ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰੀਏ ਕਿ ਤੁਸੀਂ PHP ਮਰਨ ਵਾਲੇ ਮਾਡਲ ਨੂੰ ਮੁੜ ਸੁਰਜੀਤ ਕਰਨ ਲਈ ਗੋ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰ ਸਕਦੇ ਹੋ, ਆਓ ਤੁਹਾਡੇ ਡਿਫਾਲਟ PHP ਵਿਕਾਸ ਵਾਤਾਵਰਣ 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ।

ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਤੁਸੀਂ nginx ਵੈੱਬ ਸਰਵਰ ਅਤੇ PHP-FPM ਸਰਵਰ ਦੇ ਸੁਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਚਲਾਉਂਦੇ ਹੋ। ਸਾਬਕਾ ਸਥਿਰ ਫਾਈਲਾਂ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ ਅਤੇ ਖਾਸ ਬੇਨਤੀਆਂ ਨੂੰ PHP-FPM ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ PHP-FPM ਖੁਦ PHP ਕੋਡ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਸ਼ਾਇਦ ਅਪਾਚੇ ਅਤੇ mod_php ਦੇ ਘੱਟ ਪ੍ਰਸਿੱਧ ਸੁਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ. ਪਰ ਹਾਲਾਂਕਿ ਇਹ ਥੋੜਾ ਵੱਖਰਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਸਿਧਾਂਤ ਇੱਕੋ ਜਿਹੇ ਹਨ.

ਆਉ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ ਕਿ PHP-FPM ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ, PHP-FPM ਇੱਕ PHP ਚਾਈਲਡ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਬੇਨਤੀ ਦੇ ਵੇਰਵਿਆਂ ਨੂੰ ਇਸਦੇ ਰਾਜ (_GET, _POST, _SERVER, ਆਦਿ) ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਪਾਸ ਕਰਦਾ ਹੈ।

PHP ਸਕ੍ਰਿਪਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੌਰਾਨ ਸਥਿਤੀ ਨਹੀਂ ਬਦਲ ਸਕਦੀ, ਇਸਲਈ ਇਨਪੁਟ ਡੇਟਾ ਦਾ ਨਵਾਂ ਸੈੱਟ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ: ਪ੍ਰਕਿਰਿਆ ਮੈਮੋਰੀ ਨੂੰ ਸਾਫ਼ ਕਰਕੇ ਅਤੇ ਇਸਨੂੰ ਮੁੜ-ਸ਼ੁਰੂ ਕਰਕੇ।

ਇਸ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਮਾਡਲ ਦੇ ਬਹੁਤ ਸਾਰੇ ਫਾਇਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਬਾਰੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਚਿੰਤਾ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ, ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਲੱਗ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਜੇਕਰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ "ਮਰ ਜਾਂਦੀ ਹੈ", ਤਾਂ ਇਹ ਆਪਣੇ ਆਪ ਦੁਬਾਰਾ ਬਣ ਜਾਵੇਗੀ ਅਤੇ ਇਹ ਬਾਕੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰੇਗੀ। ਪਰ ਇਸ ਪਹੁੰਚ ਦੇ ਨੁਕਸਾਨ ਵੀ ਹਨ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ।

ਇੱਕ ਨਿਯਮਤ PHP ਵਾਤਾਵਰਣ ਦੇ ਨੁਕਸਾਨ ਅਤੇ ਅਯੋਗਤਾਵਾਂ

ਜੇ ਤੁਸੀਂ ਇੱਕ ਪੇਸ਼ੇਵਰ PHP ਡਿਵੈਲਪਰ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਇੱਕ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਕਿੱਥੇ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ - ਇੱਕ ਫਰੇਮਵਰਕ ਦੀ ਚੋਣ ਦੇ ਨਾਲ. ਇਸ ਵਿੱਚ ਨਿਰਭਰਤਾ ਇੰਜੈਕਸ਼ਨ ਲਾਇਬ੍ਰੇਰੀਆਂ, ORM, ਅਨੁਵਾਦ ਅਤੇ ਟੈਂਪਲੇਟ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਅਤੇ, ਬੇਸ਼ੱਕ, ਸਾਰੇ ਉਪਭੋਗਤਾ ਇੰਪੁੱਟ ਨੂੰ ਇੱਕ ਵਸਤੂ (Symfony/HttpFoundation ਜਾਂ PSR-7) ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਫਰੇਮਵਰਕ ਵਧੀਆ ਹਨ!

ਪਰ ਹਰ ਚੀਜ਼ ਦੀ ਕੀਮਤ ਹੁੰਦੀ ਹੈ. ਕਿਸੇ ਵੀ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਪੱਧਰ ਦੇ ਫਰੇਮਵਰਕ ਵਿੱਚ, ਇੱਕ ਸਧਾਰਨ ਉਪਭੋਗਤਾ ਬੇਨਤੀ ਜਾਂ ਡੇਟਾਬੇਸ ਤੱਕ ਪਹੁੰਚ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ ਦਰਜਨਾਂ ਫਾਈਲਾਂ ਲੋਡ ਕਰਨੀਆਂ ਪੈਣਗੀਆਂ, ਕਈ ਕਲਾਸਾਂ ਬਣਾਉਣੀਆਂ ਪੈਣਗੀਆਂ ਅਤੇ ਕਈ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਪਾਰਸ ਕਰਨਾ ਹੋਵੇਗਾ। ਪਰ ਸਭ ਤੋਂ ਮਾੜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਹਰੇਕ ਕੰਮ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਸਭ ਕੁਝ ਰੀਸੈਟ ਕਰਨ ਅਤੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ: ਉਹ ਸਾਰਾ ਕੋਡ ਜੋ ਤੁਸੀਂ ਹੁਣੇ ਸ਼ੁਰੂ ਕੀਤਾ ਹੈ ਬੇਕਾਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸਦੀ ਮਦਦ ਨਾਲ ਤੁਸੀਂ ਹੁਣ ਕਿਸੇ ਹੋਰ ਬੇਨਤੀ 'ਤੇ ਕਾਰਵਾਈ ਨਹੀਂ ਕਰੋਗੇ। ਇਹ ਕਿਸੇ ਵੀ ਪ੍ਰੋਗਰਾਮਰ ਨੂੰ ਦੱਸੋ ਜੋ ਕਿਸੇ ਹੋਰ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਉਸਦੇ ਚਿਹਰੇ 'ਤੇ ਨਿਰਾਸ਼ਾ ਦੇਖੋਗੇ.

PHP ਇੰਜੀਨੀਅਰ ਚਲਾਕ ਆਲਸੀ ਲੋਡਿੰਗ ਤਕਨੀਕਾਂ, ਮਾਈਕ੍ਰੋਫਰੇਮਵਰਕ, ਅਨੁਕੂਲਿਤ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਕੈਸ਼, ਆਦਿ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਸਾਲਾਂ ਤੋਂ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੇ ਤਰੀਕੇ ਲੱਭ ਰਹੇ ਹਨ। ਪਰ ਅੰਤ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਰੀਸੈਟ ਕਰਨਾ ਪਵੇਗਾ ਅਤੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨਾ ਪਵੇਗਾ। (ਅਨੁਵਾਦਕ ਦਾ ਨੋਟ: ਇਹ ਸਮੱਸਿਆ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਦੇ ਆਗਮਨ ਨਾਲ ਹੱਲ ਹੋ ਜਾਵੇਗੀ ਪ੍ਰੀਲੋਡ PHP 7.4 ਵਿੱਚ)

ਕੀ ਗੋ ਨਾਲ PHP ਇੱਕ ਤੋਂ ਵੱਧ ਬੇਨਤੀਆਂ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ?

PHP ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਲਿਖਣਾ ਸੰਭਵ ਹੈ ਜੋ ਕੁਝ ਮਿੰਟਾਂ (ਘੰਟਿਆਂ ਜਾਂ ਦਿਨਾਂ ਤੱਕ) ਤੋਂ ਵੱਧ ਰਹਿੰਦੀਆਂ ਹਨ: ਉਦਾਹਰਨ ਲਈ, ਕ੍ਰੋਨ ਟਾਸਕ, CSV ਪਾਰਸਰ, ਕਤਾਰ ਤੋੜਨ ਵਾਲੇ। ਉਹ ਸਾਰੇ ਇੱਕੋ ਦ੍ਰਿਸ਼ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੇ ਹਨ: ਉਹ ਇੱਕ ਕੰਮ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਇਸਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਅਤੇ ਅਗਲੇ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹਨ। ਕੋਡ ਹਰ ਸਮੇਂ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਕੀਮਤੀ ਮਿਲੀਸਕਿੰਟ ਦੀ ਬਚਤ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਫਰੇਮਵਰਕ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਲੋਡ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਵਾਧੂ ਕਦਮਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਪਰ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੀਆਂ ਲਿਪੀਆਂ ਨੂੰ ਵਿਕਸਿਤ ਕਰਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ। ਕੋਈ ਵੀ ਗਲਤੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰ ਦਿੰਦੀ ਹੈ, ਮੈਮੋਰੀ ਲੀਕ ਦਾ ਨਿਦਾਨ ਕਰਨਾ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲਾ ਹੈ, ਅਤੇ F5 ਡੀਬੱਗਿੰਗ ਹੁਣ ਸੰਭਵ ਨਹੀਂ ਹੈ।

PHP 7 ਦੇ ਜਾਰੀ ਹੋਣ ਨਾਲ ਸਥਿਤੀ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ ਹੈ: ਇੱਕ ਭਰੋਸੇਯੋਗ ਕੂੜਾ ਇਕੱਠਾ ਕਰਨ ਵਾਲਾ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ, ਗਲਤੀਆਂ ਨੂੰ ਸੰਭਾਲਣਾ ਆਸਾਨ ਹੋ ਗਿਆ ਹੈ, ਅਤੇ ਕਰਨਲ ਐਕਸਟੈਂਸ਼ਨ ਹੁਣ ਲੀਕ-ਪਰੂਫ ਹਨ। ਇਹ ਸੱਚ ਹੈ, ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਅਜੇ ਵੀ ਮੈਮੋਰੀ ਦੇ ਨਾਲ ਸਾਵਧਾਨ ਰਹਿਣ ਅਤੇ ਕੋਡ ਵਿੱਚ ਰਾਜ ਦੇ ਮੁੱਦਿਆਂ ਤੋਂ ਜਾਣੂ ਹੋਣ ਦੀ ਲੋੜ ਹੈ (ਕੀ ਕੋਈ ਅਜਿਹੀ ਭਾਸ਼ਾ ਹੈ ਜੋ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦੀ ਹੈ?). ਫਿਰ ਵੀ, PHP 7 ਸਾਡੇ ਲਈ ਸਟੋਰ ਵਿੱਚ ਘੱਟ ਹੈਰਾਨੀ ਹੈ.

ਕੀ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਹੀਆਂ PHP ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਮਾਡਲ ਨੂੰ ਲੈਣਾ ਸੰਭਵ ਹੈ, ਇਸਨੂੰ HTTP ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵਰਗੇ ਹੋਰ ਮਾਮੂਲੀ ਕੰਮਾਂ ਲਈ ਅਨੁਕੂਲ ਬਣਾਉਣਾ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹਰੇਕ ਬੇਨਤੀ ਦੇ ਨਾਲ ਸਕ੍ਰੈਚ ਤੋਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਲੋਡ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣਾ ਸੰਭਵ ਹੈ?

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਪਹਿਲਾਂ ਇੱਕ ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਸੀ ਜੋ HTTP ਬੇਨਤੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹਰ ਵਾਰ ਮਾਰੇ ਬਿਨਾਂ PHP ਵਰਕਰ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਰੀਡਾਇਰੈਕਟ ਕਰ ਸਕਦਾ ਹੈ।

ਅਸੀਂ ਜਾਣਦੇ ਸੀ ਕਿ ਅਸੀਂ ਇੱਕ ਵੈਬ ਸਰਵਰ ਨੂੰ ਸ਼ੁੱਧ PHP (PHP-PM) ਵਿੱਚ ਜਾਂ ਇੱਕ C ਐਕਸਟੈਂਸ਼ਨ (Swoole) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਿਖ ਸਕਦੇ ਹਾਂ। ਅਤੇ ਹਾਲਾਂਕਿ ਹਰੇਕ ਵਿਧੀ ਦੇ ਆਪਣੇ ਗੁਣ ਹਨ, ਦੋਵੇਂ ਵਿਕਲਪ ਸਾਡੇ ਅਨੁਕੂਲ ਨਹੀਂ ਸਨ - ਅਸੀਂ ਕੁਝ ਹੋਰ ਚਾਹੁੰਦੇ ਸੀ. ਸਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਵੈਬ ਸਰਵਰ ਤੋਂ ਵੱਧ ਦੀ ਲੋੜ ਸੀ - ਸਾਨੂੰ ਇੱਕ ਹੱਲ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਉਮੀਦ ਸੀ ਜੋ ਸਾਨੂੰ PHP ਵਿੱਚ "ਸਖਤ ਸ਼ੁਰੂਆਤ" ਨਾਲ ਜੁੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਉਸੇ ਸਮੇਂ ਖਾਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਆਸਾਨੀ ਨਾਲ ਅਨੁਕੂਲਿਤ ਅਤੇ ਵਧਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਭਾਵ, ਸਾਨੂੰ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਦੀ ਲੋੜ ਸੀ।

ਕੀ ਗੋ ਇਸ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ? ਅਸੀਂ ਜਾਣਦੇ ਸੀ ਕਿ ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਭਾਸ਼ਾ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸਿੰਗਲ ਬਾਈਨਰੀਆਂ ਵਿੱਚ ਕੰਪਾਇਲ ਕਰਦੀ ਹੈ; ਇਹ ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਹੈ; HTTP ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਇਸਦੇ ਆਪਣੇ, ਬਹੁਤ ਹੀ ਸ਼ਾਨਦਾਰ, ਸਮਾਨਾਂਤਰ ਪ੍ਰੋਸੈਸਿੰਗ ਮਾਡਲ (ਇਕਸਾਰਤਾ) ਅਤੇ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ; ਅਤੇ ਅੰਤ ਵਿੱਚ, ਹਜ਼ਾਰਾਂ ਓਪਨ-ਸੋਰਸ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਏਕੀਕਰਣ ਸਾਡੇ ਲਈ ਉਪਲਬਧ ਹੋਣਗੇ।

ਦੋ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਜੋੜਨ ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ ਕਿ ਦੋ ਜਾਂ ਦੋ ਤੋਂ ਵੱਧ ਐਪਲੀਕੇਸ਼ਨਾਂ ਇੱਕ ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਸੰਚਾਰ ਕਰਨਗੀਆਂ.

ਉਦਾਹਰਨ ਲਈ, ਵਰਤ ਸ਼ਾਨਦਾਰ ਲਾਇਬ੍ਰੇਰੀ ਐਲੇਕਸ ਪੈਲੇਸਟ੍ਰਾਸ, PHP ਅਤੇ ਗੋ ਪ੍ਰਕਿਰਿਆਵਾਂ (ਅਪਾਚੇ ਵਿੱਚ mod_php ਦੇ ਸਮਾਨ) ਵਿਚਕਾਰ ਮੈਮੋਰੀ ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਸੰਭਵ ਸੀ। ਪਰ ਇਸ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਅਜਿਹੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ ਜੋ ਸਾਡੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਨੂੰ ਸੀਮਤ ਕਰਦੀਆਂ ਹਨ।

ਅਸੀਂ ਇੱਕ ਵੱਖਰੀ, ਵਧੇਰੇ ਆਮ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ: ਸਾਕਟਾਂ / ਪਾਈਪਲਾਈਨਾਂ ਰਾਹੀਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ ਬਣਾਉਣ ਲਈ। ਇਹ ਪਹੁੰਚ ਪਿਛਲੇ ਦਹਾਕਿਆਂ ਦੌਰਾਨ ਭਰੋਸੇਮੰਦ ਸਾਬਤ ਹੋਈ ਹੈ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਪੱਧਰ 'ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲਿਤ ਕੀਤੀ ਗਈ ਹੈ।

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿਚਕਾਰ ਡੇਟਾ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਨ ਅਤੇ ਟ੍ਰਾਂਸਮਿਸ਼ਨ ਗਲਤੀਆਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਇੱਕ ਸਧਾਰਨ ਬਾਈਨਰੀ ਪ੍ਰੋਟੋਕੋਲ ਬਣਾਇਆ ਹੈ। ਇਸਦੇ ਸਰਲ ਰੂਪ ਵਿੱਚ, ਇਸ ਕਿਸਮ ਦੇ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਸਮਾਨ ਹੈ netstring с ਸਥਿਰ ਆਕਾਰ ਦਾ ਪੈਕੇਟ ਹੈਡਰ (ਸਾਡੇ ਕੇਸ ਵਿੱਚ 17 ਬਾਈਟ), ਜਿਸ ਵਿੱਚ ਪੈਕੇਟ ਦੀ ਕਿਸਮ, ਇਸਦੇ ਆਕਾਰ ਅਤੇ ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਬਾਈਨਰੀ ਮਾਸਕ ਬਾਰੇ ਜਾਣਕਾਰੀ ਸ਼ਾਮਲ ਹੈ।

PHP ਵਾਲੇ ਪਾਸੇ ਅਸੀਂ ਵਰਤਿਆ ਪੈਕ ਫੰਕਸ਼ਨ, ਅਤੇ ਗੋ ਸਾਈਡ 'ਤੇ, ਲਾਇਬ੍ਰੇਰੀ ਏਨਕੋਡਿੰਗ/ਬਾਈਨਰੀ.

ਇਹ ਸਾਡੇ ਲਈ ਜਾਪਦਾ ਸੀ ਕਿ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਕਾਫ਼ੀ ਨਹੀਂ ਸੀ - ਅਤੇ ਅਸੀਂ ਕਾਲ ਕਰਨ ਦੀ ਯੋਗਤਾ ਨੂੰ ਜੋੜਿਆ PHP ਤੋਂ ਸਿੱਧਾ net/rpc ਗੋ ਸੇਵਾਵਾਂ. ਬਾਅਦ ਵਿੱਚ, ਇਸ ਨੇ ਵਿਕਾਸ ਵਿੱਚ ਸਾਡੀ ਬਹੁਤ ਮਦਦ ਕੀਤੀ, ਕਿਉਂਕਿ ਅਸੀਂ ਆਸਾਨੀ ਨਾਲ ਗੋ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ PHP ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਜੋੜ ਸਕਦੇ ਹਾਂ। ਇਸ ਕੰਮ ਦਾ ਨਤੀਜਾ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਦੂਜੇ ਓਪਨ-ਸੋਰਸ ਉਤਪਾਦ ਵਿੱਚ ਗੋਰਿਜ.

ਕਈ PHP ਵਰਕਰਾਂ ਵਿੱਚ ਕਾਰਜਾਂ ਨੂੰ ਵੰਡਣਾ

ਇੰਟਰਐਕਸ਼ਨ ਵਿਧੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਕਾਰਜਾਂ ਨੂੰ PHP ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਦੇ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵੀ ਤਰੀਕੇ ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਜਦੋਂ ਕੋਈ ਕੰਮ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਨੂੰ ਇਸਨੂੰ ਚਲਾਉਣ ਲਈ ਇੱਕ ਮੁਫਤ ਕਰਮਚਾਰੀ ਦੀ ਚੋਣ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਜੇਕਰ ਕੋਈ ਕਰਮਚਾਰੀ/ਪ੍ਰਕਿਰਿਆ ਕਿਸੇ ਗਲਤੀ ਨਾਲ ਬਾਹਰ ਹੋ ਜਾਂਦੀ ਹੈ ਜਾਂ "ਮਰ ਜਾਂਦੀ ਹੈ", ਤਾਂ ਅਸੀਂ ਇਸ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾ ਲੈਂਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਬਦਲਣ ਲਈ ਇੱਕ ਨਵਾਂ ਬਣਾ ਲੈਂਦੇ ਹਾਂ। ਅਤੇ ਜੇਕਰ ਵਰਕਰ/ਪ੍ਰਕਿਰਿਆ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰੀ ਹੋ ਗਈ ਹੈ, ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ ਕੰਮ ਕਰਨ ਲਈ ਉਪਲਬਧ ਕਰਮਚਾਰੀਆਂ ਦੇ ਪੂਲ ਵਿੱਚ ਵਾਪਸ ਕਰ ਦਿੰਦੇ ਹਾਂ।

ਸਰਗਰਮ ਵਰਕਰਾਂ ਦੇ ਪੂਲ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ, ਅਸੀਂ ਵਰਤਿਆ ਬਫਰ ਚੈਨਲ, ਪੂਲ ਤੋਂ ਅਚਾਨਕ "ਮ੍ਰਿਤ" ਵਰਕਰਾਂ ਨੂੰ ਹਟਾਉਣ ਲਈ, ਅਸੀਂ ਗਲਤੀਆਂ ਅਤੇ ਕਰਮਚਾਰੀਆਂ ਦੀਆਂ ਸਥਿਤੀਆਂ ਨੂੰ ਟਰੈਕ ਕਰਨ ਲਈ ਇੱਕ ਵਿਧੀ ਸ਼ਾਮਲ ਕੀਤੀ ਹੈ।

ਨਤੀਜੇ ਵਜੋਂ, ਸਾਨੂੰ ਇੱਕ ਕਾਰਜਸ਼ੀਲ PHP ਸਰਵਰ ਮਿਲਿਆ ਹੈ ਜੋ ਬਾਈਨਰੀ ਰੂਪ ਵਿੱਚ ਪੇਸ਼ ਕੀਤੀਆਂ ਗਈਆਂ ਕਿਸੇ ਵੀ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹੈ।

ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਵੈੱਬ ਸਰਵਰ ਵਜੋਂ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਕਿਸੇ ਵੀ ਆਉਣ ਵਾਲੀਆਂ HTTP ਬੇਨਤੀਆਂ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਇੱਕ ਭਰੋਸੇਯੋਗ PHP ਸਟੈਂਡਰਡ ਦੀ ਚੋਣ ਕਰਨੀ ਪਈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਅਸੀਂ ਸਿਰਫ਼ ਬਦਲਣਾ ਫਾਰਮੈਟ 'ਤੇ ਜਾਓ ਤੋਂ net/http ਬੇਨਤੀ PSR-7ਇਸ ਲਈ ਇਹ ਅੱਜ ਉਪਲਬਧ ਜ਼ਿਆਦਾਤਰ PHP ਫਰੇਮਵਰਕ ਦੇ ਅਨੁਕੂਲ ਹੈ।

ਕਿਉਂਕਿ PSR-7 ਨੂੰ ਅਟੱਲ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ (ਕੁਝ ਕਹਿੰਦੇ ਹਨ ਕਿ ਇਹ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਨਹੀਂ ਹੈ), ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਲਿਖਣੀਆਂ ਪੈਂਦੀਆਂ ਹਨ ਜੋ ਸਿਧਾਂਤ ਵਿੱਚ ਇੱਕ ਗਲੋਬਲ ਇਕਾਈ ਵਜੋਂ ਬੇਨਤੀ ਨੂੰ ਨਹੀਂ ਮੰਨਦੀਆਂ। ਇਹ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੀਆਂ PHP ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸੰਕਲਪ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਬੈਠਦਾ ਹੈ। ਸਾਡਾ ਅੰਤਮ ਲਾਗੂਕਰਨ, ਜਿਸਦਾ ਨਾਮ ਅਜੇ ਬਾਕੀ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਪੇਸ਼ ਹੈ ਰੋਡ ਰਨਰ - ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ PHP ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ

ਸਾਡਾ ਪਹਿਲਾ ਟੈਸਟ ਟਾਸਕ ਇੱਕ API ਬੈਕਐਂਡ ਸੀ, ਜੋ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਅਣ-ਅਨੁਮਾਨਿਤ ਬੇਨਤੀਆਂ ਵਿੱਚ ਫਟਦਾ ਹੈ (ਆਮ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ)। ਹਾਲਾਂਕਿ nginx ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਕਾਫੀ ਸੀ, ਸਾਨੂੰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ 502 ਗਲਤੀਆਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਕਿਉਂਕਿ ਅਸੀਂ ਲੋਡ ਵਿੱਚ ਸੰਭਾਵਿਤ ਵਾਧੇ ਲਈ ਤੇਜ਼ੀ ਨਾਲ ਸਿਸਟਮ ਨੂੰ ਸੰਤੁਲਿਤ ਨਹੀਂ ਕਰ ਸਕੇ।

ਇਸ ਹੱਲ ਨੂੰ ਬਦਲਣ ਲਈ, ਅਸੀਂ 2018 ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਆਪਣਾ ਪਹਿਲਾ PHP/Go ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਤੈਨਾਤ ਕੀਤਾ ਸੀ। ਅਤੇ ਤੁਰੰਤ ਇੱਕ ਸ਼ਾਨਦਾਰ ਪ੍ਰਭਾਵ ਪ੍ਰਾਪਤ ਕੀਤਾ! ਅਸੀਂ ਨਾ ਸਿਰਫ 502 ਗਲਤੀ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੁਟਕਾਰਾ ਪਾਇਆ, ਪਰ ਅਸੀਂ ਇੰਜੀਨੀਅਰਾਂ ਅਤੇ ਉਤਪਾਦ ਪ੍ਰਬੰਧਕਾਂ ਲਈ ਬਹੁਤ ਸਾਰਾ ਪੈਸਾ ਅਤੇ ਸਿਰ ਦਰਦ ਦੀਆਂ ਗੋਲੀਆਂ ਦੀ ਬਚਤ ਕਰਕੇ ਸਰਵਰਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਦੋ-ਤਿਹਾਈ ਤੱਕ ਘਟਾਉਣ ਦੇ ਯੋਗ ਹੋ ਗਏ.

ਸਾਲ ਦੇ ਮੱਧ ਤੱਕ, ਅਸੀਂ ਆਪਣੇ ਹੱਲ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ ਸੀ, ਇਸਨੂੰ MIT ਲਾਇਸੈਂਸ ਦੇ ਤਹਿਤ GitHub 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਅਤੇ ਇਸਦਾ ਨਾਮ ਦਿੱਤਾ। ਰੋਡ ਰਨਰ, ਇਸ ਤਰ੍ਹਾਂ ਇਸਦੀ ਸ਼ਾਨਦਾਰ ਗਤੀ ਅਤੇ ਕੁਸ਼ਲਤਾ 'ਤੇ ਜ਼ੋਰ ਦਿੱਤਾ ਗਿਆ।

ਰੋਡ ਰਨਰ ਤੁਹਾਡੇ ਵਿਕਾਸ ਸਟੈਕ ਨੂੰ ਕਿਵੇਂ ਸੁਧਾਰ ਸਕਦਾ ਹੈ

ਐਪਲੀਕੇਸ਼ਨ ਰੋਡ ਰਨਰ ਬੇਨਤੀ ਦੇ PHP ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ JWT ਤਸਦੀਕ ਕਰਨ ਲਈ ਗੋ ਸਾਈਡ 'ਤੇ ਮਿਡਲਵੇਅਰ ਨੈੱਟ/http ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ, ਨਾਲ ਹੀ ਪ੍ਰੋਮੀਥੀਅਸ ਵਿੱਚ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ WebSockets ਅਤੇ ਸਮੁੱਚੀ ਸਥਿਤੀ ਨੂੰ ਹੈਂਡਲ ਕਰਨ ਲਈ।

ਬਿਲਟ-ਇਨ ਆਰਪੀਸੀ ਲਈ ਧੰਨਵਾਦ, ਤੁਸੀਂ ਐਕਸਟੈਂਸ਼ਨ ਰੈਪਰਾਂ ਨੂੰ ਲਿਖੇ ਬਿਨਾਂ PHP ਲਈ ਕਿਸੇ ਵੀ ਗੋ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ API ਨੂੰ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ। ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ, ਰੋਡਰਨਰ ਨਾਲ ਤੁਸੀਂ ਨਵੇਂ ਗੈਰ-HTTP ਸਰਵਰਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨਾਂ ਵਿੱਚ PHP ਵਿੱਚ ਚੱਲ ਰਹੇ ਹੈਂਡਲਰ ਸ਼ਾਮਲ ਹਨ AWS Lambda, ਭਰੋਸੇਯੋਗ ਕਤਾਰ ਤੋੜਨ ਵਾਲੇ ਬਣਾਉਣਾ, ਅਤੇ ਜੋੜਨਾ ਵੀ ਜੀਆਰਪੀਸੀ ਸਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ.

PHP ਅਤੇ ਗੋ ਭਾਈਚਾਰਿਆਂ ਦੀ ਮਦਦ ਨਾਲ, ਅਸੀਂ ਹੱਲ ਦੀ ਸਥਿਰਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ, ਕੁਝ ਟੈਸਟਾਂ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ 40 ਗੁਣਾ ਤੱਕ ਵਧਾਇਆ, ਡੀਬੱਗਿੰਗ ਟੂਲ ਵਿੱਚ ਸੁਧਾਰ ਕੀਤਾ, ਸਿਮਫਨੀ ਫਰੇਮਵਰਕ ਨਾਲ ਏਕੀਕਰਣ ਨੂੰ ਲਾਗੂ ਕੀਤਾ, ਅਤੇ HTTPS, HTTP/2, ਲਈ ਸਮਰਥਨ ਜੋੜਿਆ। ਪਲੱਗਇਨ, ਅਤੇ PSR-17.

ਸਿੱਟਾ

ਕੁਝ ਲੋਕ ਅਜੇ ਵੀ PHP ਦੀ ਇੱਕ ਹੌਲੀ, ਬੇਲੋੜੀ ਭਾਸ਼ਾ ਦੇ ਰੂਪ ਵਿੱਚ ਪੁਰਾਣੀ ਧਾਰਨਾ ਵਿੱਚ ਫਸੇ ਹੋਏ ਹਨ ਜੋ ਸਿਰਫ ਵਰਡਪਰੈਸ ਲਈ ਪਲੱਗਇਨ ਲਿਖਣ ਲਈ ਚੰਗੀ ਹੈ। ਇਹ ਲੋਕ ਇਹ ਵੀ ਕਹਿ ਸਕਦੇ ਹਨ ਕਿ PHP ਦੀ ਅਜਿਹੀ ਸੀਮਾ ਹੈ: ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਕਾਫ਼ੀ ਵੱਡੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਹੋਰ "ਪਰਿਪੱਕ" ਭਾਸ਼ਾ ਦੀ ਚੋਣ ਕਰਨੀ ਪਵੇਗੀ ਅਤੇ ਕਈ ਸਾਲਾਂ ਤੋਂ ਇਕੱਠੇ ਹੋਏ ਕੋਡ ਬੇਸ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪਵੇਗਾ।

ਇਸ ਸਭ ਲਈ ਮੈਂ ਜਵਾਬ ਦੇਣਾ ਚਾਹੁੰਦਾ ਹਾਂ: ਦੁਬਾਰਾ ਸੋਚੋ. ਸਾਡਾ ਮੰਨਣਾ ਹੈ ਕਿ ਸਿਰਫ ਤੁਸੀਂ PHP ਲਈ ਕੋਈ ਪਾਬੰਦੀਆਂ ਸੈਟ ਕਰਦੇ ਹੋ। ਤੁਸੀਂ ਆਪਣੀ ਪੂਰੀ ਜ਼ਿੰਦਗੀ ਇੱਕ ਭਾਸ਼ਾ ਤੋਂ ਦੂਜੀ ਭਾਸ਼ਾ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਵਿੱਚ ਬਿਤਾ ਸਕਦੇ ਹੋ, ਆਪਣੀਆਂ ਲੋੜਾਂ ਲਈ ਸੰਪੂਰਣ ਮੇਲ ਲੱਭਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਤੁਸੀਂ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਔਜ਼ਾਰਾਂ ਵਜੋਂ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ। PHP ਵਰਗੀ ਭਾਸ਼ਾ ਦੀਆਂ ਮੰਨੀਆਂ ਗਈਆਂ ਖਾਮੀਆਂ ਅਸਲ ਵਿੱਚ ਇਸਦੀ ਸਫਲਤਾ ਦਾ ਕਾਰਨ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਨੂੰ ਗੋ ਵਰਗੀ ਕਿਸੇ ਹੋਰ ਭਾਸ਼ਾ ਨਾਲ ਜੋੜਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਉਸ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਸ਼ਕਤੀਸ਼ਾਲੀ ਉਤਪਾਦ ਬਣਾਉਗੇ ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਇੱਕ ਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੱਕ ਸੀਮਿਤ ਸੀ।

ਗੋ ਅਤੇ PHP ਦੇ ਇੱਕ ਸਮੂਹ ਨਾਲ ਕੰਮ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪਿਆਰ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਇੱਕ ਦੂਜੇ ਲਈ ਕੁਰਬਾਨ ਕਰਨ ਦੀ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਉਂਦੇ - ਇਸਦੇ ਉਲਟ, ਅਸੀਂ ਇਸ ਦੋਹਰੇ ਸਟੈਕ ਤੋਂ ਹੋਰ ਵੀ ਵੱਧ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਤਰੀਕੇ ਲੱਭਾਂਗੇ.

UPD: ਅਸੀਂ RoadRunner ਦੇ ਨਿਰਮਾਤਾ ਅਤੇ ਮੂਲ ਲੇਖ ਦੇ ਸਹਿ-ਲੇਖਕ ਦਾ ਸਵਾਗਤ ਕਰਦੇ ਹਾਂ - ਲੈਕੇਸਿਸ

ਸਰੋਤ: www.habr.com