ਸਰਵਰ ਪਾਸੇ ਕੈਸ਼ਿੰਗ (Redis, Memcached) ਨਾਲ WordPress ਡੇਟਾਬੇਸ ਦੇ ਭਾਰ ਨੂੰ ਘਟਾਉਣਾ

ਸਰਵਰ ਪਾਸੇ ਕੈਸ਼ਿੰਗ, ਤੁਹਾਡੇ WordPress ਸਾਈਟ ਦੇ ਵਾਰ ਵਾਰ ਹੋਣ ਵਾਲੇ ਡੇਟਾਬੇਸ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ Redis ਜਾਂ Memcached ਵਰਗੇ ਮੈਮੋਰੀ ਆਧਾਰਿਤ ਪ੍ਰਣਾਲੀਆਂ 'ਚ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਰੱਖ ਕੇ MySQL ਜਾਂ MariaDB ਤੇ ਭਾਰ ਨੂੰ ਘਟਾਉਣ ਦਾ ਤਰੀਕਾ ਹੈ। ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਖਾਸ ਕਰਕੇ ਭਾਰੀ ਟ੍ਰੈਫਿਕ ਵਾਲੀਆਂ WordPress ਸਾਈਟਾਂ 'ਤੇ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, TTFB ਮੁੱਲ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ, CPU ਦੀ ਵਰਤੋਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਉਪਭੋਗੀ ਨੂੰ ਜਲਦੀ ਜਵਾਬ ਦੇਣ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਸੰਖੇਪ ਵਿੱਚ: WordPress ਹਰ ਅਰਜ਼ੀ 'ਤੇ ਇੱਕੋ ਹੀ ਡੇਟਾ ਡੇਟਾਬੇਸ ਤੋਂ ਦੁਬਾਰਾ ਦੁਬਾਰਾ ਖਿੱਚਣ ਦੀ ਬਜਾਏ, ਜਲਦੀ ਮੈਮੋਰੀ ਤੋਂ ਸੇਵਾ ਦਿੰਦਾ ਹੈ।

WordPress ਇੱਕ ਗਤੀਸ਼ੀਲ ਸਮੱਗਰੀ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਹੈ, ਇਸ ਲਈ ਹਰ ਪੰਨਾ ਦਿਖਾਉਣ 'ਤੇ ਥੀਮ, ਪਲੱਗਇਨ, ਮੀਨੂ, ਵਿਕਲਪ, ਉਪਭੋਗੀ ਸੈਸ਼ਨ, ਉਤਪਾਦ, ਟਿੱਪਣੀਆਂ ਅਤੇ ਸਮੱਗਰੀ ਡੇਟਾ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਚਲਾਉਂਦਾ ਹੈ। ਸਧਾਰਨ ਕਾਰਪੋਰੇਟ ਸਾਈਟ 'ਤੇ ਇਕੱਲੀ ਪੰਨਾ 40-80 ਪੁੱਛਗਿੱਛਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਜਦਕਿ WooCommerce, ਮੈਂਬਰਸ਼ਿਪ ਸਿਸਟਮ ਜਾਂ ਬਹੁਭਾਸ਼ੀ ਢਾਂਚੇ ਵਾਲੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਇਹ ਸੰਖਿਆ 150-300 ਪੁੱਛਗਿੱਛਾਂ ਤੱਕ ਜਾ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਵਧਦਾ ਹੈ, ਸਮੱਸਿਆ ਆਮ ਤੌਰ 'ਤੇ PHP ਨਹੀਂ, ਸਗੋਂ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨਾਂ ਅਤੇ ਦੁਬਾਰਾ ਦੁਬਾਰਾ ਪੁੱਛਗਿੱਛਾਂ ਹੁੰਦੀ ਹੈ। Redis ਅਤੇ Memcached ਇਸ ਮੌਕੇ 'ਤੇ ਕੰਮ ਆਉਂਦੇ ਹਨ।

