ਇੱਕ Magento ਡਿਵੈਲਪਰ ਨੇ 300 ਵੱਖ-ਵੱਖ ProductRepositoryInterface::getById() ਕਾਲਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ collection query ਨਾਲ ਬਦਲ ਦਿੱਤਾ। ਡਾਟਾਬੇਸ ਹਿੱਟਸ 300 ਤੋਂ ਘਟ ਕੇ 1 ਹੋ ਗਏ, ਅਤੇ category ਪੇਜ ਕਾਫ਼ੀ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੋਣ ਲੱਗਾ। ਪਰ ਇਸਦਾ ਨਤੀਜਾ ਕੀ ਨਿਕਲਿਆ? ਕੁਝ ਉਤਪਾਦ (products) storefront ਤੋਂ ਗਾਇਬ ਹੋ ਗਏ, ਜਿਸ ਨਾਲ ਖਰੀਦਦਾਰ ਅਤੇ ਮਾਲਕ ਦੋਵੇਂ ਹੈਰਾਨ ਰਹਿ ਗਏ।
Magento category ਪੇਜ 'ਤੇ N+1 ਸਮੱਸਿਆ
ਪੇਜ 'ਤੇ 300 ਉਤਪਾਦ ਸੂਚੀਬੱਧ ਸਨ। ਹਰੇਕ ਉਤਪਾਦ ਲਈ, ਕੋਡ ਨੇ repository ਦੇ getById() ਮੈਥਡ ਰਾਹੀਂ ਦੋ custom attributes ਫੈਚ ਕੀਤੇ, ਜਿਸ ਨਾਲ ਹਰੇਕ ਉਤਪਾਦ ਲਈ ਇੱਕ query ਬਣ ਰਹੀ ਸੀ—ਇਹ ਇੱਕ ਕਲਾਸਿਕ N+1 ਪੈਟਰਨ ਹੈ। ਉਹਨਾਂ per-product loads ਨੂੰ ਇੱਕ ਅਜਿਹੇ collection ਨਾਲ ਬਦਲਣ ਨਾਲ ਜੋ ਇੱਕ ਹੀ query ਵਿੱਚ ਸਾਰੀਆਂ ਲੋੜੀਂਦੀਆਂ rows ਖਿੱਚ ਲੈਂਦਾ ਹੈ, query ਦੀ ਗਿਣਤੀ ਬਹੁਤ ਘੱਟ ਗਈ। Front-end latency ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ, ਪਰ ਉਤਪਾਦਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚੋਂ ਉਹ ਚੀਜ਼ਾਂ ਗਾਇਬ ਹੋ ਗਈਆਂ ਜੋ ਪਹਿਲਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਸਨ।
Collection ਆਊਟ-ਆਫ-ਸਟਾਕ (out-of-stock) ਚੀਜ਼ਾਂ ਨੂੰ ਕਿਉਂ ਲੁਕਾਉਂਦਾ ਹੈ
Magento ਦਾ CatalogInventory ਮੋਡਿਊਲ frontend ਲਈ ਬਣਾਏ ਗਏ ਕਿਸੇ ਵੀ product collection ਵਿੱਚ ਆਪਣੇ ਆਪ ਇੱਕ “in-stock” ਫਿਲਟਰ ਜੋੜ ਦਿੰਦਾ ਹੈ। ਇਹ ਫਿਲਟਰ ਉਦੋਂ ਐਕਟਿਵ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਟੋਰ ਦੀ ਸੈਟਿੰਗ Display Out of Stock Products ਬੰਦ ਹੁੰਦੀ ਹੈ, ਜੋ ਕਿ ਉਹਨਾਂ ਵਪਾਰੀਆਂ ਲਈ ਇੱਕ ਆਮ ਚੋਣ ਹੈ ਜੋ ਉਪਲਬਧ ਨਾ ਹੋਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਨਹੀਂ ਦਿਖਾਉਣਾ ਚਾਹੁੰਦੇ।
ਇਸਦੇ ਉਲਟ, repository ਕਦੇ ਵੀ stock filter ਲਾਗੂ ਨਹੀਂ ਕਰਦੀ। ਇਹ ਸਿਰਫ਼ ਇਹ ਚੈੱਕ ਕਰਦੀ ਹੈ ਕਿ ਉਤਪਾਦ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਇਨਵੈਂਟਰੀ ਲੈਵਲ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਉਸਨੂੰ ਵਾਪਸ ਕਰ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ ਕੋਡ repository ਕਾਲਾਂ ਤੋਂ collection ਵਿੱਚ ਬਦਲਿਆ, ਤਾਂ stock filter ਨੇ ਚੁੱਪਚਾਪ ਹਰ ਉਸ ਉਤਪਾਦ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਜਿਸਦੀ ਮਾਤਰਾ (quantity) ਜ਼ੀਰੋ ਸੀ। ਕੋਈ error log ਨਹੀਂ ਹੋਇਆ; collection ਨੇ ਬੱਸ ਡਿਵੈਲਪਰ ਦੀ ਉਮੀਦ ਨਾਲੋਂ ਘੱਟ rows ਵਾਪਸ ਕੀਤੀਆਂ।
ਵਪਾਰੀਆਂ ਲਈ ਇਸਦਾ ਕੀ ਮਤਲਬ ਹੈ
ਇੱਕ storefront ਜੋ ਚੁੱਪਚਾਪ ਆਊਟ-ਆਫ-ਸਟਾਕ SKUs ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਕਈ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ:
- Front-end components ਨੂੰ ਗਲਤ ਐਂਟਰੀਆਂ ਮਿਲਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਖਾਲੀ ਲੇਬਲ ਜਾਂ ਗਲਤ ਕੀਮਤਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।
- Debugging ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਲੱਛਣ—ਉਤਪਾਦਾਂ ਦਾ ਗਾਇਬ ਹੋਣਾ—ਕੋਈ ਚੇਤਾਵਨੀ (warning) ਪੈਦਾ ਨਹੀਂ ਕਰਦਾ।
ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ automated tests in-stock fixtures ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਬੱਗ ਅਕਸਰ ਉਦੋਂ ਤੱਕ ਲੁਕਿਆ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਸਾਈਟ ਅਸਲ ਇਨਵੈਂਟਰੀ ਨਾਲ ਨਹੀਂ ਚੱਲਦੀ।
ਇਨਵੈਂਟਰੀ ਨੂੰ ਲੁਕਾਏ ਬਿਨਾਂ ਸਪੀਡ ਕਿਵੇਂ ਬਣਾਈ ਰੱਖੀਏ
- Default stock filter ਨੂੰ ਛੱਡ ਦਿਓ – ਜੇਕਰ ਤੁਹਾਨੂੰ ਉਪਲਬਧਤਾ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਹਰ ਉਤਪਾਦ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ collection ਤੋਂ ਫਿਲਟਰ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਹਟਾ ਦਿਓ। Magento ਹਰੇਕ query ਲਈ stock plugin ਨੂੰ ਡਿਸੇਬਲ ਕਰਨ ਜਾਂ ਬਦਲਣ ਲਈ ਮੈਥਡ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
- ਜਦੋਂ ਸਹੀ ਜਾਣਕਾਰੀ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ ਤਾਂ repository ਦੀ ਵਰਤੋਂ ਕਰੋ – Repository ਇਹ ਗਾਰੰਟੀ ਦਿੰਦੀ ਹੈ ਕਿ ਹਰੇਕ ਮੰਗੀ ਗਈ product ID ਵਾਪਸ ਕੀਤੀ ਜਾਵੇ, ਭਾਵੇਂ ਉਹ out of stock ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ। ਵਾਧੂ queries ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਲਈ ਨਤੀਜਿਆਂ ਨੂੰ cache ਕਰੋ ਜਾਂ ਸਿਰਫ਼ ਉਹਨਾਂ IDs ਨੂੰ ਲੋਡ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ।
- Resource model ਜਾਂ raw SQL ਦੀ ਵਰਤੋਂ ਕਰੋ – ਲੋੜੀਂਦੇ attributes ਲਈ ਸਿੱਧਾ product table ਨੂੰ query ਕਰੋ। ਇਹ ਸਾਰੇ collection plugins ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਪੂਰਾ ਕੰਟਰੋਲ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ rows ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਹਨ।
ਸਪੀਡ ਬਨਾਮ ਸਹੀਪਨ (Speed versus correctness)
ਇੱਕ ਸ਼ੋਰ ਵਾਲੇ (noisy) N+1 loop ਨੂੰ ਇੱਕ ਸਿੰਗਲ collection query ਨਾਲ ਬਦਲਣਾ ਕੁਦਰਤੀ ਲੱਗਦਾ ਹੈ; latency ਵਿੱਚ ਆਈ ਕਮੀ ਮਹਿਸੂਸ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਫਿਰ ਵੀ, ਇੱਕ ਤੇਜ਼ query ਜੋ ਉਤਪਾਦਾਂ ਦਾ ਗਲਤ ਸਮੂਹ ਵਾਪਸ ਕਰਦੀ ਹੈ, ਉਹ ਇੱਕ 결함 (defect) ਹੈ, optimization ਨਹੀਂ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਅਧੂਰੇ ਕੈਟਾਲਾਗ ਨੂੰ ਦਿਖਾਉਣ ਦੇ ਜੋਖਮ ਦੇ ਬਦਲੇ ਸਪੀਡ ਨੂੰ ਤੋਲਣਾ ਚਾਹੀਦਾ ਹੈ।
ਅੱਗੇ ਕਿਸ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਹੈ
- Configuration drift – ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ Display Out of Stock Products ਫਲੈਗ ਕਿਸੇ ਵੀ custom collection ਕੋਡ ਦੇ ਇਰਾਦੇ ਅਨੁਸਾਰ ਹੀ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।
- Plugin side effects – ਹੋਰ ਮੋਡਿਊਲ collections ਵਿੱਚ ਆਪਣੇ ਫਿਲਟਰ ਜੋੜ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਵੀ ਤੁਸੀਂ query stratgies ਬਦਲਦੇ ਹੋ, ਤਾਂ plugin stack ਦੀ ਸਮੀਖਿਆ ਕਰੋ।
ਸਬਕ ਸਪੱਸ਼ਟ ਹੈ: collection ਨਾਲ N+1 ਸਮੱਸਿਆ ਨੂੰ ਸੁਧਾਰਨਾ ਉਦੋਂ ਹੀ ਸਫਲ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਤੁਸੀਂ collection ਦੇ default filters ਦੀ ਵੀ ਜਾਂਚ ਕਰਦੇ ਹੋ। Magento ਦੇ built-in stock filter ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਨਾਲ ਤੁਹਾਡਾ ਕੈਟਾਲਾਗ ਚੁੱਪਚਾਪ ਘਟ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪ੍ਰਦਰਸ਼ਨ (performance) ਵਿੱਚ ਹੋਇਆ ਸੁਧਾਰ ਮਾਲੀਏ ਦੇ ਨੁਕਸਾਨ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ।