ਆਪਣੇ WordPress ਸਾਈਟ ਦੇ ਐਡਮਿਨ ਪੈਨਲ (wp-admin) ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਸਰਵਰ ਸੈਟਿੰਗਜ਼

ਆਪਣੇ WordPress ਸਾਈਟ ਦੇ ਐਡਮਿਨ ਪੈਨਲ (wp-admin) ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ ਸਰਵਰ ਸੈਟਿੰਗਜ਼; ਸਹੀ PHP ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਨਾ, PHP-FPM ਸਰੋਤਾਂ ਵਧਾਉਣਾ, OPcache ਨੂੰ ਚਾਲੂ ਕਰਨਾ, ਡਾਟਾਬੇਸ ਨੂੰ ਆਯੋਜਿਤ ਕਰਨਾ, WordPress cron ਨੂੰ ਨਿਗਰਾਨੀ ਵਿੱਚ ਰੱਖਣਾ, admin-ajax ਦਾ ਬੋਝ ਘਟਾਉਣਾ ਅਤੇ ਸੁਰੱਖਿਆ ਪਰਤਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਢੰਗ ਨਾਲ ਸੰਰਚਨਾ ਕਰਨਾ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਕਿ ਦੌਰਾਨ ਸਾਰੀਆਂ ਸਫ਼ੇ cache ਨਾਲ ਤੇਜ਼ ਲੱਗਦੇ ਹਨ, ਪਰ ਐਡਮਿਨ ਪੈਨਲ ਅਕਸਰ ਗਤੀਸ਼ੀਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸੁਸਤਤਾ ਅਕਸਰ ਸਰਵਰ ਦੇ ਸਰੋਤਾਂ, ਡਾਟਾਬੇਸ ਦੇ ਪੁੱਛਗਿੱਛਾਂ, ਪਲੱਗਇਨ ਦੇ ਬੋਝ ਜਾਂ ਗਲਤ cron ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਕਾਰਨ ਹੁੰਦੀ ਹੈ।

ਇੱਕ WordPress ਸਾਈਟ 'ਤੇ फ्रੰਟ ਐਂਡ ਦੇ 1 ਸਕਿੰਟ ਵਿੱਚ ਖੁਲਣ ਦਾ ਇਹ ਮਤਲਬ ਨਹੀਂ ਕਿ wp-admin ਪੱਖ ਵੀ ਉਨ੍ਹਾਂ ਹੀ ਗਤੀ ਨਾਲ ਕੰਮ ਕਰੇਗਾ। ਕਿਉਂਕਿ ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ ਪੇਜ ਕੈਸ਼ ਅਕਸਰ ਬੰਦ ਹੁੰਦਾ ਹੈ; ਵਰਤੋਂਕਾਰ ਦੀ ਆਗਿਆ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਲੱਗਇਨ ਐਡਮਿਨ ਹੂਕ ਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹਨ, WooCommerce ਵਾਂਗੇ ਸਿਸਟਮ ਆਰਡਰ ਅਤੇ ਸਟਾਕ ਦੇ ਡੇਟਾ ਨੂੰ ਪੁੱਛਦੇ ਹਨ, ਸੁਰੱਖਿਆ ਪਲੱਗਇਨ ਹਰ ਬੇਨਤੀ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ। ਇਸ ਲਈ wp-admin ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਸੁਧਾਰਨ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਕੈਸ਼ ਪਲੱਗਇਨ ਇੰਸਟਾਲ ਕਰਨਾ ਅਕਸਰ ਯੋਗ ਨਹੀਂ ਹੁੰਦਾ। ਅਸਲ ਫਰਕ, ਹੋਸਟਿੰਗ ਢਾਂਚੇ ਵਿੱਚ ਕੀਤੇ ਗਏ ਸਹੀ ਸੈਟਿੰਗਜ਼ ਤੋਂ ਆਉਂਦਾ ਹੈ।

ਇਸ ਮਾਰਗਦਰਸ਼ਕ ਵਿੱਚ, ਅਸੀਂ WordPress ਐਡਮਿਨ ਪੈਨਲ ਦੀ ਸੁਸਤਤਾ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਲਈ ਸਰਵਰ ਪੱਖ 'ਤੇ ਲਾਗੂ ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਕਦਮਾਂ ਨੂੰ ਤਕਨੀਕੀ ਪਰੰਤੂ ਸਮਝਣਯੋਗ ਢੰਗ ਨਾਲ ਸਮਝਾਅ ਦੇਵਾਂਗੇ। ਖਾਸ ਕਰਕੇ ਸਾਂਝੇ ਹੋਸਟਿੰਗ, WordPress ਹੋਸਟਿੰਗ, VPS ਜਾਂ ਕਲਾਉਡ ਸਰਵਰ ਵਰਤਣ ਵਾਲੇ ਸਾਈਟ ਦੇ ਮਾਲਕਾਂ ਲਈ ਮਾਪਣ ਯੋਗ ਅਤੇ ਲਾਗੂ ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਸੁਝਾਵਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਾਂਗੇ। ਜੇਕਰ ਮੌਜੂਦਾ ਪੈਕੇਜ ਦੇ ਸਰੋਤ ਸਦਾ ਸੀਮਾ 'ਤੇ ਹਨ, ਤਾਂ ਆਯੋਜਨ ਦੇ ਨਾਲ-ਨਾਲ ਸਹੀ ਢਾਂਚਾ ਚੋਣ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ; ਇਸ ਬਿੰਦੂ 'ਤੇ WordPress ਹੋਸਟਿੰਗ ਪੈਕੇਜ ਜਾਂ ਜ਼ਿਆਦਾ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ VPS ਸਰਵਰ ਹੱਲ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

wp-admin ਫ੍ਰੰਟ ਐਂਡ ਨਾਲੋਂ ਕਿਉਂ ਧੀਮਾ ਕੰਮ ਕਰਦਾ ਹੈ?