ਇਸ ਗਾਈਡ ਵਿੱਚ, ਅਸੀਂ Redis ਅਤੇ Memcached ਵਿਚਕਾਰ ਫਰਕ, WordPress ਲਈ ਕਿਸ ਸਥਿਤੀ ਵਿੱਚ ਕਿਹੜਾ ਵਧੀਆ ਹੈ, ਔਬਜੈਕਟ ਕੈਸ਼ ਕਿਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਲਾਗੂ ਕਰਨ ਦੇ ਕਦਮ, ਮਾਪ ਮੈਟਰਿਕਸ ਅਤੇ ਆਮ ਕੀਤੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਵਿਸ਼ੇਸ਼ਜ্ঞান ਦੀ ਨਜ਼ਰ ਨਾਲ ਵੇਖਾਂਗੇ। ਜੇ ਤੁਹਾਡੀ ਸਾਈਟ ਹੌਲੀ ਹੋ ਰਹੀ ਹੈ, ਪ੍ਰਬੰਧਨ ਪੈਨਲ 'ਤੇ ਦੇਰੀ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਹੀ ਹੈ ਜਾਂ ਮੁਹਿੰਮ ਦੇ ਦੌਰਾਨ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਦਾ ਭਾਰ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਰਿਹਾ ਹੈ ਤਾਂ ਇਹ ਸਮੱਗਰੀ ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਅਮਲੀ ਰੋਡਮੈਪ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਹੋਰ ਮਜ਼ਬੂਤ ਅਧਾਰਭੂਤ ਯੋਜਨਾ ਲਈ WordPress ਹੋਸਟਿੰਗ ਪੈਕੇਜ ਅਤੇ ਉੱਚ ਟ੍ਰੈਫਿਕ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ VPS ਸਰਵਰ ਹੱਲ ਪੰਨਿਆਂ ਨੂੰ ਵੀ ਚੈੱਕ ਕਰ ਸਕਦੇ ਹੋ।

ਸਰਵਰ ਪਾਸੇ ਕੈਸ਼ਿੰਗ ਕੀ ਹੈ?

ਸਰਵਰ ਪਾਸੇ ਕੈਸ਼ਿੰਗ, ਡੇਟਾ ਨੂੰ ਬ੍ਰਾਉਜ਼ਰ ਦੀ ਬਜਾਏ ਸਰਵਰ ਪੱਧਰ 'ਤੇ ਰੱਖਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਇਹ ਪੱਧਰ; ਪੂਰੀ ਪੰਨਾ ਕੈਸ਼, opcode ਕੈਸ਼, CDN ਐਜ ਕੈਸ਼, ਡੇਟਾਬੇਸ ਪੁੱਛਗਿੱਛ ਕੈਸ਼ ਅਤੇ ਔਬਜੈਕਟ ਕੈਸ਼ ਵਰਗੇ ਵੱਖ-ਵੱਖ ਪੱਧਰਾਂ 'ਚ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। Redis ਅਤੇ Memcached ਆਮ ਤੌਰ 'ਤੇ persistent object cache, ਯਾਨੀ ਸਥਾਈ ਔਬਜੈਕਟ ਕੈਸ਼ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ।

WordPress ਪਾਸੇ ਔਬਜੈਕਟ ਕੈਸ਼, ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਪਹਿਲਾਂ ਗਣਨਾ ਕੀਤੇ ਗਏ ਜਾਂ ਡੇਟਾਬੇਸ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਔਬਜੈਕਟਾਂ ਨੂੰ ਛੋਟੇ ਸਮੇਂ ਲਈ RAM 'ਤੇ ਰੱਖਦਾ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ ਸਾਈਟ ਦੀਆਂ ਸੈਟਿੰਗਜ਼, ਮੀਨੂ ਬਣਤਰ, ਪੁੱਛਗਿੱਛ ਨਤੀਜੇ, ਉਤਪਾਦ ਵਿੱਕਲਪ, ਉਪਭੋਗੀ ਮੈਟਾ ਡੇਟਾ ਅਤੇ ਅਸਥਾਈ ਡੇਟਾ ਇਸ ਪੱਧਰ 'ਤੇ ਰੱਖੇ ਜਾ ਸਕਦੇ ਹਨ। RAM ਡਿਸਕ ਆਧਾਰਿਤ ਡੇਟਾਬੇਸ ਨਾਲੋਂ ਬਹੁਤ ਜਲਦੀ ਹੁੰਦੀ ਹੈ। ਇਸ ਲਈ, ਜੇਕਰ ਇੱਕੋ ਹੀ ਡੇਟਾ ਨੂੰ ਦੁਬਾਰਾ ਦੁਬਾਰਾ ਮੰਗਿਆ ਜਾਵੇ ਤਾਂ Redis ਜਾਂ Memcached ਰਾਹੀਂ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਨਾ, ਡੇਟਾਬੇਸ 'ਤੇ ਜਾਣ ਤੋਂ ਸਾਫ਼ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।

ਇੱਥੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਹੈ: ਸਰਵਰ ਪਾਸੇ ਕੈਸ਼ਿੰਗ, ਖਰਾਬ ਓਪਟੀਮਾਈਜ਼ ਕੀਤੀ ਗਈ ਸਾਈਟ ਨੂੰ ਅਚਾਨਕ ਬਿਲਕੁਲ ਪੂਰਨ ਨਹੀਂ ਬਣਾਉਂਦੀ। ਬਹੁਤ ਭਾਰੀ ਪਲੱਗਇਨ, ਗਲਤ ਪੁੱਛਗਿੱਛਾਂ, ਫੂਲਿਆ ਹੋਇਆ options ਟੇਬਲ, ਓਪਟੀਮਾਈਜ਼ ਨਾ ਕੀਤੇ ਗਏ WooCommerce ਕਾਰਟ ਫਲੋ ਜਾਂ ਗਲਤ ਕਰੋਨ ਸੈਟਿੰਗਜ਼ ਅਜੇ ਵੀ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਪਰੰਤੂ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਸੰਰਚਿਤ Redis ਜਾਂ Memcached ਪੱਧਰ, ਇੱਕ ਸਿਹਤਮੰਦ WordPress ਬੁਨਿਆਦ 'ਤੇ ਵੱਡਾ ਫਰਕ ਪੈਦਾ ਕਰਦਾ ਹੈ।

WordPress ਡੇਟਾਬੇਸ ਦਾ ਭਾਰ ਕਿਉਂ ਵਧਦਾ ਹੈ?

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

ਸਭ ਤੋਂ ਆਮ ਭਾਰ ਦੇ ਸਰੋਤ

• WooCommerce ਕਾਰਵਾਈਆਂ: ਕਾਰਟ, ਭੁਗਤਾਨ, ਸਟਾਕ ਅਤੇ ਉਤਪਾਦ ਵਿੱਕਲਪ ਲਗਾਤਾਰ ਨਵੀਨਤਮ ਡੇਟਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
• ਭਾਰੀ ਥੀਮ ਅਤੇ ਪੰਨਾ ਬਣਾਉਣ ਵਾਲੇ: ਬਹੁਤ ਸਤਰਾਂ ਵਾਲੇ ਛੋਟੇ ਕੋਡ ਅਤੇ ਗਤੀਸ਼ੀਲ ਵਿਜੇਟ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਸੰਖਿਆ ਵਧਾਉਂਦੇ ਹਨ।
• ਬਹੁਤ ਸਾਰੇ ਪਲੱਗਇਨ: ਹਰ ਪਲੱਗਇਨ ਆਪਣੇ ਟੇਬਲ ਅਤੇ ਪੁੱਛਗਿੱਛਾਂ ਨਾਲ ਵਾਧੂ ਖਰਚ ਕਰ ਸਕਦਾ ਹੈ।
• ਫੂਲਿਆ ਹੋਇਆ wp_options ਟੇਬਲ: Autoload ਮੁੱਲ ਉੱਚੀ ਵਿਕਲਪ ਹਰ ਅਰਜ਼ੀ 'ਤੇ ਮੈਮੋਰੀ 'ਚ ਲਿਆਉਂਦਾ ਹੈ।
• ਗ਼ੈਰ-ਕਾਫ਼ੀ ਸਰਵਰ ਸ੍ਰੋਤ: ਘੱਟ RAM, ਸੀਮਿਤ CPU ਅਤੇ ਹੌਲੀ ਡਿਸਕ ਰਚਨਾ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਕਤਾਰ ਨੂੰ ਵਧਾਉਂਦੇ ਹਨ।
• ਬੋਟ ਅਤੇ ਸਪੈਮ ਟ੍ਰੈਫਿਕ: ਅਸਲ ਉਪਭੋਗੀ ਨਾ ਹੋਣ ਵਾਲੀਆਂ ਅਰਜ਼ੀਆਂ ਵੀ ਡੇਟਾਬੇਸ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੀਆਂ ਹਨ।

ਇੱਕ ਤਜਰਬਾਤੀ ਉਦਾਹਰਣ ਦੇ ਨਾਲ ਸਮਝਾਈਏ: ਦਿਨ ਵਿੱਚ 20,000 ਪੰਨਾ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ WordPress ਸਾਈਟ 'ਤੇ ਜੇਕਰ ਪੰਨੇ ਦੇ ਪ੍ਰਤੀ ਔਸਤ 120 ਪੁੱਛਗਿੱਛਾਂ ਚੱਲਦੀਆਂ ਹਨ, ਤਾਂ ਸਿਧਾਂਤਿਕ ਤੌਰ 'ਤੇ ਦਿਨ ਵਿੱਚ 2.4 ਮਿਲੀਅਨ ਪੁੱਛਗਿੱਛਾਂ ਬਣਦੀਆਂ ਹਨ। ਇਸ ਵਿੱਚੋਂ 40% ਦੁਬਾਰਾ ਹੋ ਰਹੀ ਡੇਟਾ ਹੈ ਤਾਂ ਔਬਜੈਕਟ ਕੈਸ਼ ਨਾਲ ਸੈਂਕੜੇ ਹਜ਼ਾਰਾਂ ਪੁੱਛਗਿੱਛਾਂ ਡੇਟਾਬੇਸ 'ਤੇ ਬਿਨਾਂ ਜਾਂਦੇ RAM ਰਾਹੀਂ ਪੂਰੀਆਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਖਾਸ ਕਰਕੇ ਭਾਰੀ ਘੰਟਿਆਂ ਦੌਰਾਨ CPU ਅਤੇ I/O ਦੀ ਵਰਤੋਂ ਨੂੰ ਬਹੁਤ ਘਟਾਉਂਦਾ ਹੈ।

