PHP-FPM ਸੈੱਟਅੱਪ: ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਦਰਸ਼ਨ ਲਈ pm ਸਥਿਰ ਦੀ ਵਰਤੋਂ ਕਰੋ

ਇਸ ਲੇਖ ਦਾ ਇੱਕ ਸੰਪਾਦਿਤ ਸੰਸਕਰਣ ਅਸਲ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਸੀ haydenjames.io ਅਤੇ ਉਸਦੀ ਇਜਾਜ਼ਤ ਨਾਲ ਇੱਥੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਲੇਖਕ.

ਮੈਂ ਤੁਹਾਨੂੰ ਸੰਖੇਪ ਵਿੱਚ ਦੱਸਾਂਗਾ ਕਿ ਥ੍ਰੁਪੁੱਟ ਨੂੰ ਵਧਾਉਣ, ਲੇਟੈਂਸੀ ਨੂੰ ਘਟਾਉਣ, ਅਤੇ CPU ਅਤੇ ਮੈਮੋਰੀ ਨੂੰ ਲਗਾਤਾਰ ਵਰਤਣ ਲਈ PHP-FPM ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ, PHP-FPM ਵਿੱਚ PM (ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਬੰਧਕ) ਲਾਈਨ ਹੈ ਡਾਇਨਾਮਿਕ, ਅਤੇ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਲੋੜੀਂਦੀ ਮੈਮੋਰੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਇੰਸਟਾਲ ਕਰਨਾ ਬਿਹਤਰ ਹੈ ਮੰਗ ਉੱਤੇ. ਆਉ php.net ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਅਧਾਰ ਤੇ 2 ਨਿਯੰਤਰਣ ਵਿਕਲਪਾਂ ਦੀ ਤੁਲਨਾ ਕਰੀਏ ਅਤੇ ਵੇਖੀਏ ਕਿ ਮੇਰਾ ਮਨਪਸੰਦ ਉਹਨਾਂ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰਾ ਹੈ ਸਥਿਰ ਹਾਈ ਵੌਲਯੂਮ ਟ੍ਰੈਫਿਕ ਲਈ pm:

pm = ਗਤੀਸ਼ੀਲ — ਬਾਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਗਤੀਸ਼ੀਲ ਰੂਪ ਨਾਲ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = ਮੰਗ - ਪ੍ਰਕਿਰਿਆਵਾਂ ਮੰਗ 'ਤੇ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ (ਡਾਇਨੈਮਿਕ ਰਚਨਾ ਦੇ ਉਲਟ, ਜਦੋਂ ਸੇਵਾ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ pm.start_servers ਲਾਂਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ)।
pm = ਸਥਿਰ — ਬਾਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਗਿਣਤੀ ਨਿਸ਼ਚਿਤ ਕੀਤੀ ਗਈ ਹੈ ਅਤੇ ਪੈਰਾਮੀਟਰ ਦੁਆਰਾ ਦਰਸਾਈ ਗਈ ਹੈ pm.max_children.

ਵੇਰਵਿਆਂ ਲਈ, ਵੇਖੋ ਗਲੋਬਲ ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਪੂਰੀ ਸੂਚੀ php-fpm.conf.

PHP-FPM ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਬੰਧਕ ਅਤੇ CPU ਬਾਰੰਬਾਰਤਾ ਕੰਟਰੋਲਰ ਵਿਚਕਾਰ ਸਮਾਨਤਾਵਾਂ