WordPress ਐਡਮਿਨ ਪੈਨਲ, ਜਿਹੜੇ ਸਫ਼ੇ ਦਰਸ਼ਕਾਂ ਨੂੰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਤੋਂ ਵੱਖਰੀ ਲਾਜ਼ਿਕ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਫ੍ਰੰਟ ਐਂਡ 'ਤੇ ਬਲੌਗ ਲੇਖ, ਸ਼੍ਰੇਣੀ ਦੇ ਸਫ਼ੇ ਜਾਂ ਕਾਰਪੋਰੇਟ ਸਫ਼ੇ ਪੂਰੀ ਸਫ਼ੇ ਦੀ ਕੈਸ਼ ਨਾਲ ਸਟੈਟਿਕ HTML ਵਾਂਗ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਪਰ wp-admin ਖੇਤਰ ਵਿੱਚ ਪ੍ਰਤੀ ਵਰਤੋਂਕਾਰ ਦੀ ਆਗਿਆ, ਸੂਚਨਾਵਾਂ, ਪਲੱਗਇਨ ਸਕਰੀਨਾਂ, ਅੱਪਡੇਟ ਚੈਕ ਅਤੇ ਡਾਟਾਬੇਸ ਦੀ ਕਾਰਵਾਈ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ ਪਰੰਪਰਾਗਤ ਪੇਜ ਕੈਸ਼ਿੰਗ, ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ ਸੀਮਿਤ ਲਾਭ ਦਿੰਦੀ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, WooCommerce ਵਰਤਣ ਵਾਲੀ ਇੱਕ ਦੁਕਾਨ ਵਿੱਚ ਜਦੋਂ ਆਰਡਰਾਂ ਦੀ ਸਕਰੀਨ ਖੁਲਦੀ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਇੱਕ HTML ਪੇਜ ਹੀ ਨਾ ਦਿਖਾਈ ਦੇਂਦਾ ਹੈ। ਸਿਸਟਮ ਆਰਡਰ ਦੀ ਸਥਿਤੀ, ਭੁਗਤਾਨ ਰਿਕਾਰਡ, ਗਾਹਕ ਮੈਟਾ ਡੇਟਾ, ਸਟਾਕ ਚਲਾਅ, ਕੂਪਨ ਅਤੇ ਪਲੱਗਇਨ ਦੁਆਰਾ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਵਿਸ਼ੇਸ਼ ਖੇਤਰਾਂ ਨੂੰ ਪੁੱਛ ਸਕਦਾ ਹੈ। ਇੱਕ ਵੱਡੇ ਡਾਟਾਬੇਸ ਵਿੱਚ ਇਹ ਕਾਰਵਾਈ ਕੁੱਝ ਸੌ ਮਿੱਲੀਸੇਕੰਡਾਂ ਤੋਂ ਕੁਝ ਸਕਿੰਟਾਂ ਤੱਕ ਚੱਲ ਸਕਦੀ ਹੈ। ਜੇ PHP ਮੈਮੋਰੀ ਸੀਮਾ ਕਮਜ਼ੋਰ, MySQL ਪੁੱਛਗਿੱਛਾਂ ਧੀਮੀ ਜਾਂ CPU ਦੀ ਭਾਰੀ ਵਰਤੋਂ ਹੈ, ਤਾਂ ਪੈਨਲ 'ਤੇ ਮੈਨੂਆਂ 'ਤੇ ਕਲਿਕ ਕਰਨ ਤੇ ਵੀ ਦੇਰ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ।

ਧੀਮੇ wp-admin ਲਈ ਆਮ ਲੱਛਣ

• ਲੌਗਇਨ ਕਰਨ ਦੇ ਬਾਅਦ ਪੈਨਲ ਸਕਰੀਨ ਦਾ 5 ਸਕਿੰਟ ਤੋਂ ਜ਼ਿਆਦਾ ਖੁਲਣਾ।
• ਲਿਖਤ ਸੰਜੋਣ ਸਕਰੀਨ 'ਤੇ ਸੇਵ ਜਾਂ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਕਾਰਵਾਈ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਨਾ।
• WooCommerce ਆਰਡਰਾਂ ਦੇ ਸਫ਼ੇ 'ਤੇ ਫਿਲਟਰਿੰਗ ਕਰਦੇ ਸਮੇਂ ਟਾਈਮ ਆਉਟ ਹੋਣਾ।
• ਪਲੱਗਇਨ ਦੇ ਸਫ਼ੇ 'ਤੇ ਅੱਪਡੇਟ ਚੈੱਕ ਦਾ ਬਹੁਤ ਲੰਬਾ ਹੋਣਾ।
• admin-ajax.php ਬੇਨਤੀਆਂ ਦੀ ਨਿਰੰਤਰ ਉੱਚ CPU ਵਰਤੋਂ।
• ਸਰਵਰ ਦੀ ਗਲਤ ਰਿਕਾਰਡਾਂ ਵਿੱਚ 500, 502, 503 ਜਾਂ 504 ਦੀਆਂ ਗਲਤੀਆਂ ਦਿਖਾਈ ਦੇਣਾ।

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

ਪਹਿਲਾਂ ਮਾਪੋ: wp-admin ਦੇ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਕਿਵੇਂ ਪਤਾ ਲਗਾਉਣਾ ਹੈ?

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

ਤੁਸੀਂ ਚੈਕ ਕਰਨ ਵਾਲੇ ਮੁੱਖ ਮੈਟਰਿਕਸ