Redis ਅਤੇ Memcached WordPress 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ?

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

Redis ਦਾ ਕੰਮ ਕਰਨ ਦਾ ਤਰੀਕਾ

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

Memcached ਦਾ ਕੰਮ ਕਰਨ ਦਾ ਤਰੀਕਾ

Memcached ਵੀ ਮੈਮੋਰੀ ਆਧਾਰਤ ਅਤੇ ਕੀ-ਮੁੱਲ ਮੰਟਲ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲਾ ਤੇਜ਼ ਕੈਸ਼ ਸਿਸਟਮ ਹੈ। Redis ਦੇ ਮੁਕਾਬਲੇ ਇਸਦੀ ਸਧਾਰਨ ਬਣਤਰ ਹੈ। ਇਹ ਬਹੁਤ ਸਧਾਰਨ, ਤੇਜ਼, ਵੰਡੇ ਹੋਏ ਕੈਸ਼ ਸਥਿਤੀਆਂ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ। WordPress ਲਈ ਸਹੀ ਪਲੱਗਇਨ ਦੇ ਨਾਲ ਵਰਤੋਂ ਕਰਨ 'ਤੇ ਦੁਬਾਰਾ ਹੋ ਰਹੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ RAM ਤੋਂ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਪਰੰਤੂ ਵਿਕਸਿਤ ਡੇਟਾ ਸੰਰਚਨਾਵਾਂ, ਕਾਇਮ ਕਰਨ ਅਤੇ ਵਧੇਰੇ ਵਿਸਥਾਰਿਤ ਪ੍ਰਬੰਧਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਪੱਖੋਂ Redis ਦੇ ਬਰਾਬਰ ਲਚਕੀਲਾ ਨਹੀਂ ਹੈ।

Redis ਜਾਂ Memcached? ਤੁਲਨਾ ਟੇਬਲ

ਦੋਵੇਂ ਹੱਲ WordPress ਡੇਟਾਬੇਸ ਦੇ ਭਾਰ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ। ਚੋਣ ਕਰਨ ਵੇਲੇ ਸਾਈਟ ਦੇ ਟ੍ਰੈਫਿਕ ਦਾ ਢਾਂਚਾ, ਸਰਵਰ ਦੇ ਸ੍ਰੋਤ, ਪ੍ਰਬੰਧਨ ਦੀ ਆਸਾਨੀ ਅਤੇ ਪੈਮਾਨੇ ਦੀ ਗਤੀ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅਮਲ 'ਚ, ਆਧੁਨਿਕ WordPress ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ Redis ਅਕਸਰ ਵੱਧ ਲਾਭਕਾਰੀ ਹੁੰਦਾ ਹੈ। WooCommerce, LMS, ਫੋਰਮ, ਰਿਜ਼ਰਵੇਸ਼ਨ ਸਿਸਟਮ ਜਾਂ ਮੈਂਬਰਸ਼ਿਪ ਸਾਈਟ ਵਰਗੀਆਂ ਗਤੀਸ਼ੀਲ ਬਣਤਰਾਂ 'ਚ Redis ਦਾ ਪਲੱਗਇਨ ਸਮਰਥਨ ਅਤੇ ਪ੍ਰਬੰਧਨਤਾ ਖੂਬਸੂਰਤ ਹੈ। Memcached ਫਿਰ ਵੀ ਬਹੁਤ ਸਧਾਰਨ, ਤੇਜ਼ ਅਤੇ ਘੱਟ ਪੈਚੀਦਗੀ ਵਾਲੇ ਕੈਸ਼ ਪੱਧਰ ਦੀ ਲੋੜ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਮੁੱਲਵਾਨ ਹੈ।

WordPress ਲਈ ਸਰਵਰ ਪਾਸੇ ਕੈਸ਼ਿੰਗ ਕਦੋਂ ਲੋੜੀਂਦੀ ਹੈ?

ਹਰ ਛੋਟੀ WordPress ਸਾਈਟ ਦੇ ਪਹਿਲੇ ਦਿਨ ਤੋਂ Redis ਜਾਂ Memcached ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੈ। ਪਰ ਕੁਝ ਸੰਕੇਤ ਇਹ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਸਰਵਰ ਪਾਸੇ ਕੈਸ਼ਿੰਗ ਹੁਣ ਲੋੜ ਬਣ ਗਈ ਹੈ।

ਕੰਟਰੋਲ ਕਰਨ ਵਾਲੇ ਕਾਰਗੁਜ਼ਾਰੀ ਸੰਕੇਤ