ਇਹ ਆਫਟੌਪਿਕ ਜਾਪਦਾ ਹੈ, ਪਰ ਮੈਂ ਇਸਨੂੰ PHP-FPM ਸੰਰਚਨਾ ਦੇ ਵਿਸ਼ੇ ਨਾਲ ਲਿੰਕ ਕਰਨ ਜਾ ਰਿਹਾ ਹਾਂ। ਕਿਸ ਨੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ ਪ੍ਰੋਸੈਸਰ ਦੀ ਸੁਸਤੀ ਦਾ ਅਨੁਭਵ ਨਹੀਂ ਕੀਤਾ ਹੈ - ਇੱਕ ਲੈਪਟਾਪ, ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਜਾਂ ਸਮਰਪਿਤ ਸਰਵਰ 'ਤੇ? CPU ਬਾਰੰਬਾਰਤਾ ਸਕੇਲਿੰਗ ਨੂੰ ਯਾਦ ਰੱਖੋ? ਲਈ ਇਹ ਵਿਕਲਪ ਉਪਲਬਧ ਹਨ ਤੋਂ ਪ੍ਰੋਸੈਸਰ ਥ੍ਰੋਟਲ ਸੈਟਿੰਗ ਨੂੰ ਬਦਲ ਕੇ nix ਅਤੇ Windows ਸਿਸਟਮ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਜਵਾਬਦੇਹੀ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕਦੇ ਹਨ ਮੰਗ ਉੱਤੇ 'ਤੇ ਪ੍ਰਦਰਸ਼ਨ*. ਇਸ ਵਾਰ, ਆਓ ਵਰਣਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰੀਏ ਅਤੇ ਸਮਾਨਤਾਵਾਂ ਨੂੰ ਵੇਖੀਏ:

ਗਵਰਨਰ = ਮੰਗ - ਮੌਜੂਦਾ ਲੋਡ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ਪ੍ਰੋਸੈਸਰ ਦੀ ਬਾਰੰਬਾਰਤਾ ਦੀ ਗਤੀਸ਼ੀਲ ਸਕੇਲਿੰਗ। ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਤੋਂ ਵੱਧ ਬਾਰੰਬਾਰਤਾ 'ਤੇ ਛਾਲ ਮਾਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਇਸ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਅਕਿਰਿਆਸ਼ੀਲਤਾ ਦੇ ਸਮੇਂ ਵਧਦੇ ਹਨ।
ਗਵਰਨਰ=ਰੂੜੀਵਾਦੀ= ਮੌਜੂਦਾ ਲੋਡ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ ਗਤੀਸ਼ੀਲ ਬਾਰੰਬਾਰਤਾ ਸਕੇਲਿੰਗ। ਔਨਡਿਮਾਂਡ ਦੇ ਮੁਕਾਬਲੇ ਬਾਰੰਬਾਰਤਾ ਨੂੰ ਵਧਾਉਂਦਾ ਅਤੇ ਘਟਾਉਂਦਾ ਹੈ।
ਗਵਰਨਰ = ਕਾਰਗੁਜ਼ਾਰੀ - ਬਾਰੰਬਾਰਤਾ ਹਮੇਸ਼ਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਹੁੰਦੀ ਹੈ.

ਵੇਰਵਿਆਂ ਲਈ, ਵੇਖੋ ਪ੍ਰੋਸੈਸਰ ਬਾਰੰਬਾਰਤਾ ਰੈਗੂਲੇਟਰ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਪੂਰੀ ਸੂਚੀ.

ਸਮਾਨਤਾਵਾਂ ਦੇਖੋ? ਮੈਂ ਤੁਹਾਨੂੰ ਯਕੀਨ ਦਿਵਾਉਣ ਲਈ ਇਹ ਤੁਲਨਾ ਦਿਖਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ pm ਸਥਿਰ PHP-FPM ਲਈ।

ਪ੍ਰੋਸੈਸਰ ਰੈਗੂਲੇਟਰ ਪੈਰਾਮੀਟਰ ਲਈ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਵਧਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਰਵਰ ਦੀ CPU ਸੀਮਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਬੇਸ਼ੱਕ, ਤਾਪਮਾਨ, ਬੈਟਰੀ ਚਾਰਜ (ਲੈਪਟਾਪ ਵਿੱਚ) ਅਤੇ ਪ੍ਰੋਸੈਸਰ ਨੂੰ 100% 'ਤੇ ਲਗਾਤਾਰ ਚਲਾਉਣ ਦੇ ਹੋਰ ਮਾੜੇ ਪ੍ਰਭਾਵਾਂ ਵਰਗੇ ਕਾਰਕ ਵੀ ਹਨ। ਪ੍ਰਦਰਸ਼ਨ ਸੈਟਿੰਗ ਸਭ ਤੋਂ ਤੇਜ਼ ਪ੍ਰੋਸੈਸਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ। ਪੜ੍ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਬਾਰੇ Raspberry Pi ਵਿੱਚ force_turbo ਪੈਰਾਮੀਟਰਜਿਸ ਨਾਲ ਆਰਪੀਆਈ ਪੈਨਲ ਰੈਗੂਲੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ, ਜਿੱਥੇ ਘੱਟ CPU ਕਲਾਕ ਸਪੀਡ ਦੇ ਕਾਰਨ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਵਧੇਰੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੋਵੇਗਾ।