• TTFB: ਜੇ ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ ਪਹਿਲਾ ਬਾਈਟ ਸਮਾਂ 800 ms ਤੋਂ ਉਪਰ ਹੈ, ਤਾਂ ਸਰਵਰ ਪੱਖ 'ਤੇ ਦੇਰ ਹੋ ਸਕਦੀ ਹੈ।
• PHP ਕਾਰਵਾਈ ਸਮਾਂ: ਇਕੱਲਾ wp-admin ਬੇਨਤੀ 2-3 ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਹੈ, ਤਾਂ ਪਲੱਗਇਨ, ਥੀਮ ਜਾਂ ਡਾਟਾਬੇਸ ਪੁੱਛਗਿੱਛ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਵੇ।
• CPU ਵਰਤੋਂ: ਨਿਰੰਤਰ 80% ਅਤੇ ਉੱਪਰ ਦੀ ਵਰਤੋਂ, ਸਰੋਤਾਂ ਦੀ ਘਾਟ ਜਾਂ ਭਾਰੀ ਬੋਟ ਟਰੈਫਿਕ ਦਿਖਾ ਸਕਦੀ ਹੈ।
• RAM ਵਰਤੋਂ: ਜਦੋਂ ਯਾਦاشت ਭਰ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸਵਾਪ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਪੈਨਲ ਗੰਭੀਰਤਾ ਨਾਲ ਧੀਮਾ ਹੋ ਜਾਂਦਾ ਹੈ।
• MySQL ਧੀਮੀ ਪੁੱਛਗਿੱਛਾਂ: ਖਾਸ ਤੌਰ 'ਤੇ wp_postmeta ਅਤੇ wp_options ਟੇਬਲਾਂ ਵਿੱਚ ਦੇਰ ਅਕਸਰ ਹੁੰਦੀ ਹੈ।
• Disk I/O: ਧੀਮਾ ਡਿਸਕ ਜਾਂ ਭਾਰੀ ਬੈਕਅਪ ਕਾਰਵਾਈਆਂ ਐਡਮਿਨ ਪੈਨਲ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ।

Hostragons ਨਿਗਰਾਨੀ ਪੈਨਲ ਜਾਂ ਤੁਸੀਂ ਵਰਤ ਰਹੇ ਸਰਵਰ ਪੈਨਲ 'ਤੇ CPU, RAM, I/O ਅਤੇ ਦੌਰਾਬਾਰੀ ਅੰਕੜਿਆਂ ਨੂੰ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਚੈਕ ਕਰਨਾ ਚੰਗੀ ਸ਼ੁਰੂਆਤ ਹੈ। ਹੋਰ ਵਿਸਥਾਰਤ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਗਲਤੀ ਰਿਕਾਰਡ, PHP ਸੁਸਤ ਲੌਗ, MySQL ਸੁਸਤ ਪੁੱਛਗਿੱਛ ਲੌਗ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨਿਗਰਾਨੀ ਦੇ ਟੂਲ ਵਰਤੀ ਜਾ ਸਕਦੇ ਹਨ। ਜੇਕਰ ਸਾਈਟ ਵੱਡੀ ਹੋ ਗਈ ਹੈ ਅਤੇ ਇਹ ਮੈਟਰਿਕਸ ਨੂੰ ਇਕੱਠਾ ਸੰਭਾਲਣਾ ਮੁਸ਼ਕਲ ਹੋ ਰਿਹਾ ਹੈ, ਤਾਂ ਸੰਭਾਲੇ ਹੋਏ ਹੋਸਟਿੰਗ ਸੇਵਾਵਾਂ ਨੂੰ ਪਸੰਦ ਕਰਨਾ ਕਾਰਵਾਈ ਦੇ ਬੋਝ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ।

ਸਰਵਰ ਸੈਟਿੰਗਜ਼: ਸਾਰਾਂਕਸ਼ਿਤ ਤੁਲਨਾ ਟੇਬਲ

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

PHP ਸੰਸਕਰਣ ਅਤੇ PHP-FPM ਸੈਟਿੰਗਜ਼ ਨੂੰ ਸੁਧਾਰੋ

WordPress ਕੋਰ, ਆਧੁਨਿਕ PHP ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਹੋਰ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਪੁਰਾਣੇ PHP ਸੰਸਕਰਣ ਸਿਰਫ਼ ਸੁਰੱਖਿਆ ਦੇ ਖਤਰੇ ਪੈਦਾ ਨਹੀਂ ਕਰਦੇ; ਸਗੋਂ ਇਹ ਧੀਮੇ ਵੀ ਹੋ ਸਕਦੇ ਹਨ। 2026 ਤੱਕ WordPress ਸਾਈਟਾਂ 'ਤੇ ਸਮਰਥਿਤ, ਸੁਰੱਖਿਆ ਅੱਪਡੇਟ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਅਤੇ ਤੁਹਾਡੇ ਪਲੱਗਇਨਾਂ ਨਾਲ ਅਨੁਕੂਲ ਸਭ ਤੋਂ ਨਵਾਂ ਸਥਿਰ PHP ਸੰਸਕਰਣ ਵਰਤਣਾ ਕਾਰਗੁਜ਼ਾਰੀ ਲਈ ਮੂਲ ਸ਼ਰਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।

ਇੱਕ ਉਦਾਹਰਣ ਸੋਚੋ: ਇੱਕ ਹੀ ਸਾਈਟ 'ਤੇ ਪੁਰਾਣੇ PHP ਸੰਸਕਰਣ ਤੋਂ ਨਵੇਂ ਸੰਸਕਰਣ 'ਤੇ ਜਾਣ 'ਤੇ ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ 10% ਤੋਂ 30% ਦੇ ਵਿਚਕਾਰ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਮਿਲਣਾ ਆਮ ਨਤੀਜਾ ਹੈ। ਇਹ ਅਨੁਪਾਤ ਸਾਈਟ ਦੇ ਪਲੱਗਇਨ ਬਣਤਰ ਦੇ ਅਨੁਸਾਰ ਬਦਲਦਾ ਹੈ। ਖਾਸ ਕਰਕੇ ਭਾਰੀ ਪੇਜ ਬਣਾਉਣ ਵਾਲੇ, WooCommerce, LMS ਅਤੇ ਮੈਂਬਰਸ਼ਿਪ ਪਲੱਗਇਨਾਂ ਨੂੰ PHP ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਤੋਂ ਸਿੱਧਾ ਪ੍ਰਭਾਵ ਹੁੰਦਾ ਹੈ।

PHP memory_limit ਕਿੰਨਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?