• TTFB ਮੁੱਲ ਦੀ ਨਿਯਮਤ ਤੌਰ 'ਤੇ 600 ms ਤੋਂ ਵੱਧ ਜਾਣਾ।
• ਪ੍ਰਬੰਧਨ ਪੈਨਲ 'ਤੇ ਪੰਨਾ ਬਦਲਣ ਦੇ ਸਮੇਂ ਮਹਿਸੂਸ ਕਰਨ ਵਾਲੀ ਦੇਰੀ।
• MySQL CPU ਦੀ ਵਰਤੋਂ ਟ੍ਰੈਫਿਕ ਦੇ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਵਧਣੀ।
• WooCommerce ਕਾਰਟ ਅਤੇ ਭੁਗਤਾਨ ਪੰਨਿਆਂ 'ਤੇ ਦੇਰੀ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ।
• ਗੂਗਲਬੋਟ ਸਕੈਨਿੰਗ ਦੌਰਾਨ ਸਰਵਰ ਜਵਾਬ ਦੇ ਸਮੇਂ ਦਾ ਵਧਣਾ।
• ਹੋਸਟਿੰਗ ਪੈਨਲ 'ਤੇ ਸਮਕਾਲੀ ਕਨੈਕਸ਼ਨ ਜਾਂ ਸਰੋਤ ਸੀਮਾ ਦੀ ਚੇਤਾਵਨੀ ਦੇਖਣਾ।

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

ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਿਆਰੀ: ਮਾਪ ਨਾ ਕਰਨ ਤੋਂ ਸ਼ੁਰੂ ਨਾ ਕਰੋ

ਕੈਸ਼ਿੰਗ ਦੀ ਸੈਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਹਾਲਤ ਨੂੰ ਮਾਪਣਾ ਜ਼ਰੂਰੀ ਹੈ। ਨਹੀਂ ਤਾਂ ਸੁਧਾਰ ਕਿੱਥੋਂ ਆ ਰਿਹਾ ਹੈ, ਕਿਹੜਾ ਸੈਟਿੰਗ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕਿਹੜੀ ਸਮੱਸਿਆ ਜਾਰੀ ਰਹਿੰਦੀ ਹੈ, ਇਹ ਸਮਝਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਪੇਸ਼ੇਵਰ ਰੁਖ ਵਿੱਚ ਪਹਿਲਾਂ ਬੇਸ ਮੁੱਲ ਲਏ ਜਾਂਦੇ ਹਨ, ਫਿਰ Redis ਜਾਂ Memcached ਨੂੰ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਕੋ ਤਰ੍ਹਾਂ ਦੇ ਟੈਸਟ ਦੁਬਾਰਾ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਸ਼ੁਰੂਆਤ 'ਤੇ ਮਾਪਣ ਵਾਲੀਆਂ ਮੈਟਰਿਕਸ

• TTFB: ਪਹਿਲੀ ਬੇਟ 'ਤੇ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ। WebPageTest, GTmetrix ਜਾਂ ਬ੍ਰਾਉਜ਼ਰ ਵਿਕਾਸਕ ਟੂਲਾਂ ਨਾਲ ਮਾਪਿਆ ਜਾ ਸਕਦਾ ਹੈ।
• ਡੇਟਾਬੇਸ ਪੁੱਛਗਿੱਛ ਦੀ ਸੰਖਿਆ: Query Monitor ਵਰਗੀਆਂ ਟੂਲਾਂ ਨਾਲ ਪੰਨੇ ਪ੍ਰਤੀ ਪੁੱਛਗਿੱਛ ਦੀ ਸੰਖਿਆ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
• ਹੌਲੀ ਪੁੱਛਗਿੱਛਾਂ: MySQL ਸਲੋ ਪੁੱਛਗਿੱਛ ਲੌਗ ਦੇ ਰਾਹੀਂ ਬੰਧਨ ਪਛਾਣੇ ਜਾ ਸਕਦੇ ਹਨ।
• RAM ਦੀ ਵਰਤੋਂ: Redis ਜਾਂ Memcached ਲਈ ਸੁਰੱਖਿਅਤ ਮੈਮੋਰੀ ਦੀ ਰਾਖੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
• ਕੈਸ਼ ਹਿੱਟ ਰੇਸ਼ੋ: ਕੈਸ਼ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ ਅਰਜ਼ੀਆਂ ਦਾ ਅਨੁਪਾਤ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਰਚਿਤ ਸਾਈਟਾਂ 'ਤੇ 70% ਅਤੇ ਉਸ ਤੋਂ ਉੱਚੇ ਮੁੱਲ ਦੇਖੇ ਜਾ ਸਕਦੇ ਹਨ।

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