ਵੱਧ ਤੋਂ ਵੱਧ ਸਰਵਰ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ pm ਸਥਿਰ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

PHP-FPM ਵਿਕਲਪ pm ਸਥਿਰ ਜ਼ਿਆਦਾਤਰ ਸਰਵਰ 'ਤੇ ਮੁਫਤ ਮੈਮੋਰੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜੇ ਮੈਮੋਰੀ ਘੱਟ ਹੈ, ਤਾਂ ਇਹ ਚੁਣਨਾ ਬਿਹਤਰ ਹੈ ਮੰਗ ਉੱਤੇ ਜ ਡਾਇਨਾਮਿਕ. ਦੂਜੇ ਪਾਸੇ, ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਮੈਮੋਰੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ pm ਸੈੱਟ ਕਰਕੇ PHP ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਬੰਧਕ ਓਵਰਹੈੱਡ ਤੋਂ ਬਚ ਸਕਦੇ ਹੋ ਸਥਿਰ ਸਰਵਰ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਰੱਥਾ ਤੱਕ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਜੇ ਸਭ ਕੁਝ ਚੰਗੀ ਤਰ੍ਹਾਂ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ pm.static PHP-FPM ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਅਧਿਕਤਮ ਮਾਤਰਾ ਤੱਕ, ਜੋ ਕਿ ਚਲਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਘੱਟ ਮੈਮੋਰੀ ਜਾਂ ਕੈਸ਼ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕੀਤੇ ਬਿਨਾਂ। ਪਰ ਇੰਨਾ ਉੱਚਾ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਪ੍ਰੋਸੈਸਰਾਂ ਨੂੰ ਹਾਵੀ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ PHP-FPM ਓਪਰੇਸ਼ਨਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਇਕੱਠਾ ਕਰਦਾ ਹੈ ਜੋ ਚੱਲਣ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਨ।.

ਉਪਰੋਕਤ ਸਕ੍ਰੀਨਸ਼ਾਟ ਵਿੱਚ, ਸਰਵਰ ਕੋਲ ਹੈ pm = ਸਥਿਰ ਅਤੇ pm.max_children = 100, ਅਤੇ ਇਹ ਉਪਲਬਧ 10 ਵਿੱਚੋਂ ਲਗਭਗ 32 GB ਲੈਂਦਾ ਹੈ। ਉਜਾਗਰ ਕੀਤੇ ਕਾਲਮਾਂ ਵੱਲ ਧਿਆਨ ਦਿਓ, ਇੱਥੇ ਸਭ ਕੁਝ ਸਪੱਸ਼ਟ ਹੈ। ਇਸ ਸਕ੍ਰੀਨਸ਼ੌਟ ਵਿੱਚ ਗੂਗਲ ਵਿਸ਼ਲੇਸ਼ਣ ਵਿੱਚ ਲਗਭਗ 200 ਸਰਗਰਮ ਉਪਭੋਗਤਾ (60 ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ) ਸਨ। ਇਸ ਪੱਧਰ 'ਤੇ, ਲਗਭਗ 70% PHP-FPM ਬਾਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਜੇ ਵੀ ਨਿਸ਼ਕਿਰਿਆ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮੌਜੂਦਾ ਟ੍ਰੈਫਿਕ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ PHP-FPM ਹਮੇਸ਼ਾਂ ਸਰਵਰ ਸਰੋਤਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਮਾਤਰਾ 'ਤੇ ਸੈੱਟ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਵਿਹਲੀ ਪ੍ਰਕਿਰਿਆ ਟ੍ਰੈਫਿਕ ਸਿਖਰਾਂ ਦੀ ਉਡੀਕ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਰੰਤ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਇੰਤਜ਼ਾਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ pm ਚਾਈਲਡ ਪ੍ਰਕਿਰਿਆਵਾਂ ਬਣਾਵੇਗਾ ਅਤੇ ਫਿਰ ਮਿਆਦ ਦੀ ਮਿਆਦ ਪੁੱਗਣ 'ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਖਤਮ ਕਰ ਦੇਵੇਗਾ pm.process_idle_timeout. ਮੈਂ ਮੁੱਲ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੈੱਟ ਕੀਤਾ ਹੈ pm.max_requestsਕਿਉਂਕਿ ਇਹ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਸਰਵਰ ਹੈ ਜਿਸ ਵਿੱਚ PHP ਵਿੱਚ ਕੋਈ ਮੈਮੋਰੀ ਲੀਕ ਨਹੀਂ ਹੈ। ਤੁਸੀਂ ਇੰਸਟਾਲ ਕਰ ਸਕਦੇ ਹੋ pm.max_requests = 0 ਸਥਿਰ ਦੇ ਨਾਲ ਜੇਕਰ ਤੁਸੀਂ ਮੌਜੂਦਾ ਅਤੇ ਭਵਿੱਖ ਦੀਆਂ PHP ਸਕ੍ਰਿਪਟਾਂ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਭਰੋਸਾ ਰੱਖਦੇ ਹੋ। ਪਰ ਸਮੇਂ ਦੇ ਨਾਲ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣਾ ਬਿਹਤਰ ਹੈ। ਬੇਨਤੀਆਂ ਦੀ ਇੱਕ ਵੱਡੀ ਗਿਣਤੀ ਸੈਟ ਕਰੋ, ਕਿਉਂਕਿ ਅਸੀਂ ਬੇਲੋੜੇ pm ਖਰਚਿਆਂ ਤੋਂ ਬਚਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਘੱਟੋ-ਘੱਟ pm.max_requests = 1000 - ਮਾਤਰਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ pm.max_children ਅਤੇ ਪ੍ਰਤੀ ਸਕਿੰਟ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ।

