Developers often ask me the same question: "My API is slow. Where do I start?" The reflex is usually to upgrade the serv

ਡਿਵੈਲਪਰ ਅਕਸਰ ਮੈਨੂੰ ਇੱਕੋ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ: "ਮੇਰੀ API ਹੌਲੀ ਹੈ। ਮੈਂ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਕਰਾਂ?" ਆਮ ਤੌਰ 'ਤੇ ਜਵਾਬ ਸਰਵਰ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨਾ ਜਾਂ RAM ਨੂੰ ਦੁੱਗਣਾ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। ਇਸ ਨਾਲ ਪੈਸੇ ਖਰਚ ਹੁੰਦੇ ਹਨ ਅਤੇ ਇਹ ਬਹੁਤ ਘੱਟ ਹੀ ਮੂਲ ਕਾਰਨ (root cause) ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ Laravel ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ, ਰੁਕਾਵਟ (bottleneck) ਡਾਟਾਬੇਸ ਲੇਅਰ ਵਿੱਚ ਹੁੰਦੀ ਹੈ। ਫਰੇਮਵਰਕ ਦਾ ਸ਼ਾਨਦਾਰ ਸਿੰਟੈਕਸ (syntax) ਇਸ ਗੱਲ ਨੂੰ ਭੁੱਲਣਾ ਆਸਾਨ ਬਣਾ ਦਿੰਦਾ ਹੈ ਕਿ ਹਰ Eloquent ਕਾਲ ਅੰਤ ਵਿੱਚ SQL ਬਣ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਅਕਸਰ SQL ਹੀ ਉਹ ਜਗ੍ਹਾ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਮੁਸ਼ਕਲਾਂ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ।

ਸਰਵਰ ਦੀ ਕਿਸੇ ਵੀ ਸੈਟਿੰਗ ਨੂੰ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਪਣੀਆਂ ਕੁਐਰੀਆਂ (queries) 'ਤੇ ਵਿਧੀਵਤ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰੋ।

ਸਹੀ ਡਾਇਗਨੌਸਟਿਕ (Diagnostic) ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਹਨੇਰੇ ਵਿੱਚ ਅਨੁਮਾਨ ਲਗਾ ਕੇ ਆਪਟੀਮਾਈਜ਼ (optimize) ਨਾ ਕਰੋ। ਕੁਐਰੀਆਂ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਯੋਜਨਾ ਦੇ ਦੁਬਾਰਾ ਲਿਖਣਾ ਸਿਰਫ਼ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਹੈ, ਅਤੇ ਅੰਦਾਜ਼ੇ ਨਾਲ ਕਈ ਘੰਟੇ ਬਰਬਾਦ ਹੁੰਦੇ ਹਨ।

ਤੁਹਾਨੂੰ ਉਹ ਸਟੇਟਮੈਂਟਸ (statements) ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਂਦੀਆਂ ਹਨ। ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਸਲ ਲੋਡ (real load) ਦੇ ਅਧੀਨ ਦੇਖੋ। Laravel Telescope ਤੁਹਾਨੂੰ ਇੱਕ ਰਿਕਵੈਸਟ ਦੌਰਾਨ ਚਲਾਈ ਗਈ ਹਰ ਕੁਐਰੀ ਦਾ ਸਾਫ਼ ਦ੍ਰਿਸ਼ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਮਾਂ (timing) ਵੀ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। Laravel Debugbar ਲੋਕਲ ਡਿਵੈਲਪਮੈਂਟ ਦੌਰਾਨ ਉਹਨਾਂ ਨੂੰ ਤੁਹਾਡੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੁਰੰਤ ਅਸਧਾਰਨਤਾਵਾਂ (anomalies) ਦੀ ਪਛਾਣ ਕਰ ਸਕੋ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ (production) ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਫੜਨ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ MySQL Slow Query Log ਨੂੰ ਇਨੇਬਲ ਕਰੋ। ਇਹ ਉਹਨਾਂ ਸਟੇਟਮੈਂਟਸ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਥਰੈਸ਼ਹੋਲਡ (threshold) ਤੋਂ ਵੱਧ ਹੁੰਦੀਆਂ ਹਨ, ਜੋ ਕਿ ਉਹਨਾਂ ਅਚਾਨਕ ਆਉਣ ਵਾਲੀਆਂ ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਲੱਭਣ ਲਈ ਆਦਰਸ਼ ਹੈ ਜੋ ਛੋਟੇ ਡੇਟਾਸੈਟਾਂ ਵਿੱਚ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ। ਜੇਕਰ ਤੁਸੀਂ ਕੁਝ ਵੱਡਾ ਚਲਾ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ Application Performance Monitoring ਟੂਲ ਹੌਲੀ HTTP endpoints ਨੂੰ ਖਾਸ ਡਾਟਾਬੇਸ ਕਾਲਾਂ ਨਾਲ ਜੋੜ ਸਕਦਾ ਹੈ।

ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ ਡੇਟਾ ਦੀ ਸਮੀਖਿਆ ਕਰਦੇ ਹੋ, ਦੋ ਚੀਜ਼ਾਂ ਲੱਭੋ: ਅਬਸੋਲਿਊਟ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ (absolute execution time) ਅਤੇ ਕਾਲ ਫ੍ਰੀਕੁਐਂਸੀ (call frequency)। ਚਾਲੀ ਮਿਲੀਸੈਕਿੰਡ ਲੈਣ ਵਾਲੀ ਕੁਐਰੀ ਨੁਕਸਾਨਦੇਹ ਨਹੀਂ ਲੱਗਦੀ ਜਦੋਂ ਤੱਕ ਤੁਹਾਨੂੰ ਇਹ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਇਹ ਹਰ ਮਿੰਟ ਵਿੱਚ ਦੋ ਹਜ਼ਾਰ ਵਾਰ ਚੱਲਦੀ ਹੈ। ਇੱਕ ਤਿੰਨ-ਸੈਕਿੰਡ ਦੀ ਰਿਪੋਰਟ ਜੋ ਘੰਟੇ ਵਿੱਚ ਇੱਕ ਵਾਰ ਚੱਲਦੀ ਹੈ, ਉਹ ਅੱਧੇ-ਸੈਕਿੰਡ ਦੀ ਲੁੱਕਅੱਪ (lookup) ਨਾਲੋਂ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਹਰ ਪੇਜ 'ਤੇ ਚੱਲਦੀ ਹੈ। ਪਹਿਲਾਂ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ (high-impact) ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਠੀਕ ਕਰੋ।