Redis ਨਾਲ WordPress ਔਬਜੈਕਟ ਕੈਸ਼ ਸੈਟਿੰਗ

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

ਕਦਮ ਬਾਈ ਕਦਮ Redis ਲਾਗੂ ਕਰਨ ਦੀ ਯੋਜਨਾ

• 1. ਬੈਕਅਪ ਲਓ: ਫਾਇਲਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਲਈ ਨਵੀਨਤਮ ਬੈਕਅਪ ਬਣਾਏ ਬਿਨਾਂ ਪ੍ਰਦਰਸ਼ਨ ਪੱਧਰ ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਾ ਕਰੋ।
• 2. ਸਰਵਰ ਦੇ ਸਮਰਥਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: Redis ਸੇਵਾ ਫਾਇਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, PHP Redis ਪਲੱਗਇਨ ਇੰਸਟਾਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਨੈਕਸ਼ਨ ਪੋਰਟ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸੰਰਚਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
• 3. WordPress ਪਲੱਗਇਨ ਇੰਸਟਾਲ ਕਰੋ: Redis Object Cache ਵਰਗਾ ਭਰੋਸੇਯੋਗ ਅਤੇ ਨਵੀਨਤਮ ਪਲੱਗਇਨ ਵਰਤੋਂ ਕਰੋ।
• 4. ਕਨੈਕਸ਼ਨ ਨੂੰ ਚਾਲੂ ਕਰੋ: ਪਲੱਗਇਨ ਪੈਨਲ ਤੋਂ Redis ਕਨੈਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ object-cache.php ਡ੍ਰਾਪ-ਇਨ ਫਾਈਲ ਬਣਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
• 5. wp-config ਸੈਟਿੰਗਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ: ਜਰੂਰਤ ਹੋਣ 'ਤੇ ਕੈਸ਼ ਕੀ ਸਾਲਟ, ਡੇਟਾਬੇਸ ਇੰਡੈਕਸ ਅਤੇ ਟਾਈਮਆਉਟ ਵਰਗੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਸੰਰਚਿਤ ਕਰੋ।
• 6. ਟੈਸਟ ਕਰੋ: ਪ੍ਰਬੰਧਨ ਪੈਨਲ, ਫਰੰਟ ਐਂਡ, ਕਾਰਟ ਅਤੇ ਲਾਗਇਨ ਕੀਤੇ ਉਪਭੋਗੀ ਦੇ ਅਨੁਭਵ ਦੀ ਜਾਂਚ ਕਰੋ।
• 7. ਨਿਗਰਾਨੀ ਕਰੋ: ਹਿੱਟ ਰੇਸ਼ੋ, ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਅਤੇ ਖਾਰਜ ਕੀਤੇ ਕੀ ਦਾਤਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ।

Redis ਲਈ ਮੈਮੋਰੀ ਸੀਮਾ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ, 2 GB RAM ਵਾਲੇ ਛੋਟੇ VPS ਤੇ Redis ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਨਿਯੰਤਰਣ ਦੇ ਮੈਮੋਰੀ ਵਰਤਣ ਦੇਣ ਨਾਲ PHP ਅਤੇ MySQL ਲਈ ਜਗ੍ਹਾ ਨਹੀਂ ਰਹਿ ਸਕਦੀ। ਸ਼ੁਰੂਆਤ 'ਤੇ 128-256 MB ਵਰਗੀਆਂ ਸੁਰੱਖਿਅਤ ਸੀਮਾਵਾਂ ਨਿਰਧਾਰਿਤ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ; ਭਾਰੀ WooCommerce ਸਾਈਟਾਂ 'ਤੇ ਇਹ ਮੁੱਲ ਜਰੂਰਤ ਦੇ ਅਨੁਸਾਰ 512 MB ਜਾਂ ਉਸ ਤੋਂ ਵੱਧ ਵਧਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਸਲ ਫੈਸਲਾ, ਅਸਲ ਵਰਤੋਂ ਦੇ ਮੈਟਰਿਕਸ ਦੇ ਅਨੁਸਾਰ ਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

Memcached ਨਾਲ WordPress ਔਬਜੈਕਟ ਕੈਸ਼ ਸੈਟਿੰਗ

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

ਕਦਮ ਬਾਈ ਕਦਮ Memcached ਲਾਗੂ ਕਰਨ ਦੀ ਯੋਜਨਾ