ਸਕਰੀਨਸ਼ਾਟ ਕਮਾਂਡ ਦਿਖਾਉਂਦਾ ਹੈ ਲੀਨਕਸ ਸਿਖਰ, u (ਉਪਭੋਗਤਾ) ਅਤੇ PHP-FPM ਉਪਭੋਗਤਾ ਨਾਮ ਦੁਆਰਾ ਫਿਲਟਰ ਕੀਤਾ ਗਿਆ। ਸਿਰਫ਼ ਪਹਿਲੀਆਂ 50 ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਿਖਾਈਆਂ ਗਈਆਂ ਹਨ (ਮੈਂ ਬਿਲਕੁਲ ਨਹੀਂ ਗਿਣਿਆ), ਪਰ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਸਿਖਰਲੇ ਅੰਕੜੇ ਦਿਖਾਉਂਦੇ ਹਨ ਜੋ ਟਰਮੀਨਲ ਵਿੰਡੋ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੇ ਹਨ। ਇਸ ਕੇਸ ਵਿੱਚ % CPU (% CPU) ਦੁਆਰਾ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ। ਸਾਰੀਆਂ 100 PHP-FPM ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਦੇਖਣ ਲਈ, ਕਮਾਂਡ ਚਲਾਓ:

top -bn1 | grep php-fpm

pm ਔਨਡਿਮਾਂਡ ਅਤੇ ਡਾਇਨਾਮਿਕ ਦੀ ਵਰਤੋਂ ਕਦੋਂ ਕਰਨੀ ਹੈ

ਜੇਕਰ ਤੁਸੀਂ ਪੀ.ਐਮ ਡਾਇਨਾਮਿਕ, ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ:

WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children