ਸਭ ਕੁਝ ਮੰਗਣਾ ਬੰਦ ਕਰੋ

SELECT * ਸੁਵਿਧਾਜਨਕ ਹੈ। ਇਹ ਮਹਿੰਗਾ ਵੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ Model::all() ਲਿਖਦੇ ਹੋ ਜਾਂ ਕਾਲਮਾਂ ਦੇ ਨਾਮ ਲਏ ਬਿਨਾਂ ਰਿਜ਼ਲਟ ਸੈੱਟ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਤਾਂ MySQL ਹਰ ਮੈਚ ਹੋਏ ਰੋਅ (row) ਲਈ ਹਰ ਫੀਲਡ ਨੂੰ ਖਿੱਚਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਵੱਡੇ ਟੈਕਸਟ ਫੀਲਡ, JSON blobs, ਅਤੇ ਟੇਬਲ 'ਤੇ ਮੌਜੂਦ ਕੋਈ ਵੀ ਹੋਰ ਚੀਜ਼ ਸ਼ਾਮਲ ਹੈ। ਰਿਜ਼ਲਟ ਸੈੱਟ ਵਧਦਾ ਹੈ, ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਵਧਦੀ ਹੈ, ਅਤੇ ਰਿਸਪਾਂਸ ਨੂੰ ਸੀਰੀਅਲਾਈਜ਼ (serializing) ਕਰਨ ਵਿੱਚ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ ਵਧ ਜਾਂਦਾ ਹੈ।

ਸਪੱਸ਼ਟ ਰਹੋ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੰਟਰੋਲਰ ਨੂੰ ਸਿਰਫ਼ id, name, ਅਤੇ email ਫੀਲਡਾਂ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਉਹੀ ਮੰਗੋ:

User::select('id', 'name', 'email')->get();

ਕੁਐਰੀ ਬਿਲਡਰ (query builder) ਵਿੱਚ ਵੀ ਇਹੀ ਸਿਧਾਂਤ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਛੋਟੇ ਪੇਲੋਡ (payloads) ਨੈੱਟਵਰਕ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਚਲਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ 'ਤੇ ਘੱਟ RAM ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਇਹ ਉਪਲਬਧ ਸਭ ਤੋਂ ਸਸਤੇ ਫਾਇਦਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਫਿਰ ਵੀ ਇਸ ਨੂੰ ਛੱਡਣਾ ਆਸਾਨ ਹੈ ਕਿਉਂਕਿ Laravel SELECT * ਨੂੰ ਡਿਫੌਲਟ ਵਿਵਹਾਰ ਬਣਾਉਂਦਾ ਹੈ।

EXPLAIN ਨੂੰ ਆਪਣੇ ਬਦਲਾਅ ਕਰਨ ਲਈ ਮਾਰਗਦਰਸ਼ਕ ਬਣਾਓ

ਪਹਿਲਾਂ EXPLAIN ਚਲਾਏ ਬਿਨਾਂ ਕਦੇ ਵੀ ਕਿਸੇ ਹੌਲੀ ਕੁਐਰੀ ਨੂੰ ਰੀਫੈਕਟਰ (refactor) ਨਾ ਕਰੋ। MySQL ਵਿੱਚ, EXPLAIN ਕੀਵਰਡ ਕੁਐਰੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪਲਾਨ (execution plan) ਦਿਖਾਉਂਦਾ ਹੈ। ਇਹ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਦੱਸਦਾ ਹੈ ਕਿ ਆਪਟੀਮਾਈਜ਼ਰ ਤੁਹਾਡੇ ਡੇਟਾ ਨੂੰ ਲੱਭਣ ਲਈ ਕੀ ਕਰਨ ਦਾ ਇਰਾਦਾ ਰੱਖਦਾ ਹੈ।

type ਕਾਲਮ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਜੇਕਰ ਤੁਹਾਨੂੰ ALL ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਤਾਂ

ਇਹ ਗਲਤੀ ਚੁੱਪਚਾਪ ਇੰਡੈਕਸਾਂ ਨੂੰ ਅਯੋਗ ਕਰ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ WHERE ਕਲਾਜ਼ ਦੇ ਅੰਦਰ ਕਿਸੇ ਕਾਲਮ 'ਤੇ ਫੰਕਸ਼ਨ ਲਗਾਉਂਦੇ ਹੋ, ਤਾਂ MySQL ਨਹੀਂ...