ਸਧਾਰਨ ਇੱਕ ਕਾਰਪੋਰੇਟ WordPress ਸਾਈਟ ਲਈ 256 MB ਅਕਸਰ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। WooCommerce, ਬਹੁਭਾਸ਼ੀ ਢਾਂਚਾ, ਰੀਜ਼ਰਵੇਸ਼ਨ ਸਿਸਟਮ, ਉਨਤ ਫਾਰਮ ਪਲੱਗਇਨਾਂ ਜਾਂ ਪੇਜ ਬਣਾ ਰਿਹਾ ਹੈ, ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਸਾਈਟਾਂ ਲਈ 512 MB ਇੱਕ ਵਧੀਆ ਸ਼ੁਰੂਆਤ ਹੈ। ਬਹੁਤ ਵੱਡੀਆਂ ਦੁਕਾਨਾਂ ਜਾਂ ਭਾਰੀ ਆਯੋਜਨ ਕਾਰਵਾਈਆਂ ਵਿੱਚ 768 MB ਜਾਂ 1024 MB ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਪਰ ਯਾਦਾਸ਼ਤ ਦੀ ਸੀਮਾ ਨੂੰ ਅਨੰਤ ਵਧਾਉਣਾ ਹੱਲ ਨਹੀਂ ਹੈ; ਜੇਕਰ ਕੋਈ ਪਲੱਗਇਨ ਯਾਦਾਸ਼ਤ ਲੀਕ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਉੱਚ ਸੀਮਾ ਸਿਰਫ਼ ਸਮੱਸਿਆ ਨੂੰ ਦੇਰ ਕਰ ਦੇਵੇਗੀ।

max_execution_time ਅਤੇ input Varsayımları

wp-admin ਪੱਖ 'ਤੇ ਉਤਪਾਦ ਆਯਾਤ, ਬਲਕ ਅੱਪਡੇਟ, ਵੱਡੀਆਂ ਵਿਜ਼ੂਅਲ ਪ੍ਰਕਿਰਿਆ ਜਾਂ ਬੈਕਅੱਪ ਨੂੰ ਦੁਬਾਰਾ ਲਾਉਣ ਜਿਹੀਆਂ ਕਾਰਵਾਈਆਂ ਟਾਈਮ ਆਉਟ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਲਈ max_execution_time ਲਈ 120-300 ਸਕਿੰਟ ਦੀ ਰੇਂਜ, post_max_size ਅਤੇ upload_max_filesize ਲਈ ਸਾਈਟ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਅਨੁਸਾਰ ਮੁੱਲ ਚੁਣੇ ਜਾ ਸਕਦੇ ਹਨ। ਪਰ ਇਹ ਸੈਟਿੰਗਜ਼ ਦਿਨਚਰਿਆ ਪੈਨਲ ਦੀ ਵਰਤੋਂ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਤੋਂ ਬਹੁਤ, ਭਾਰੀ ਕਾਰਵਾਈਆਂ ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਦੇ ਹਨ।

PHP-FPM ਵਰਕਰ ਸੈਟਿੰਗਜ਼

PHP-FPM, PHP ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵਾਲੀ ਪਰਤ ਹੈ। ਜੇ ਵਰਕਰਾਂ ਦੀ ਸੰਖਿਆ ਬਹੁਤ ਘੱਟ ਹੈ, ਤਾਂ ਜਦੋਂ ਇੱਕ ਸਮੇਂ 'ਤੇ ਕੁਝ ਐਡਮਿਨ ਵਰਤੋਂਕਾਰ ਕਾਰਵਾਈ ਕਰਦੇ ਹਨ, ਤਾਂ ਕਤਾਰ ਬਣ ਜਾਂਦੀ ਹੈ। ਜੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ, ਤਾਂ RAM ਤੇਜ਼ੀ ਨਾਲ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਸੰਤੁਲਿਤ ਸੈਟਿੰਗ ਲਈ ਸਰਵਰ 'ਤੇ ਕੁੱਲ RAM, ਔਸਤ PHP ਕਾਰਵਾਈ ਦੇ ਸਮੇਂ ਦੀ ਯਾਦਾਸ਼ਤ ਦੀ ਵਰਤੋਂ ਅਤੇ ਸਮਕਾਲੀ ਵਰਤੋਂਕਾਰਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ, ਜੇ ਔਸਤ PHP ਕਾਰਵਾਈ 80 MB ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਅਤੇ PHP ਲਈ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ 2 GB RAM ਵਹਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ 20-25 ਵਰਕਰਾਂ ਦਾ ਉੱਪਰੀ ਸੀਮਾ ਵਜੋਂ ਸੋਚਿਆ ਜਾ ਸਕਦਾ ਹੈ; ਪਰ ਡਾਟਾਬੇਸ, ਵੈੱਬ ਸਰਵਰ ਅਤੇ ਸਿਸਟਮ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਵੀ ਹਿੱਸਾ ਛੱਡਣਾ ਚਾਹੀਦਾ ਹੈ।

OPcache ਨਾਲ PHP ਦੀ ਸੰਕਲਨ ਦੀ ਭਾਰ ਨੂੰ ਘਟਾਓ

OPcache, PHP ਫਾਇਲਾਂ ਦੇ ਸੰਕਲਿਤ ਅਵਸਥਾ ਨੂੰ ਯਾਦਾਸ਼ਤ ਵਿੱਚ ਸੰਭਾਲਦਾ ਹੈ। WordPress ਵਰਗੇ ਸੈਂਕੜੇ PHP ਫਾਇਲਾਂ ਨੂੰ ਚਲਾਉਣ ਵਾਲੇ ਸਿਸਟਮਾਂ ਵਿੱਚ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਆਤਮਕ ਮਹੱਤਵ ਦੀ ਹੈ। ਜੇ OPcache ਬੰਦ ਹੈ, ਤਾਂ ਹਰ ਬੇਨਤੀ 'ਤੇ PHP ਫਾਇਲਾਂ ਨੂੰ ਦੁਬਾਰਾ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸੰਕਲਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਸਥਿਤੀ ਖਾਸ ਤੌਰ 'ਤੇ wp-admin ਖੇਤਰ ਵਿੱਚ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ; ਕਿਉਂਕਿ ਪੈਨਲ ਸਕਰੀਨ ਬਹੁਤ ਸਾਰੇ ਕੋਰ ਅਤੇ ਪਲੱਗਇਨ ਫਾਇਲਾਂ ਨੂੰ ਲੋਡ ਕਰਦੇ ਹਨ।