ਪੈਰਾਮੀਟਰ ਨੂੰ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਗਲਤੀ ਦੂਰ ਨਹੀਂ ਹੋਵੇਗੀ, ਜਿਵੇਂ ਸਰਵਰਫਾਲਟ 'ਤੇ ਇਸ ਪੋਸਟ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, pm.min ਮੁੱਲ ਬਹੁਤ ਛੋਟਾ ਸੀ, ਅਤੇ ਕਿਉਂਕਿ ਵੈੱਬ ਟ੍ਰੈਫਿਕ ਬਹੁਤ ਬਦਲਦਾ ਹੈ ਅਤੇ ਉੱਚੀਆਂ ਚੋਟੀਆਂ ਅਤੇ ਡੂੰਘੀਆਂ ਘਾਟੀਆਂ ਹਨ, ਇਸ ਲਈ pm ਨੂੰ ਢੁਕਵੇਂ ਰੂਪ ਵਿੱਚ ਅਨੁਕੂਲ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ। ਡਾਇਨਾਮਿਕ. ਆਮ ਤੌਰ 'ਤੇ pm ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਮੰਗ ਉੱਤੇ, ਜਿਵੇਂ ਕਿ ਉਸੇ ਪੋਸਟ ਵਿੱਚ ਸਲਾਹ ਦਿੱਤੀ ਗਈ ਹੈ. ਪਰ ਇਹ ਹੋਰ ਵੀ ਭੈੜਾ ਹੈ, ਕਿਉਂਕਿ ਮੰਗ ਉੱਤੇ ਥੋੜਾ ਜਾਂ ਕੋਈ ਟ੍ਰੈਫਿਕ ਨਾ ਹੋਣ 'ਤੇ ਨਿਸ਼ਕਿਰਿਆ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਜ਼ੀਰੋ 'ਤੇ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਅਜੇ ਵੀ ਟਰੈਫਿਕ ਬਦਲਣ ਦੇ ਓਵਰਹੈੱਡ ਦੇ ਨਾਲ ਖਤਮ ਹੋਵੋਗੇ। ਜਦੋਂ ਤੱਕ, ਬੇਸ਼ੱਕ, ਤੁਸੀਂ ਇੱਕ ਵਿਸ਼ਾਲ ਉਡੀਕ ਸਮਾਂ ਸੈਟ ਕਰਦੇ ਹੋ. ਅਤੇ ਫਿਰ ਇਸ ਨੂੰ ਵਰਤਣ ਲਈ ਬਿਹਤਰ ਹੈ pm.static + ਉੱਚ ਸੰਖਿਆ pm.max_requests.

PM ਡਾਇਨਾਮਿਕ ਅਤੇ ਖਾਸ ਕਰਕੇ ਮੰਗ ਉੱਤੇ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਕਈ PHP-FPM ਪੂਲ ਹਨ ਤਾਂ ਇਹ ਕੰਮ ਆ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਪੂਲ ਵਿੱਚ ਕਈ cPanel ਖਾਤਿਆਂ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਵੈੱਬਸਾਈਟਾਂ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਦੇ ਹੋ। ਮੇਰੇ ਕੋਲ 100+ cpanel ਖਾਤਿਆਂ ਅਤੇ ਲਗਭਗ 200 ਡੋਮੇਨਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸਰਵਰ ਹੈ, ਅਤੇ pm.static ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ ਡਾਇਨਾਮਿਕ ਮੈਨੂੰ ਨਹੀਂ ਬਚਾਏਗਾ। ਤੁਹਾਨੂੰ ਇੱਥੇ ਸਭ ਦੀ ਲੋੜ ਹੈ ਮੰਗ ਉੱਤੇ, ਆਖ਼ਰਕਾਰ, ਦੋ ਤਿਹਾਈ ਤੋਂ ਵੱਧ ਵੈਬਸਾਈਟਾਂ ਨੂੰ ਬਹੁਤ ਘੱਟ ਜਾਂ ਕੋਈ ਟ੍ਰੈਫਿਕ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਇਸਦੇ ਨਾਲ ਮੰਗ ਉੱਤੇ ਸਾਰੀਆਂ ਬਾਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਬੰਦ ਹੋ ਜਾਣਗੀਆਂ, ਜਿਸ ਨਾਲ ਸਾਡੀ ਬਹੁਤ ਸਾਰੀ ਯਾਦਦਾਸ਼ਤ ਬਚੇਗੀ! ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, cPanel ਡਿਵੈਲਪਰਾਂ ਨੇ ਇਸ ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਮੁੱਲ ਨੂੰ ਡਿਫੌਲਟ 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਮੰਗ ਉੱਤੇ. ਪਹਿਲਾਂ, ਜਦੋਂ ਡਿਫਾਲਟ ਸੀ ਡਾਇਨਾਮਿਕ, PHP-FPM ਵਿਅਸਤ ਸਾਂਝੇ ਸਰਵਰਾਂ ਲਈ ਬਿਲਕੁਲ ਵੀ ਢੁਕਵਾਂ ਨਹੀਂ ਸੀ। ਕਈਆਂ ਨੇ ਵਰਤਿਆ ਹੈ suPHP, ਕਿਉਂਕਿ pm ਡਾਇਨਾਮਿਕ ਵਿਹਲੇ ਪੂਲ ਅਤੇ cPanel PHP-FPM ਖਾਤਿਆਂ ਦੇ ਨਾਲ ਵੀ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਕੀਤੀ। ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਜੇਕਰ ਟ੍ਰੈਫਿਕ ਵਧੀਆ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ PHP-FPM ਪੂਲ (ਸਾਂਝੀ ਹੋਸਟਿੰਗ) ਵਾਲੇ ਸਰਵਰ 'ਤੇ ਹੋਸਟ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ।