• 1. ਸਰਵਰ ਸੇਵਾ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰੋ: Memcached ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ PHP memcached ਐਕਸਟੈਂਸ਼ਨ ਸਰਗਰਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
• 2. ਸੁਰੱਖਿਆ ਸੈਟਿੰਗਾਂ ਬਣਾਓ: ਸੇਵਾ ਕਿਸੇ ਵੀ ਆਮ IP ਦੇ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਸਥਾਨਕ ਕਨੈਕਸ਼ਨ ਜਾਂ ਸੁਰੱਖਿਅਤ ਨੈੱਟਵਰਕ ਦੀ ਪREFERਕਰਨਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
• 3. WordPress ਪਲੱਗਇਨ ਚੁਣੋ: ਨਵੀਨ, ਸੰਭਾਲੀ ਜਾਣ ਵਾਲੀ ਅਤੇ ਔਬਜੈਕਟ ਕੈਸ਼ ਡ੍ਰਾਪ-ਇਨ ਸਹਾਇਤਾ ਵਾਲਾ ਪਲੱਗਇਨ ਵਰਤੋਂ ਕਰੋ।
• 4. ਮੈਮੋਰੀ ਸੀਮਾ ਨਿਰਧਾਰਿਤ ਕਰੋ: ਸਾਈਟ ਦੇ ਆਕਾਰ ਅਤੇ ਟ੍ਰੈਫਿਕ ਪ੍ਰੋਫਾਈਲ ਦੇ ਅਨੁਸਾਰ ਸ਼ੁਰੂਆਤ ਸੀਮਾ ਨਿਰਧਾਰਿਤ ਕਰੋ।
• 5. ਅਸਲ ਪੰਨਿਆਂ 'ਤੇ ਟੈਸਟ ਕਰੋ: ਖਾਸ ਤੌਰ 'ਤੇ ਲਾਗਇਨ ਕੀਤੇ ਉਪਭੋਗੀਆਂ ਅਤੇ ਗਤੀਸ਼ੀਲ ਪੰਨਾ ਵਿਹਾਰ ਦੀ ਜਾਂਚ ਕਰੋ।

Memcached ਦੀ ਸਧਾਰਨ ਬਣਤਰ ਦੇ ਫਾਇਦੇ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਕੁਝ ਪੈਚੀਦਗੀ ਵਾਲੇ WordPress ਸਥਿਤੀਆਂ ਵਿੱਚ Redis ਦੇ ਤਰ੍ਹਾਂ ਵਿਸਥਾਰਿਤ ਨਿਗਰਾਨੀ ਅਤੇ ਪ੍ਰਬੰਧਨ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਇਸ ਲਈ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਫੈਸਲਾ ਕਰਨ ਵੇਲੇ ਸਿਰਫ ਤੇਜ਼ੀ ਨਹੀਂ, ਸਗੋਂ ਓਪਰੇਸ਼ਨਲ ਰਖਵਾਲੀ ਦੀ ਆਸਾਨੀ ਵੀ ਸੋਚੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਕੈਸ਼ ਦੇ ਸਮੇਂ, ਸਾਫ਼ ਕਰਨ ਅਤੇ ਗੈਰ-ਕਾਇਮ ਕਰਨ ਦੀ ਰਣਨੀਤੀ

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

ਸਿਹਤਮੰਦ ਰਣਨੀਤੀ ਲਈ ਸੁਝਾਅ

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

ਉਦਾਹਰਣ ਵਜੋਂ, ਇੱਕ ਖ਼ਬਰਾਂ ਦੀ ਸਾਈਟ 'ਤੇ ਨਵਾਂ ਲੇਖ ਜਾਰੀ ਹੋਣ 'ਤੇ ਮੁੱਖ ਪੰਨਾ, ਸ਼੍ਰੇਣੀ ਪੰਨਾ ਅਤੇ ਸਬੰਧਤ ਟੈਗ ਪੰਨਿਆਂ ਦਾ ਅੱਪਡੇਟ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ। Redis ਔਬਜੈਕਟ ਕੈਸ਼ ਡੇਟਾਬੇਸ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ, ਪਰ ਜੇਕਰ ਪੂਰੀ ਪੰਨਾ ਕੈਸ਼ ਜਾਂ CDN ਪੱਧਰ ਨਾਲ ਮਿਲ ਕੇ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ ਤਾਂ ਸਾਰੇ ਪੱਧਰਾਂ ਦੀ ਸਾਫ਼ ਕਰਨ ਦੀ ਮੰਟਲ ਸਹਿਮਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਮਾਮਲੇ 'ਚ CDN, SSL ਅਤੇ ਸੁਰੱਖਿਅਤ ਪ੍ਰਕਾਸ਼ਨ ਪੱਧਰ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਲਈ SSL ਸਰਟੀਫਿਕੇਟ ਦੇ ਹੱਲ ਅਤੇ ਡੋਮੇਨ ਪ੍ਰਬੰਧਨ ਸਮੱਗਰੀਆਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ।

WooCommerce ਸਾਈਟਾਂ 'ਤੇ Redis ਅਤੇ Memcached ਦੀ ਵਰਤੋਂ

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