ਜਦੋਂ OPcache ਸਰਗਰਮ ਹੁੰਦਾ ਹੈ, ਤਾਂ CPU ਦਾ ਬੋਝ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਜਵਾਬ ਦੇ ਸਮੇਂ ਹੋਰ ਸਥਿਰ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉੱਚ ਟਰੈਫਿਕ 'ਤੇ ਸਰਵਰ ਹੋਰ ਆਸਾਨੀ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। WordPress ਹੋਸਟਿੰਗ ਵਾਤਾਵਰਨ ਵਿੱਚ OPcache ਦੀ ਸਰਗਰਮੀ ਹੁਣ ਮੂਲ ਕਾਰਗੁਜ਼ਾਰੀ ਮਿਆਰ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੇ ਹੋਸਟਿੰਗ ਪੈਨਲ ਵਿੱਚ ਇਹ ਵਿਕਲਪ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦਾ, ਤਾਂ ਸਹਾਇਤਾ ਟੀਮ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰਨਾ ਲਾਭਦਾਇਕ ਹੈ। Hostragons ਪਾਸੇ ਕਾਰਗੁਜ਼ਾਰੀ-ਕੇਂਦਰਤ ਪੈਕੇਜਾਂ ਨੂੰ ਜਾਂਚਦੇ ਸਮੇਂ ਉੱਚ ਪਰਫਾਰਮੈਂਸ ਵਾਲਾ ਵੈੱਬ ਹੋਸਟਿੰਗ ਪੇਜ਼ 'ਤੇ ਨਜ਼ਰ ਮਾਰ ਸਕਦੇ ਹੋ।

OPcache ਲਈ ਪ੍ਰਾਇਕਟਿਕ ਚੈਕਲਿਸਟ

• OPcache ਸਰਗਰਮ ਹੈ?
• ਵਿਭਾਜਿਤ ਯਾਦਾਸ਼ਤ, ਪਲੱਗਇਨ ਦੀ ਸੰਖਿਆ ਦੇ ਅਨੁਸਾਰ ਯੋਗ ਹੈ?
• ਬਹੁਤ ਜ਼ਿਆਦਾ ਫਾਇਲਾਂ ਦੇ ਬਦਲਾਅ ਵਾਲੇ ਵਿਕਾਸ ਵਾਤਾਵਰਨ ਅਤੇ ਜ਼ਿੰਦਾ ਵਾਤਾਵਰਨ ਵੱਖਰੇ ਹਨ?
• Deploy ਤੋਂ ਬਾਅਦ ਕੈਸ਼ ਸਾਫ਼ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ?

ਜ਼ਿੰਦਾ ਸਾਈਟ 'ਤੇ OPcache ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਕਾਰਗੁਜ਼ਾਰੀ ਲਈ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਕਦਮ ਹੈ। ਪਰ ਵਿਕਾਸ ਕਰਦੇ ਸਮੇਂ ਪਦਲਾਵਾਂ ਦੇ ਦੇਰ ਨਾਲ ਦਿਖਾਈ ਦੇਣ ਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਪੈਦਾ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਲਈ ਉਤਪਾਦਨ ਅਤੇ ਚੇਤਨਾ ਵਾਤਾਵਰਨ ਨੂੰ ਵੱਖਰੇ ਕਰਨਾ, ਖਾਸ ਕਰਕੇ ਏਜੰਸੀਆਂ ਅਤੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਹੋਰ ਪੇਸ਼ੇਵਰ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਹੈ।

ਡਾਟਾਬੇਸ ਸੈਟਿੰਗਜ਼: wp-admin ਦੀ ਗਤੀ ਦਾ ਗੁਪਤ ਨਿਰਧਾਰਕ

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

wp_options ਟੇਬਲ ਨੂੰ ਚੈਕ ਕਰੋ

wp_options ਟੇਬਲ ਵਿੱਚ autoload ਮੁੱਲ ਦੇ ਨਾਲ ਰਿਕਾਰਡ, WordPress ਹਰ ਬੇਨਤੀ 'ਤੇ ਖੁਲਦੇ ਸਮੇਂ ਲੋਡ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਇਹ ਟੇਬਲ ਫੂਲ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਫ੍ਰੰਟ ਐਂਡ ਨਹੀਂ, ਸਗੋਂ wp-admin ਵੀ ਸੁਸਤ ਹੁੰਦਾ ਹੈ। Autoload ਕੁੱਲ ਆਕਾਰ ਦੇ ਕੁਝ MB ਤੋਂ ਵੱਧ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੁਰਾਣੇ ਪਲੱਗਇਨਾਂ ਤੋਂ ਬਚੇ ਹੋਏ ਵੱਡੇ ਸੈਟਿੰਗਾਂ, ਕੈਸ਼ ਦੇ ਅਵਸ਼ੇਸ਼ ਜਾਂ ਗੈਰ-ਜਰੂਰੀ ਅਸਥਾਈ ਰਿਕਾਰਡਾਂ ਨੂੰ ਸਾਫ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਕਾਰਵਾਈ ਸਾਵਧਾਨੀ ਦੀ ਲੋੜ ਹੈ; ਸਿਧਾ ਸਾਈਟ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਬੈਕਅਪ ਲਿਆ ਗਿਆ ਹੈ। ਬੈਕਅਪ ਰਣਨੀਤੀਆਂ ਲਈ WordPress ਬੈਕਅਪ ਗਾਈਡ ਲਿੰਕ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

postmeta ਅਤੇ WooCommerce ਪੁੱਛਗਿੱਛ