ਸਿੱਟਾ

ਜੇ ਤੁਸੀਂ PHP-FPM ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਤੁਹਾਡਾ ਟ੍ਰੈਫਿਕ ਭਾਰੀ ਹੈ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਬੰਧਕ ਮੰਗ ਉੱਤੇ и ਡਾਇਨਾਮਿਕ PHP-FPM ਲਈ ਉਹਨਾਂ ਦੇ ਅੰਦਰੂਨੀ ਓਵਰਹੈੱਡ ਦੇ ਕਾਰਨ ਸੀਮਿਤ ਥ੍ਰੁਪੁੱਟ ਹੋਵੇਗਾ। ਆਪਣੇ ਸਿਸਟਮ ਨੂੰ ਸਮਝੋ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਸਰਵਰ ਸਮਰੱਥਾ ਦੇ ਅਨੁਸਾਰ PHP-FPM ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ। ਪਹਿਲਾ ਸੈੱਟ pm.max_children ਵੱਧ ਤੋਂ ਵੱਧ pm ਵਰਤੋਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਡਾਇਨਾਮਿਕ ਜ ਮੰਗ ਉੱਤੇ, ਅਤੇ ਫਿਰ ਇਸ ਮੁੱਲ ਨੂੰ ਇੱਕ ਪੱਧਰ ਤੱਕ ਵਧਾਓ ਜਿੱਥੇ ਮੈਮੋਰੀ ਅਤੇ ਪ੍ਰੋਸੈਸਰ ਓਵਰਲੋਡ ਕੀਤੇ ਬਿਨਾਂ ਕੰਮ ਕਰਨਗੇ। ਤੁਸੀਂ ਇਸਦੇ ਨਾਲ ਨੋਟਿਸ ਕਰੋਗੇ pm ਸਥਿਰ, ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਮੈਮੋਰੀ ਵਿੱਚ ਸਭ ਕੁਝ ਹੈ, ਟ੍ਰੈਫਿਕ ਸਪਾਈਕਸ ਸਮੇਂ ਦੇ ਨਾਲ ਘੱਟ CPU ਸਪਾਈਕ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ, ਅਤੇ ਸਰਵਰ ਅਤੇ CPU ਲੋਡ ਔਸਤ ਪੱਧਰ ਹੋ ਜਾਣਗੇ। ਔਸਤ PHP-FPM ਪ੍ਰਕਿਰਿਆ ਦਾ ਆਕਾਰ ਵੈੱਬ ਸਰਵਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਲਈ ਮੈਨੂਅਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਇਸਲਈ ਵਧੇਰੇ ਸਵੈਚਾਲਿਤ ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਬੰਧਕ ਹਨ ਡਾਇਨਾਮਿਕ и ਮੰਗ ਉੱਤੇ - ਵਧੇਰੇ ਪ੍ਰਸਿੱਧ. ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਲੇਖ ਲਾਭਦਾਇਕ ਸੀ.

ਯੂ.ਪੀ.ਡੀ ਬੈਂਚਮਾਰਕ ਚਾਰਟ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ab. ਜੇਕਰ PHP-FPM ਪ੍ਰਕਿਰਿਆਵਾਂ ਮੈਮੋਰੀ ਵਿੱਚ ਹਨ, ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਦੇ ਖਰਚੇ 'ਤੇ ਵਧਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਬੈਠਦੇ ਹਨ ਅਤੇ ਉਡੀਕ ਕਰਦੇ ਹਨ। ਆਪਣੇ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਲੱਭੋ.

ਸਰੋਤ: www.habr.com