Redis, WooCommerce ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਵਧੀਆ ਚੋਣ ਵਜੋਂ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ। ਖਾਸ ਕਰਕੇ ਉਤਪਾਦ ਦੀ ਸੂਚੀ, ਫਿਲਟਰਿੰਗ ਅਤੇ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਨਿਸ਼ਾਨੀ ਭਾਗ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਪਰ, ਕਾਰਟ ਅਤੇ ਭੁਗਤਾਨ ਜਿਵੇਂ ਵਿਅਕਤੀਗਤ ਧਾਰਾਵਾਂ ਜੇਕਰ ਗਲਤ ਕੈਸ਼ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਗੰਭੀਰ ਉਪਭੋਗੀ ਅਨੁਭਵ ਅਤੇ ਆਰਡਰ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਔਬਜੈਕਟ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਦਿਆਂ ਪੰਨਾ ਕੈਸ਼ ਦੇ ਨਿਯਮ ਵੀ ਇਸ ਅਨੁਸਾਰ ਸੰਰਚਿਤ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।

WooCommerce ਲਈ ਅਮਲੀ ਸੈਟਿੰਗਾਂ

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

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

ਸੁਰੱਖਿਆ ਅਤੇ ਸਰਵਰ ਸੰਰਚਨਾ ਦੀ ਧਿਆਨ

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

ਮੂਲ ਸੁਰੱਖਿਆ ਨਿਗਰਾਨੀ ਸੂਚੀ

• Redis ਲਈ ਡਿਫਾਲਟ 6379 ਪੋਰਟ ਨੂੰ ਇੰਟਰਨੈਟ 'ਤੇ ਖੁੱਲ੍ਹਾ ਨਾ ਛੱਡੋ।
• Memcached ਲਈ 11211 ਪੋਰਟ ਦੇ ਬਾਹਰੀ ਪਹੁੰਚ ਲਈ ਬੰਦ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
• ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਪਾਸਵਰਡ, ਬਾਈਂਡ ਐਡਰੈਸ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਬਣਾਓ।
• ਸੇਵਾਵਾਂ ਨੂੰ ਨਵੀਨਤਮ ਸੰਸਕਰਣ 'ਤੇ ਰੱਖੋ।
• ਸਾਂਝੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕੈਸ਼ ਕੀ ਸਾਲਟ ਦਾ ਉਪਯੋਗ ਕਰਕੇ ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਟਕਰਾਉਂਦ ਤੋਂ ਬਚੋ।
• ਸਰਵਰ ਬੈਕਅਪ ਅਤੇ ਵਾਪਸੀ ਯੋਜਨਾ ਨੂੰ ਤਿਆਰ ਰੱਖੋ।

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

ਤੁਸੀਂ ਸਫਲਤਾ ਨੂੰ ਕਿਵੇਂ ਮਾਪਦੇ ਹੋ?

ਸੈਟਿੰਗ ਤੋਂ ਬਾਅਦ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਲਾਭ ਨੂੰ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਦੇਖਣ ਲਈ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੇ ਤੁਲਨਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਿਰਫ ਪੰਨਾ ਗਤੀ ਟੈਸਟ ਸਕੋਰ ਨਹੀਂ, ਸਰਵਰ ਪਾਸੇ ਸਰੋਤ ਦੀ ਵਰਤੋਂ ਵੀ ਦੇਖੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਨਿਗਰਾਨੀ ਕਰਨ ਵਾਲੇ ਮੁੱਖ ਸੰਕੇਤ

• TTFB ਵਿੱਚ ਘਟਾਉ: ਉਦਾਹਰਣ ਵਜੋਂ 850 ms ਤੋਂ 350 ms ਦੀ ਘਟਤ, ਉਪਭੋਗੀ ਅਨੁਭਵ ਦੇ ਲਈ ਇੱਕ ਮਜ਼ਬੂਤ ਸੁਧਾਰ ਹੈ।
• ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਸੰਖਿਆ ਵਿੱਚ ਕਮੀ: Query Monitor ਨਾਲ ਦੁਬਾਰਾ ਹੋ ਰਹੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਕਮੀ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
• ਕੈਸ਼ ਹਿੱਟ ਰੇਸ਼ੋ: 70-90% ਦੀ ਸੀਮਾ ਕਈ WordPress ਸਥਿਤੀਆਂ ਵਿੱਚ ਸਿਹਤਮੰਦ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।
• MySQL CPU ਦੀ ਵਰਤੋਂ: ਭਾਰੀ ਘੰਟਿਆਂ ਦੌਰਾਨ ਜ਼ਿਆਦਾ ਸਥਿਰ ਗ੍ਰਾਫ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।
• ਗਲਤੀ ਲੌਗ: ਕਨੈਕਸ਼ਨ ਗਲਤੀ, ਟਾਈਮਆਉਟ ਜਾਂ ਸਿਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।