ਕਰੈਸ਼ ਹੋ ਰਹੇ URL ਰੀਰਾਈਟਰ ਨਾਲ ਹੌਲੀ Squid ਬੇਨਤੀਆਂ

ਜੇ Squid ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਪਰ ਬੇਨਤੀਆਂ ਅੱਗੇ ਭੇਜਣ ਵਿੱਚ ਬਹੁਤ ਸਮਾਂ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਉਸ ਰਾਹ ਉੱਤੇ ਕੋਈ ਵੀ URL ਰੀਰਾਈਟਰ ਵੇਖੋ। Squid 5–7 ਵਿੱਚ url_rewrite_program ਉਸ ਬਾਹਰੀ ਪ੍ਰੋਗਰਾਮ ਦਾ ਨਾਂ ਦੱਸਦਾ ਹੈ ਜੋ ਸ਼ੁਰੂਆਤੀ ਪਹੁੰਚ ਜਾਂਚ ਤੋਂ ਬਾਅਦ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਬੇਨਤੀ ਨੂੰ ਮੰਜ਼ਿਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਦੇਰੀ ਕਰ ਸਕਦਾ ਹੈ।

1. ਪ੍ਰਭਾਵੀ ਰੀਰਾਈਟ ਕਮਾਂਡ ਪੜ੍ਹੋ, ਵੈਰਾਪਰ ਅਤੇ ਆਰਗੂਮੈਂਟ ਸਮੇਤ।
2. ਪ੍ਰਭਾਵਿਤ ਲੈਣ-ਦੇਣ ਨੂੰ ਹੈਲਪਰ ਡਾਇਗਨੋਸਟਿਕਸ ਨਾਲ ਮਿਲਾਓ। ਚਾਈਲਡ ਪ੍ਰੋਸੈਸ ਦਾ ਵਾਰ-ਵਾਰ ਬਾਹਰ ਨਿਕਲਣਾ, ਗਲਤ ਰੂਪ ਵਾਲੇ ਜਵਾਬ ਅਤੇ ਵਧਦੀ ਕਤਾਰ ਵੱਖਰੇ ਸੰਕੇਤ ਹਨ।
3. ਜਾਂਚੋ ਕਿ ਕੀ ਇੱਕ URL ਪੈਟਰਨ ਇਹ ਫੇਲ੍ਹ ਪੈਦਾ ਕਰ ਰਿਹਾ ਹੈ। ਅਣਸੰਬੰਧਿਤ resolver ਸੈਟਿੰਗਾਂ ਬਦਲਣ ਦੀ ਥਾਂ ਉਸ ਇਨਪੁਟ ਦਾ ਲੁਕਾਇਆ ਨਮੂਨਾ ਸੰਭਾਲੋ।

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

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

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