WooCommerce ਸਾਈਟਾਂ 'ਤੇ wp_postmeta ਟੇਬਲ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧਦੀ ਹੈ। ਹਰ ਉਤਪਾਦ, ਵੈਰੀਏਸ਼ਨ, ਆਰਡਰ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਖੇਤਰ ਇਥੇ ਬਹੁਤ ਸਾਰੇ ਰਿਕਾਰਡ ਬਣਾਉਂਦੇ ਹਨ। 50,000 ਉਤਪਾਦਾਂ ਜਾਂ 100,000 ਆਰਡਰਾਂ ਵਾਲੀ ਦੁਕਾਨ ਵਿੱਚ ਐਡਮਿਨ ਸਕਰੀਨਾਂ ਦੀ ਸੁਸਤਤਾ ਨਹੀਂ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਸਿਰਫ਼ PHP ਸੈਟਿੰਗ ਕਰਨਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦਾ; ਡਾਟਾਬੇਸ ਦੇ ਇੰਡੈਕਸ, ਆਰਕੀਵਿੰਗ ਰਣਨੀਤੀ ਅਤੇ ਪੁੱਛਗਿੱਛ ਦੇ ਆਯੋਜਨ ਦੀ ਲੋੜ ਹੈ।

MySQL ਸੁਸਤ ਪੁੱਛਗਿੱਛ ਲੌਗ ਦੀ ਵਰਤੋਂ ਕਰੋ

ਧੀਮੀ ਪੁੱਛਗਿੱਛ ਲੌਗ, ਨਿਰਧਾਰਿਤ ਸਮੇਂ ਤੋਂ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲ ਰਹੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ, 1 ਸਕਿੰਟ ਤੋਂ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲ ਰਹੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ, ਇਹ ਪਤਾ ਲਗਾ ਸਕਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪਲੱਗਇਨ ਜਾਂ ਸਕਰੀਨ ਡਾਟਾਬੇਸ ਨੂੰ ਮੁਸ਼ਕਲ ਵਿੱਚ ਰੱਖ ਰਿਹਾ ਹੈ। ਇੱਕ ਆਮ ਸਮੱਸਿਆ ਵਿੱਚ, ਪਲੱਗਇਨਾਂ ਨੇ ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ ਹਰ ਦਾਖਲੇ 'ਤੇ ਬਾਹਰੀ API ਦੀ ਜਾਂਚ ਕਰਨ ਜਾਂ ਵੱਡੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਇੰਡੈਕਸ ਵਿਹਿਨ ਪੁੱਛਣ ਦੀ ਆਦਤ ਬਣਾਈ ਹੈ। ਇਹ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ ਪਲੱਗਇਨ ਸੈਟਿੰਗ ਨੂੰ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਵਿਕਲਪੀ ਪਲੱਗਇਨ ਦੀ ਚੋਣ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜਾਂ ਵਿਕਾਸਕਾਰ ਦੀ ਹਸਤਕਸ਼ੇਪ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

Redis ਜਾਂ Memcached ਨਾਲ Object Cache ਦੀ ਵਰਤੋਂ ਕਰੋ

WordPress ਕੁਝ ਡੇਟਾ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਕਰਦਾ ਹੈ; ਪਰ ਡਿਫਾਲਟ object cache ਦੀ ਬੇਨਤੀ ਦੀ ਸਮੇਂ ਦੀ ਸੀਮਾ ਵਿੱਚ ਸੀਮਿਤ ਹੁੰਦੀ ਹੈ। Redis ਜਾਂ Memcached ਵਰਗੇ ਸਥਾਈ object cache ਹੱਲ, ਦੁਹਰਾਈ ਡਾਟਾਬੇਸ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ। ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ wp-admin ਪੱਖ 'ਤੇ; ਵਰਤੋਂਕਾਰ ਦੀਆਂ ਆਗਿਆਵਾਂ, ਵਿਕਲਪ, ਮੀਨੂਆਂ, ਉਤਪਾਦ ਦੇ ਡੇਟਾ ਅਤੇ ਜਟਿਲ ਪੁੱਛਗਿੱਛਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੈ।

Redis ਦੀ ਵਰਤੋਂ, ਭਾਰੀ ਪਲੱਗਇਨ ਵਾਲੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਐਡਮਿਨ ਪੈਨਲ ਦੇ ਹੋਰ ਸਥਿਰ ਕੰਮ ਕਰਨ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ। ਪਰ ਗਲਤ ਸੰਗਠਿਤ object cache ਸਮੱਸਿਆ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ, ਇੱਕੋ Redis ਡਾਟਾਬੇਸ ਨੂੰ ਬਿਨਾਂ ਪ੍ਰੀਫਿਕਸ ਦੇ ਵਰਤਣ ਵਾਲੇ ਕਈ WordPress ਸਾਈਟਾਂ ਡੇਟਾ ਦੇ ਮਿਸ਼ਰਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਲਈ ਹਰ ਸਾਈਟ ਲਈ ਵਿਲੱਖਣ ਪ੍ਰੀਫਿਕਸ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਯਾਦਾਸ਼ਤ ਦੀ ਸੀਮਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਕੈਸ਼ ਸਾਫ਼ ਕਰਨ ਦੀ ਮਕੈਨਿਜ਼ਮ ਜਾਣੀ ਜਾ ਸਕਦੀ ਹੈ।

Object Cache ਕਦੋਂ ਲੋੜੀਂਦੀ ਹੈ?

• ਜੇਕਰ ਤੁਸੀਂ WooCommerce ਜਾਂ ਮੈਂਬਰਸ਼ਿਪ ਸਾਈਟ ਚਲਾਉਂਦੇ ਹੋ।
• ਜੇਕਰ ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ ਸੂਚੀਬੱਧ ਅਤੇ ਫਿਲਟਰਿੰਗ ਸਕਰੀਨ ਧੀਮਾ ਹੈ।
• ਜੇਕਰ ਡਾਟਾਬੇਸ CPU ਦੀ ਵਰਤੋਂ ਉੱਚ ਹੈ।
• ਜੇਕਰ ਬਹੁਤ ਸਾਰੇ ਸਮਕਾਲੀ ਵਰਤੋਂਕਾਰ ਜਾਂ ਸੰਪਾਦਕ ਹਨ।
• ਜੇਕਰ wp_options ਅਤੇ postmeta ਟੇਬਲਾਂ ਵਧ ਗਈਆਂ ਹਨ।

ਛੋਟੇ ਬਲੌਗ ਵਿੱਚ Redis ਨਾਟਕਿਕ ਫਰਕ ਨਹੀਂ ਪੈਦਾ ਕਰ ਸਕਦਾ। ਪਰ ਮੱਧ ਅਤੇ ਵੱਡੇ ਪੈਮਾਨੇ ਦੇ WordPress ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ, ਸਹੀ ਸੰਗਠਿਤ object cache ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਦੇ ਅਨੁਭਵ ਨੂੰ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਸੁਧਾਰਦਾ ਹੈ।

WP-Cron ਨੂੰ ਅਸਲ Cron ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕਰੋ

WordPress ਦਾ ਡਿਫਾਲਟ cron ਸਿਸਟਮ, ਸਾਈਟ 'ਤੇ ਦੌਰਾਨ ਆਉਣ ਵੇਲੇ ਟ੍ਰIGGER ਹੁੰਦਾ ਹੈ। ਇਹ ਢਾਂਚਾ ਛੋਟੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਵਰਤਣੀਯੋਗ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਭਾਰੀ ਜਾਂ ਜਟਿਲ ਸਾਈਟਾਂ 'ਤੇ ਬੇਤਰਤੀਬੀ ਬੋਝ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ ਦਾਖਲ ਹੋਣ 'ਤੇ ਉਡੀਕ ਰਹੇ cron ਕਾਰਜ ਚਲਦੇ ਹਨ, ਤਾਂ wp-admin ਅਸਮਾਨ ਤੌਰ 'ਤੇ ਸੁਸਤ ਹੋ ਸਕਦਾ ਹੈ। ਈ-ਮੇਲ ਭੇਜਣ, ਸਟਾਕ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ, ਬੈਕਅੱਪ, ਸੁਰੱਖਿਆ ਸਕੈਨਿੰਗ ਅਤੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਕਾਰਵਾਈਆਂ cron ਕਤਾਰ ਨੂੰ ਵੱਧਾਉਂਦੇ ਹਨ।

ਜ਼ਿਆਦਾ ਸਿਹਤਮੰਦ ਹੱਲ, WordPress ਦੇ ਡਿਫਾਲਟ ਦੌਰਾਂ ਵਿਜ਼ੀਟਰ ਟ੍ਰIGGER ਕੀਤੇ ਗਏ cron ਵਿਵਹਾਰ ਨੂੰ ਬੰਦ ਕਰਨਾ ਅਤੇ ਸਰਵਰ ਦੁਆਰਾ ਅਸਲ cron ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ 5, 10 ਜਾਂ 15 ਮਿੰਟਾਂ ਦੇ ਅੰਤਰਕਾਲ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ। ਬਹੁਤ ਭਾਰੀ ਦੁਕਾਨਾਂ ਵਿੱਚ ਕਾਰਜਾਂ ਦੀ ਕਿਸਮ ਦੇ ਅਨੁਸਾਰ ਵੱਖਰੇ cron ਢਾਂਚੇ ਚੁਣੇ ਜਾ ਸਕਦੇ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ cron ਕਾਰਵਾਈਆਂ ਐਡਮਿਨ ਪੈਨਲ 'ਤੇ ਬੇਤਰਤੀਬੀ ਬੋਝ ਨਹੀਂ ਪਾਉਂਦੀਆਂ।

Cron ਆਯੋਜਨ ਵਿੱਚ ਧਿਆਨ ਰੱਖਣ ਵਾਲੀਆਂ ਗੱਲਾਂ

• ਬੈਕਅੱਪ ਅਤੇ ਸੁਰੱਖਿਆ ਸਕੈਨਿੰਗ ਨੂੰ ਵੱਧ ਕੇ ਘੱਟ ਮਿੰਟਾਂ 'ਤੇ ਕਰੋ।
• ਹਰ ਮਿੰਟ ਚਲਾਉਣ ਵਾਲੀਆਂ ਗੈਰ-ਜਰੂਰੀ ਕਾਰਵਾਈਆਂ ਦੀ ਪਛਾਣ ਕਰੋ।
• ਬਾਹਰੀ API ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਕਤਾਰ ਪ੍ਰਣਾਲੀ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕਰੋ।
• ਫੇਲ ਹੋਣ ਅਤੇ ਦੁਬਾਰਾ ਦੁਬਾਰਾ ਚਲਾਉਣ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸਾਫ਼ ਕਰੋ।
• WooCommerce ਕਾਰਵਾਈ ਸਮਾਂ-ਸੂਚਕ ਨੂੰ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਜਾਂਚੋ।

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

admin-ajax.php ਅਤੇ REST API ਦੇ ਬੋਝ ਨੂੰ ਘਟਾਓ

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

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

ਪ੍ਰੈਕਟਿਕਲ ਸੁਧਾਰ ਕਦਮ

• ਪੈਨਲ ਵਿੱਚ ਖੁੱਲੀਆਂ ਪਲੱਗਇਨ ਸੂਚਨਾਵਾਂ ਨੂੰ ਘਟਾਓ।
• ਲਾਈਵ ਸਟੈਟਿਸਟਿਕਸ ਪਲੱਗਇਨਾਂ ਦੀ ਨਵੀਨੀਕਰਨ ਦੇ ਅੰਤਰਾਲ ਨੂੰ ਵਧਾਓ।
• ਹਿਰਟਬੀਟ API ਦੇ ਤੌਰ 'ਤੇ ਜਾਣੇ ਜਾਂਦੇ ਹਿਰਟਬੀਟ ਦੀ ਅਵਧੀ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰੋ।
• ਗੈਰ-ਜ਼ਰੂਰੀ ਡੈਸ਼ਬੋਰਡ ਵਿਜੇਟਾਂ ਨੂੰ ਬੰਦ ਕਰੋ।
• ਭਾਰੀ ਪਲੱਗਇਨਾਂ ਨੂੰ ਸਟੇਜਿੰਗ ਵਾਤਾਵਰਨ ਵਿੱਚ ਬੰਦ ਕਰਕੇ ਮੁਕਾਬਲਾ ਕਰੋ।

ਹਿਰਟਬੀਟ API ਖਾਸ ਤੌਰ 'ਤੇ ਲਿਖਤ ਸੰਪਾਦਨ ਸਕਰੀਨ 'ਤੇ ਆਟੋਮੈਟਿਕ ਸੇਵ ਅਤੇ ਸੈਸ਼ਨ ਨਿਗਰਾਨੀ ਲਈ ਲਾਭਦਾਇਕ ਹੈ। ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰਨ ਦੀ ਬਜਾਏ ਇਸਦੀ ਅਵਧੀ ਨੂੰ ਘਟਾਉਣਾ ਅਕਸਰ ਹੋਰ ਸੁਰੱਖਿਅਤ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਹੁੰਦਾ ਹੈ।

ਵੈੱਬ ਸਰਵਰ: LiteSpeed, Nginx ਅਤੇ Apache ਸੈਟਿੰਗਜ਼

WordPress ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਵੈੱਬ ਸਰਵਰ ਦੀ ਪਰਤ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। Apache ਲਚਕੀਲੇ .htaccess ਸਹਿਯੋਗ ਨਾਲ ਆਮ ਹੈ; Nginx ਉੱਚ ਸਮਕਾਲੀ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ; LiteSpeed ਤਾਂ WordPress ਕੈਸ਼ ਈਕੋਸਿਸਟਮ ਨਾਲ ਮਜ਼ਬੂਤ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਪਰ wp-admin ਪੱਖ 'ਤੇ ਪੂਰੀ ਸਫ਼ੇ ਦੀ ਕੈਸ਼ ਸੀਮਿਤ ਹੋਣ ਕਾਰਨ ਅਸਲ ਫਰਕ, ਕਨੈਕਸ਼ਨ ਪ੍ਰਬੰਧਨ, ਸਟੈਟਿਕ ਫਾਇਲਾਂ ਦੀ ਪ੍ਰਦਰਸ਼ਨੀ, ਕੰਪ੍ਰੈਸ਼ਨ ਅਤੇ PHP-FPM ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਵਿੱਚ ਪੈਂਦਾ ਹੈ।

gzip ਜਾਂ Brotli ਕੰਪ੍ਰੈਸ਼ਨ, ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼ ਹੈੱਡਰ ਅਤੇ HTTP/2 ਜਾਂ HTTP/3 ਸਹਿਯੋਗ ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ CSS, JS ਅਤੇ ਚਿੱਤਰ ਫਾਇਲਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। SSL ਸੰਰਚਨਾ ਦਾ ਆਧੁਨਿਕ ਹੋਣਾ ਵੀ ਕਨੈਕਸ਼ਨ ਦੇ ਸਮੇਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਸੁਰੱਖਿਅਤ ਅਤੇ ਕਾਰਗੁਜ਼ਾਰੀ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਲਈ SSL ਸਰਟੀਫਿਕੇਟ ਦੇ ਹੱਲ ਪੇਜ਼ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਸਰਵਰ ਪਰਤ ਵਿੱਚ ਚੈਕ ਕਰਨ ਵਾਲੀਆਂ ਗੱਲਾਂ

• HTTP/2 ਜਾਂ ਸੰਭਵ ਹੋਣ 'ਤੇ HTTP/3 ਸਹਿਯੋਗ ਸਰਗਰਮ ਹੈ?
• Brotli ਜਾਂ Gzip ਕੰਪ੍ਰੈਸ਼ਨ ਸਰਗਰਮ ਹੈ?
• ਸਟੈਟਿਕ ਫਾਇਲਾਂ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਕੈਸ਼ ਹੈੱਡਰ ਸਹੀ ਹਨ?
• Keep-alive ਸੈਟਿੰਗਜ਼ ਸੰਤੁਲਿਤ ਹਨ?
• PHP-FPM ਨਾਲ ਵੈੱਬ ਸਰਵਰ ਦੇ ਵਿਚਕਾਰ ਇੰਤਜ਼ਾਰ ਬਣਦਾ ਹੈ?

ਇਹ ਸੈਟਿੰਗਜ਼ ਇਕੱਲੇ ਹੀ ਜਾਦੂ ਨਹੀਂ ਕਰਦੀਆਂ; ਪਰ ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ ਫਾਇਲ ਲੋਡ ਕਰਨ ਦੇ ਸਮੇਂ ਨੂੰ ਅਤੇ ਗਰੰਥੀ ਨੂੰ ਸੁਧਾਰਨ ਵਿੱਚ ਸਹਾਇਕ ਹਨ।

ਸੁਰੱਖਿਆ ਸੈਟਿੰਗਜ਼ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ?

ਸੁਰੱਖਿਆ, ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਦੁਸ਼ਮਣ ਹੋਣਾ ਜਰੂਰੀ ਨਹੀਂ ਹੈ; ਪਰ ਗਲਤ ਸੰਗਠਿਤ ਸੁਰੱਖਿਆ ਪਲੱਗਇਨਾਂ ਜਾਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜ਼ਬਰਦਸਤ WAF ਨਿਯਮ wp-admin ਨੂੰ ਧੀਮਾ ਕਰ ਸਕਦੇ ਹਨ। ਹਰ ਬੇਨਤੀ 'ਤੇ ਡੂੰਗੀਆਂ ਫਾਇਲਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਵਾਲੇ, ਡਾਟਾਬੇਸ ਵਿੱਚ ਵੱਡੇ ਲੌਗ ਲਿਖਣ ਵਾਲੇ ਜਾਂ ਬਾਹਰੀ ਸੇਵਾ ਨੂੰ ਨਿਰੰਤਰ ਨਿਗਰਾਨੀ ਕਰਨ ਵਾਲੇ ਪਲੱਗਇਨ ਐਡਮਿਨ ਪੈਨਲ ਵਿੱਚ ਦੇਰ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।

ਦੂਜੇ ਪਾਸੇ, wp-login.