ਬੇਤਰਤੀਬ I/O ਦੀ ਅਸਲ ਲਾਗਤ

ਤੁਹਾਡਾ ਕਾਰੋਬਾਰੀ ਸੌਫਟਵੇਅਰ ਇਸ ਤੋਂ ਹੌਲੀ ਹੈ - ਅਤੇ ਬੇਤਰਤੀਬ I/O ਅਦਿੱਖ ਦੋਸ਼ੀ ਹੈ

ਹਰ ਵਾਰ ਜਦੋਂ ਕੋਈ ਗਾਹਕ ਹੌਲੀ ਡੈਸ਼ਬੋਰਡ ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਕਰਦਾ ਹੈ, ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਹਾਡੀ ਟੀਮ ਰਿਪੋਰਟ ਲੋਡ ਹੋਣ ਲਈ ਵਾਧੂ ਤਿੰਨ ਸਕਿੰਟ ਉਡੀਕਦੀ ਹੈ, ਅਤੇ ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਹਾਡਾ ਚੈੱਕਆਉਟ ਪੰਨਾ ਇੱਕ ਖਰੀਦਦਾਰ ਨੂੰ ਬੇਸਬਰੀ ਨਾਲ ਗੁਆ ਦਿੰਦਾ ਹੈ — ਇਸ ਗੱਲ ਦੀ ਇੱਕ ਮਜ਼ਬੂਤ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਬੇਤਰਤੀਬ I/O ਚੁੱਪਚਾਪ ਤੁਹਾਡੀ ਆਮਦਨ ਨੂੰ ਘਟਾ ਰਿਹਾ ਹੈ। ਇਹ ਡੇਟਾਬੇਸ ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਰਾਖਵਾਂ ਕੋਈ ਬੁਜ਼ਵਰਡ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਮਾਪਣਯੋਗ, ਮਹਿੰਗੀ ਰੁਕਾਵਟ ਹੈ ਜੋ ਲਗਭਗ ਹਰ ਕਾਰੋਬਾਰੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਲੁਕੀ ਹੋਈ ਹੈ, CRM ਖੋਜਾਂ ਤੋਂ ਲੈ ਕੇ ਇਨਵੌਇਸ ਬਣਾਉਣ ਤੱਕ। ਇਸਦੀ ਅਸਲ ਲਾਗਤ ਨੂੰ ਸਮਝਣਾ ਸਿਰਫ਼ ਇੱਕ ਤਕਨੀਕੀ ਅਭਿਆਸ ਨਹੀਂ ਹੈ - ਇਹ ਇੱਕ ਵਿੱਤੀ ਹੈ। ਜਿਹੜੀਆਂ ਕੰਪਨੀਆਂ ਇਸ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀਆਂ ਹਨ, ਉਹ ਫੁੱਲੇ ਹੋਏ ਕਲਾਉਡ ਬਿੱਲਾਂ, ਗੁਆਚੇ ਗਾਹਕਾਂ ਅਤੇ ਸਕਰੀਨਾਂ 'ਤੇ ਇੰਤਜ਼ਾਰ ਵਿੱਚ ਫਸੀਆਂ ਟੀਮਾਂ ਦੀ ਕੀਮਤ ਅਦਾ ਕਰਦੀਆਂ ਹਨ ਜੋ ਤੁਰੰਤ ਲੋਡ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਰੈਂਡਮ I/O ਦਾ ਅਸਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਹੈ (ਅਤੇ ਇਹ ਮਹਿੰਗਾ ਕਿਉਂ ਹੈ)

ਇਸਦੇ ਮੂਲ ਵਿੱਚ, I/O — ਇਨਪੁਟ/ਆਊਟਪੁੱਟ — ਸਟੋਰੇਜ਼ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਜਦੋਂ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਡੇਟਾਬੇਸ ਤੋਂ ਰਿਕਾਰਡ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ, ਡਿਸਕ ਤੋਂ ਫਾਈਲਾਂ ਲੋਡ ਕਰਦੀ ਹੈ, ਜਾਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਲਿਖਦੀ ਹੈ, ਤਾਂ ਇਹ I/O ਓਪਰੇਸ਼ਨ ਕਰਦੀ ਹੈ। ਇਹ ਓਪਰੇਸ਼ਨ ਦੋ ਰੂਪਾਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ: ਕ੍ਰਮਵਾਰ ਅਤੇ ਬੇਤਰਤੀਬ। ਕ੍ਰਮਵਾਰ I/O ਨਾਲ ਜੁੜੇ ਬਲਾਕਾਂ ਵਿੱਚ ਡੇਟਾ ਪੜ੍ਹਦਾ ਜਾਂ ਲਿਖਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਕਿਤਾਬ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਪੜ੍ਹਨਾ। ਬੇਤਰਤੀਬੇ I/O ਜੰਪ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਪੰਨਾ 47, ਫਿਰ ਪੰਨਾ 3, ਫਿਰ ਪੰਨਾ 812।

ਇਹਨਾਂ ਦੋ ਪੈਟਰਨਾਂ ਵਿਚਕਾਰ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਅੰਤਰ ਹੈਰਾਨ ਕਰਨ ਵਾਲਾ ਹੈ। ਇੱਕ ਪਰੰਪਰਾਗਤ ਹਾਰਡ ਡਰਾਈਵ 'ਤੇ, ਕ੍ਰਮਵਾਰ ਰੀਡ 150-200 MB/s ਦੇ ਥ੍ਰੋਪੁੱਟ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਬੇਤਰਤੀਬ ਰੀਡ ਅਕਸਰ 0.5-1.5 MB/s - 100x ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ ਦਾ ਅੰਤਰ ਹੁੰਦਾ ਹੈ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਆਧੁਨਿਕ NVMe SSDs 'ਤੇ, ਜੋ ਕਿ ਬੇਤਰਤੀਬੇ I/O ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਨਾਟਕੀ ਢੰਗ ਨਾਲ ਸੁਧਾਰ ਕਰਦੇ ਹਨ, ਕੰਮ ਦੇ ਬੋਝ ਦੇ ਆਧਾਰ 'ਤੇ ਅੰਤਰ ਅਜੇ ਵੀ 5x ਤੋਂ 20x ਤੱਕ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਡੀ ਕਾਰੋਬਾਰੀ ਐਪਲੀਕੇਸ਼ਨ ਹਜ਼ਾਰਾਂ ਛੋਟੀਆਂ, ਖਿੰਡੀਆਂ ਹੋਈਆਂ ਪੜ੍ਹਨ ਦੀਆਂ ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਜਾਰੀ ਕਰਦੀ ਹੈ — ਇੱਥੇ ਇੱਕ ਗਾਹਕ ਦਾ ਨਾਮ ਖਿੱਚਣਾ, ਇੱਕ ਇਨਵੌਇਸ ਲਾਈਨ ਆਈਟਮ, ਉੱਥੇ ਇੱਕ ਅਨੁਮਤੀ ਦੀ ਜਾਂਚ — ਹਰੇਕ ਹੌਪ ਮਾਈਕ੍ਰੋਸਕਿੰਡ ਵਿੱਚ ਮਾਪੀ ਗਈ ਲੇਟੈਂਸੀ ਨੂੰ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਅਸਲ ਉਪਭੋਗਤਾ ਉਡੀਕ ਸਮੇਂ ਦੇ ਸਕਿੰਟਾਂ ਵਿੱਚ ਮਿਸ਼ਰਿਤ ਹੁੰਦਾ ਹੈ।

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

ਹਰ ਵਪਾਰਕ ਸੰਚਾਲਨ 'ਤੇ ਲੁਕਿਆ ਹੋਇਆ ਟੈਕਸ

ਵਿਚਾਰ ਕਰੋ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਸਿੰਗਲ ਉਪਭੋਗਤਾ CRM ਡੈਸ਼ਬੋਰਡ ਖੋਲ੍ਹਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਗਾਹਕ ਟੇਬਲ ਤੋਂ ਪੁੱਛਗਿੱਛ ਕਰਦੀ ਹੈ, ਇਸਨੂੰ ਹਾਲ ਹੀ ਦੇ ਗਤੀਵਿਧੀ ਲੌਗਸ ਨਾਲ ਜੋੜਦੀ ਹੈ, ਸੰਬੰਧਿਤ ਡੀਲ ਮੁੱਲਾਂ ਨੂੰ ਖਿੱਚਦੀ ਹੈ, ਉਪਭੋਗਤਾ ਅਨੁਮਤੀਆਂ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਗਿਣਤੀ ਲੋਡ ਕਰਦੀ ਹੈ, ਅਤੇ ਡਿਸਪਲੇ ਤਰਜੀਹਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ। ਇਹਨਾਂ ਸਵਾਲਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਡਿਸਕ 'ਤੇ ਵੱਖ-ਵੱਖ ਸਥਾਨਾਂ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀਆਂ ਵੱਖ-ਵੱਖ ਟੇਬਲਾਂ ਨੂੰ ਛੂਹ ਸਕਦਾ ਹੈ। ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਜੋ 50 ਗਾਹਕ ਰਿਕਾਰਡਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਹੁੱਡ ਦੇ ਹੇਠਾਂ 300 ਤੋਂ 500 ਬੇਤਰਤੀਬ I/O ਓਪਰੇਸ਼ਨਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਪੀਕ ਕਾਰੋਬਾਰੀ ਘੰਟਿਆਂ ਦੌਰਾਨ 200 ਸਮਕਾਲੀ ਉਪਭੋਗਤਾਵਾਂ ਦੁਆਰਾ ਇਸ ਨੂੰ ਗੁਣਾ ਕਰੋ, ਅਤੇ ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਸਰਵਰ ਪ੍ਰਤੀ ਸਕਿੰਟ 100,000 ਬੇਤਰਤੀਬੇ ਰੀਡਜ਼ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਰਿਹਾ ਹੈ।

ਇਹ ਕਾਲਪਨਿਕ ਨਹੀਂ ਹੈ। ਪਰਕੋਨਾ ਦੁਆਰਾ 2024 ਦੇ ਇੱਕ ਅਧਿਐਨ ਵਿੱਚ ਪਾਇਆ ਗਿਆ ਹੈ ਕਿ ਖਰਾਬ ਅਨੁਕੂਲਿਤ ਡਾਟਾਬੇਸ ਵਰਕਲੋਡ ਉਨ੍ਹਾਂ ਦੇ ਕੁੱਲ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮੇਂ ਦਾ 68% I/O ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਉਡੀਕ ਵਿੱਚ ਬਿਤਾਉਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਬੇਤਰਤੀਬ ਪਹੁੰਚ ਪੈਟਰਨ ਪ੍ਰਾਇਮਰੀ ਅਪਰਾਧੀ ਹਨ। ਹਜ਼ਾਰਾਂ ਕਾਰੋਬਾਰਾਂ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੀ SaaS ਕੰਪਨੀ ਲਈ, ਇਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਉੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀਆਂ ਲਾਗਤਾਂ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ। ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ IOPS (I/O ਓਪਰੇਸ਼ਨ ਪ੍ਰਤੀ ਸਕਿੰਟ) ਦੁਆਰਾ ਚਾਰਜ ਕਰਦੇ ਹਨ, ਅਤੇ ਬੇਤਰਤੀਬੇ I/O-ਭਾਰੀ ਵਰਕਲੋਡ ਮਾਸਿਕ ਸਟੋਰੇਜ ਬਿੱਲਾਂ ਨੂੰ ਸੈਂਕੜੇ ਤੋਂ ਹਜ਼ਾਰਾਂ ਡਾਲਰਾਂ ਵਿੱਚ ਧੱਕ ਸਕਦੇ ਹਨ — ਡਾਟਾ ਵਾਲੀਅਮ ਦੇ ਕਾਰਨ ਨਹੀਂ, ਪਰ ਪਹੁੰਚ ਪੈਟਰਨਾਂ ਦੇ ਕਾਰਨ।

ਲਾਗਤ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਤੋਂ ਪਰੇ ਹੈ। ਅਕਮਈ ਦੀ ਖੋਜ ਦੇ ਅਨੁਸਾਰ, ਹਰ 100 ਮਿਲੀਸਕਿੰਟ ਵਾਧੂ ਪੰਨਾ ਲੋਡ ਸਮਾਂ ਲਗਭਗ 7% ਤੱਕ ਪਰਿਵਰਤਨ ਦਰਾਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਬੇਤਰਤੀਬ I/O ਤੁਹਾਡੇ ਇਨਵੌਇਸ ਜਨਰੇਸ਼ਨ ਜਾਂ ਰਿਪੋਰਟ ਲੋਡਿੰਗ ਵਿੱਚ ਇੱਕ ਪੂਰਾ ਸਕਿੰਟ ਜੋੜਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਗਣਨਾ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ — ਤੁਸੀਂ ਮਾਲੀਆ ਬਰਨ ਕਰ ਰਹੇ ਹੋ।

ਜਿੱਥੇ ਕਾਰੋਬਾਰੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਖ਼ਰਾਬ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

ਜਦੋਂ I/O ਪੈਟਰਨਾਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ ਤਾਂ ਸਾਰੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਰਾਬਰ ਨਹੀਂ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਕੁਝ ਸਭ ਤੋਂ ਆਮ ਕਾਰੋਬਾਰੀ ਕਾਰਵਾਈਆਂ ਵੀ ਬੇਤਰਤੀਬ ਪਹੁੰਚ ਲਈ ਸਭ ਤੋਂ ਭੈੜੇ ਅਪਰਾਧੀ ਹਨ:

• ਖੋਜ ਅਤੇ ਫਿਲਟਰਿੰਗ: ਕਈ ਖੇਤਰਾਂ (ਨਾਮ, ਮਿਤੀ, ਸਥਿਤੀ, ਟੈਗਸ) ਵਿੱਚ ਪੁੱਛਗਿੱਛ ਕਰਨਾ ਡੇਟਾਬੇਸ ਨੂੰ ਸਟੋਰੇਜ ਵਿੱਚ ਖਿੰਡੇ ਹੋਏ ਸੂਚਕਾਂਕ ਨੂੰ ਸਕੈਨ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ, ਭਾਰੀ ਬੇਤਰਤੀਬੇ ਰੀਡਜ਼ ਪੈਦਾ ਕਰਦਾ ਹੈ
• ਡੈਸ਼ਬੋਰਡ ਐਗਰੀਗੇਸ਼ਨ: ਆਮਦਨ ਨੂੰ ਜੋੜਨ, ਸਰਗਰਮ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਗਿਣਤੀ ਕਰਨ, ਜਾਂ ਬਕਾਇਆ ਇਨਵੌਇਸ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਵੱਖ-ਵੱਖ ਡੇਟਾ ਪੰਨਿਆਂ ਵਿੱਚ ਫੈਲੀਆਂ ਹਜ਼ਾਰਾਂ ਕਤਾਰਾਂ ਨੂੰ ਛੂਹਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ
• ਇਜਾਜ਼ਤ ਜਾਂਚ: ਬਹੁ-ਕਿਰਾਏਦਾਰ ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ ਰੋਲ-ਅਧਾਰਿਤ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਲਈ ਅਕਸਰ ਪ੍ਰਤੀ ਬੇਨਤੀ ਕਈ ਖੋਜਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ — ਉਪਭੋਗਤਾ → ਭੂਮਿਕਾ → ਅਨੁਮਤੀਆਂ → ਸਰੋਤ — ਹਰੇਕ ਵੱਖ-ਵੱਖ ਟੇਬਲ ਨੂੰ ਮਾਰਦਾ ਹੈ
• ਰਿਪੋਰਟ ਬਣਾਉਣਾ: ਮਹੀਨਾਵਾਰ ਪੇਰੋਲ ਰਿਪੋਰਟਾਂ, ਫਲੀਟ ਮੇਨਟੇਨੈਂਸ ਸਾਰਾਂਸ਼, ਜਾਂ HR ਵਿਸ਼ਲੇਸ਼ਣ ਦਰਜਨਾਂ ਟੇਬਲਾਂ ਤੋਂ ਇੱਕੋ ਸਮੇਂ ਡਾਟਾ ਖਿੱਚਦੇ ਹਨ
• ਰੀਅਲ-ਟਾਈਮ ਸੂਚਨਾਵਾਂ: ਨਵੇਂ ਸੁਨੇਹਿਆਂ, ਕਾਰਜ ਅੱਪਡੇਟ, ਅਤੇ ਮੌਡਿਊਲਾਂ ਵਿੱਚ ਸਿਸਟਮ ਚੇਤਾਵਨੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਨਾਲ ਛੋਟੀਆਂ, ਬੇਤਰਤੀਬ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਇੱਕ ਨਿਰੰਤਰ ਸਟ੍ਰੀਮ ਬਣ ਜਾਂਦੀ ਹੈ

ਪੈਟਰਨ ਸਪੱਸ਼ਟ ਹੈ: ਪਲੇਟਫਾਰਮ ਦੀ ਪੇਸ਼ਕਸ਼ ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਮੋਡੀਊਲ ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ, ਓਨੇ ਹੀ ਜ਼ਿਆਦਾ I/O ਮਾਰਗ ਗੁਣਾ ਕਰਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਨ ਲਿੰਕ-ਇਨ-ਬਾਇਓ ਟੂਲ ਪ੍ਰਤੀ ਪੰਨਾ ਲੋਡ 10 ਸਵਾਲ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। CRM, ਇਨਵੌਇਸਿੰਗ, HR, ਪੇਰੋਲ, ਬੁਕਿੰਗ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਮੋਡੀਊਲ ਦੇ ਨਾਲ ਇੱਕ ਪੂਰਾ ਕਾਰੋਬਾਰੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ — ਜਿਵੇਂ ਕਿ ਮੇਵੇਜ਼ ਆਪਣੇ 207 ਮੋਡਿਊਲਾਂ ਵਿੱਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ — ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ ਸੈਂਕੜੇ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਪਲੇਟਫਾਰਮ ਜੋ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਜੋ ਸੁਸਤ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ, ਵਿੱਚ ਅੰਤਰ ਅਕਸਰ ਇਸ ਗੱਲ 'ਤੇ ਆ ਜਾਂਦਾ ਹੈ ਕਿ ਪਰਦੇ ਦੇ ਪਿੱਛੇ ਉਹਨਾਂ I/O ਪੈਟਰਨਾਂ ਨੂੰ ਕਿੰਨੀ ਸਮਝਦਾਰੀ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਮੱਸਿਆ 'ਤੇ ਹਾਰਡਵੇਅਰ ਸੁੱਟਣਾ ਕੰਮ ਕਿਉਂ ਨਹੀਂ ਕਰਦਾ

ਐਪਲੀਕੇਸ਼ਨ ਹੌਲੀ ਹੋਣ ਦੀ ਪ੍ਰਵਿਰਤੀ ਅੱਪਗਰੇਡ ਕਰਨਾ ਹੈ। ਵੱਡੇ ਸਰਵਰ, ਤੇਜ਼ SSD, ਹੋਰ RAM। ਅਤੇ ਜਦੋਂ ਕਿ ਹਾਰਡਵੇਅਰ ਸੁਧਾਰ ਮਦਦ ਕਰਦੇ ਹਨ, ਉਹ ਘਟਦੇ ਰਿਟਰਨ ਦੀ ਇੱਕ ਵਕਰ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ ਜੋ CFOs ਨੂੰ ਅਸੁਵਿਧਾਜਨਕ ਬਣਾਉਂਦਾ ਹੈ। ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਸਰਵਰ ਦੀ RAM ਨੂੰ 64GB ਤੋਂ 128GB ਤੱਕ ਦੁੱਗਣਾ ਕਰਨ ਨਾਲ ਕੈਸ਼ ਹਿੱਟ ਦਰਾਂ ਨੂੰ 92% ਤੋਂ 96% ਤੱਕ ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ - ਇੱਕ ਅਰਥਪੂਰਨ ਲਾਭ, ਪਰ ਬਾਕੀ ਬਚੇ 4% ਕੈਸ਼ ਖੁੰਝਣ ਨਾਲ ਅਜੇ ਵੀ ਬੇਤਰਤੀਬ I/O ਨਾਲ ਸਟੋਰੇਜ ਹਿੱਟ ਹੁੰਦੀ ਹੈ। AWS 'ਤੇ ਤੁਹਾਡੇ IOPS ਅਲਾਟਮੈਂਟ ਨੂੰ 3,000 ਤੋਂ 10,000 ਤੱਕ ਤਿੰਨ ਗੁਣਾ ਕਰਨ ਨਾਲ ਲਗਭਗ $450 ਪ੍ਰਤੀ ਮਹੀਨਾ ਹੋਰ ਖਰਚ ਆਉਂਦਾ ਹੈ ਪਰ ਸਿਰਫ p99 ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਸਮੇਂ ਵਿੱਚ 30% ਤੱਕ ਸੁਧਾਰ ਹੋ ਸਕਦਾ ਹੈ।

ਅਸਲ ਸਮੱਸਿਆ ਆਰਕੀਟੈਕਚਰ ਦੀ ਹੈ। ਬੇਤਰਤੀਬ I/O ਅਕਸਰ ਡੂੰਘੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਲੱਛਣ ਹੁੰਦਾ ਹੈ: ਗੁੰਮ ਜਾਂ ਖਰਾਬ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਸੂਚਕਾਂਕ, N+1 ਪੁੱਛਗਿੱਛ ਪੈਟਰਨ ਜਿੱਥੇ ਐਪਲੀਕੇਸ਼ਨ ਬੈਚਿੰਗ ਦੀ ਬਜਾਏ ਪ੍ਰਤੀ ਆਈਟਮ ਇੱਕ ਡਾਟਾਬੇਸ ਕਾਲ ਕਰਦੀ ਹੈ, ਓਵਰ-ਆਮ ਸਕੀਮਾਂ ਜਿਸ ਲਈ ਇੱਕ ਡਿਸਪਲੇ ਕਤਾਰ ਲਈ ਪੰਜ ਟੇਬਲ ਜੋੜਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਰੀਡ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਜਾਂ ਕੈਚਿੰਗ ਲੇਅਰਾਂ ਦੀ ਘਾਟ। ਹਾਰਡਵੇਅਰ ਅੱਪਗਰੇਡ ਲੱਛਣ ਦਾ ਇਲਾਜ ਕਰਦੇ ਹਨ। ਆਰਕੀਟੈਕਚਰਲ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਕਾਰਨ ਦਾ ਇਲਾਜ ਕਰਦਾ ਹੈ।

ਸਭ ਤੋਂ ਮਹਿੰਗਾ I/O ਓਪਰੇਸ਼ਨ ਉਹ ਹੈ ਜੋ ਪਹਿਲਾਂ ਮੌਜੂਦ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੇਜ਼ ਸਟੋਰੇਜ 'ਤੇ ਖਰਚ ਕੀਤੇ ਗਏ ਹਰੇਕ ਡਾਲਰ ਲਈ, ਪੁੱਛਗਿੱਛ ਅਨੁਕੂਲਤਾ 'ਤੇ ਖਰਚੇ ਗਏ 10 ਸੈਂਟ ਵਧੀਆ ਨਤੀਜੇ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਕਾਰਗੁਜ਼ਾਰੀ 'ਤੇ ਜਿੱਤਣ ਵਾਲੀਆਂ ਕੰਪਨੀਆਂ ਆਪਣੇ ਮੁਕਾਬਲੇ ਨੂੰ ਪਛਾੜਦੀਆਂ ਨਹੀਂ ਹਨ - ਉਹ ਆਪਣੇ ਡੇਟਾ ਐਕਸੈਸ ਪੈਟਰਨਾਂ ਨੂੰ ਬਾਹਰ-ਵਿਚਾਰਦੀਆਂ ਹਨ।

ਵਿਹਾਰਕ ਰਣਨੀਤੀਆਂ ਜੋ ਅਸਲ ਵਿੱਚ ਬੇਤਰਤੀਬੇ I/O ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ

ਬੇਤਰਤੀਬ I/O ਨੂੰ ਘਟਾਉਣ ਲਈ ਤੁਹਾਡੀ ਅਰਜ਼ੀ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਐਕਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕੈਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਵਿੱਚ ਨਿਸ਼ਾਨਾ, ਮਾਪਣਯੋਗ ਤਬਦੀਲੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਥੇ ਉਹ ਰਣਨੀਤੀਆਂ ਹਨ ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ:

1. ਅਗਰੈਸਿਵ ਪੁੱਛਗਿੱਛ ਬੈਚਿੰਗ ਨੂੰ ਲਾਗੂ ਕਰੋ। ਉਤਸੁਕ ਲੋਡਿੰਗ ਨਾਲ N+1 ਪੁੱਛਗਿੱਛ ਪੈਟਰਨਾਂ ਨੂੰ ਬਦਲੋ। ਜੇਕਰ ਤੁਹਾਡਾ ਡੈਸ਼ਬੋਰਡ 50 ਗਾਹਕਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀ ਹਾਲੀਆ ਗਤੀਵਿਧੀ ਨੂੰ ਲੋਡ ਕਰਦਾ ਹੈ, ਤਾਂ 50 ਵਿਅਕਤੀਗਤ ਖੋਜਾਂ ਦੀ ਬਜਾਏ WHERE customer_id IN (...) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸਵਾਲ ਵਿੱਚ ਸਾਰੇ 50 ਸਰਗਰਮੀ ਸੈੱਟ ਪ੍ਰਾਪਤ ਕਰੋ। ਇਹ ਇਕੱਲਾ ਸੂਚੀ ਦ੍ਰਿਸ਼ਾਂ 'ਤੇ ਬੇਤਰਤੀਬੇ I/O ਨੂੰ 80% ਤੱਕ ਘਟਾ ਸਕਦਾ ਹੈ।
2. ਕੰਪੋਜ਼ਿਟ ਇੰਡੈਕਸ ਦੀ ਰਣਨੀਤਕ ਤੌਰ 'ਤੇ ਵਰਤੋਂ ਕਰੋ। (tenant_id, status, created_at) 'ਤੇ ਇੱਕ ਸੰਯੁਕਤ ਸੂਚਕਾਂਕ ਡੇਟਾਬੇਸ ਨੂੰ ਵੱਖ-ਵੱਖ ਇੰਡੈਕਸਾਂ ਵਿੱਚ ਕਈ ਬੇਤਰਤੀਬ ਖੋਜਾਂ ਦੀ ਬਜਾਏ ਇੱਕ ਸਿੰਗਲ ਕ੍ਰਮਵਾਰ ਸੂਚਕਾਂਕ ਸਕੈਨ ਨਾਲ ਆਮ ਫਿਲਟਰ ਕੀਤੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦਿੰਦਾ ਹੈ।
3. ਬੁੱਧੀਮਾਨ ਅਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਨਾਲ ਇੱਕ ਕੈਸ਼ਿੰਗ ਲੇਅਰ ਪੇਸ਼ ਕਰੋ। ਕੈਸ਼ ਨੂੰ ਅਕਸਰ ਐਕਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਪਰ ਬਹੁਤ ਘੱਟ ਡਾਟਾ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ — ਉਪਭੋਗਤਾ ਅਨੁਮਤੀਆਂ, ਸੰਗਠਨ ਸੈਟਿੰਗਾਂ, ਮੋਡੀਊਲ ਸੰਰਚਨਾ — ਮੈਮੋਰੀ ਵਿੱਚ। Redis ਜਾਂ Memcached ਇਹਨਾਂ ਨੂੰ ਮਾਈਕ੍ਰੋਸਕਿੰਡਾਂ ਵਿੱਚ ਸੇਵਾ ਕਰ ਸਕਦੇ ਹਨ, ਪ੍ਰਤੀ ਮਿੰਟ ਹਜ਼ਾਰਾਂ ਬੇਤਰਤੀਬ ਰੀਡਜ਼ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹੋਏ।
4. ਪ੍ਰੀ-ਕੰਪਿਊਟ ਐਗਰੀਗੇਸ਼ਨ। ਹਰ ਡੈਸ਼ਬੋਰਡ ਲੋਡ 'ਤੇ ਮਹੀਨਾਵਾਰ ਆਮਦਨ ਜਾਂ ਹੈੱਡਕਾਉਂਟ ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਬਜਾਏ, ਇੱਕ ਅਨੁਸੂਚੀ 'ਤੇ ਐਗਰੀਗੇਸ਼ਨ ਜੌਬਾਂ ਚਲਾਓ ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰੋ। ਰੀਅਲ-ਟਾਈਮ ਬੇਤਰਤੀਬੇ I/O ਵਿੱਚ ਭਾਰੀ ਕਮੀ ਲਈ ਥੋੜ੍ਹੇ ਜਿਹੇ ਡੇਟਾ ਤਾਜ਼ਗੀ ਦਾ ਵਪਾਰ ਕਰੋ।
5. ਵੱਡੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਐਕਸੈਸ ਪੈਟਰਨ ਦੁਆਰਾ ਵੰਡੋ। ਜੇਕਰ 90% ਪੁੱਛਗਿੱਛਾਂ ਪਿਛਲੇ 30 ਦਿਨਾਂ ਦੇ ਡੇਟਾ ਨੂੰ ਛੂਹਦੀਆਂ ਹਨ, ਤਾਂ ਆਪਣੀ ਟੇਬਲ ਨੂੰ ਮਿਤੀ ਰੇਂਜ ਦੇ ਅਨੁਸਾਰ ਵੰਡੋ ਤਾਂ ਕਿ ਕਿਰਿਆਸ਼ੀਲ ਭਾਗ ਕੈਸ਼ ਵਿੱਚ ਗਰਮ ਰਹੇ ਜਦੋਂ ਕਿ ਇਤਿਹਾਸਕ ਡੇਟਾ ਸਸਤੀ ਸਟੋਰੇਜ 'ਤੇ ਠੰਡਾ ਰਹਿੰਦਾ ਹੈ।

ਇਹ ਵਿਦੇਸ਼ੀ ਤਕਨੀਕਾਂ ਨਹੀਂ ਹਨ। ਉਹ ਉਹੀ ਪੈਟਰਨ ਹਨ ਜੋ ਸੈਂਕੜੇ ਹਜ਼ਾਰਾਂ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੇ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਗੁੰਝਲਦਾਰ, ਮਲਟੀ-ਮੋਡਿਊਲ ਇੰਟਰਫੇਸਾਂ ਵਿੱਚ ਸਬ-ਸੈਕਿੰਡ ਜਵਾਬ ਸਮਾਂ ਬਰਕਰਾਰ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ Mewayz ਨੇ V2 ਲਈ ਆਪਣੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਇਆ — ਇੱਕ ਸਿੰਗਲ ਲਿੰਕ-ਇਨ-ਬਾਇਓ ਟੂਲ ਤੋਂ 138,000 ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੇ ਇੱਕ 207-ਮੋਡਿਊਲ ਬਿਜ਼ਨਸ OS ਤੱਕ ਸਕੇਲ ਕਰਨਾ — I/O ਪਹੁੰਚ ਪੈਟਰਨਾਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਖਰਚਿਆਂ ਨੂੰ ਅਨੁਪਾਤਕ ਤੌਰ 'ਤੇ ਗੁਣਾ ਕੀਤੇ ਬਿਨਾਂ ਉਸ ਵਿਸਤਾਰ ਨੂੰ ਵਿਹਾਰਕ ਬਣਾਉਣ ਲਈ ਬੁਨਿਆਦੀ ਸੀ।

ਉਪਭੋਗਤਾ ਅਨੁਭਵ ਅਤੇ ਧਾਰਨ 'ਤੇ ਮਿਸ਼ਰਤ ਪ੍ਰਭਾਵ

ਪ੍ਰਦਰਸ਼ਨ ਸਿਰਫ਼ ਇੱਕ ਬੈਕਐਂਡ ਚਿੰਤਾ ਨਹੀਂ ਹੈ - ਇਹ ਇੱਕ ਉਤਪਾਦ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ। Google ਦੀ ਖੋਜ ਨੇ ਲਗਾਤਾਰ ਦਿਖਾਇਆ ਹੈ ਕਿ 53% ਮੋਬਾਈਲ ਉਪਭੋਗਤਾ ਇੱਕ ਪੰਨੇ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ ਜਿਸ ਨੂੰ ਲੋਡ ਹੋਣ ਵਿੱਚ 3 ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਕਾਰੋਬਾਰੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਜਿੱਥੇ ਉਪਭੋਗਤਾ ਪ੍ਰਤੀ ਦਿਨ ਦਰਜਨਾਂ ਵਾਰ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ, ਸਹਿਣਸ਼ੀਲਤਾ ਹੋਰ ਵੀ ਘੱਟ ਹੈ। ਹਫਤਾਵਾਰੀ ਰਿਪੋਰਟਾਂ ਚਲਾਉਣ ਵਾਲਾ ਇੱਕ ਤਨਖਾਹ ਪ੍ਰਬੰਧਕ, ਬਿਨੈਕਾਰਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਵਾਲਾ ਇੱਕ HR ਲੀਡ, ਜਾਂ ਪਾਈਪਲਾਈਨ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਨ ਵਾਲਾ ਇੱਕ ਵਿਕਰੀ ਪ੍ਰਤੀਨਿਧੀ — ਇਹ ਉਪਭੋਗਤਾ ਗਤੀ ਦੀ ਇੱਕ ਅਨੁਭਵੀ ਭਾਵਨਾ ਵਿਕਸਿਤ ਕਰਦੇ ਹਨ। ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹ "ਇਨਵੌਇਸ ਐਗਰੀਗੇਸ਼ਨ ਪੁੱਛਗਿੱਛ 'ਤੇ ਬੇਤਰਤੀਬ I/O ਲੇਟੈਂਸੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ," ਪਰ ਉਹ ਕਹਿਣਗੇ "ਇਹ ਸੌਫਟਵੇਅਰ ਹੌਲੀ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ" ਅਤੇ ਵਿਕਲਪਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਣਗੇ।

ਕੰਪਾਊਂਡਿੰਗ ਪ੍ਰਭਾਵ ਮਾਪਣਯੋਗ ਹੈ। ਇੱਕ ਪਲੇਟਫਾਰਮ ਜੋ 2.4 ਸਕਿੰਟਾਂ ਦੀ ਬਜਾਏ 800ms ਵਿੱਚ ਡੈਸ਼ਬੋਰਡ ਲੋਡ ਕਰਦਾ ਹੈ, ਸਿਰਫ 3 ਗੁਣਾ ਤੇਜ਼ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰਦਾ - ਇਹ ਵਰਤੋਂ ਵਿਵਹਾਰ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਉਪਭੋਗਤਾ ਵਧੇਰੇ ਵਾਰ ਡੇਟਾ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ, ਹੋਰ ਮੋਡਿਊਲਾਂ ਦੀ ਪੜਚੋਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਟੂਲ ਨੂੰ ਉਹਨਾਂ ਦੇ ਵਰਕਫਲੋ ਵਿੱਚ ਹੋਰ ਡੂੰਘਾਈ ਨਾਲ ਜੋੜਦੇ ਹਨ। ਉੱਚ ਰੁਝੇਵਿਆਂ ਉੱਚ ਧਾਰਨਾ ਨੂੰ ਵਧਾਉਂਦੀਆਂ ਹਨ, ਜੋ ਜੀਵਨ ਭਰ ਦੇ ਉੱਚ ਮੁੱਲ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ। ਸਲੈਕ ਨੇ ਮਸ਼ਹੂਰ ਤੌਰ 'ਤੇ ਆਪਣੇ ਸ਼ੁਰੂਆਤੀ ਵਿਕਾਸ ਦੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸੇ ਨੂੰ ਜਨੂੰਨੀ ਪ੍ਰਦਰਸ਼ਨ ਅਨੁਕੂਲਤਾ ਨੂੰ ਮੰਨਿਆ, ਇਹ ਮੰਨਦੇ ਹੋਏ ਕਿ ਗਤੀ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਮੁਕਾਬਲੇ ਵਾਲੀ ਖਾਈ ਸੀ।

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

ਮਾਪਣਾ ਕੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ: ਬੇਤਰਤੀਬੇ I/O ਨੂੰ ਦ੍ਰਿਸ਼ਮਾਨ ਬਣਾਉਣਾ

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

• p95 ਅਤੇ p99 ਪੁੱਛਗਿੱਛ ਲੇਟੈਂਸੀ: ਔਸਤ ਲੇਟੈਂਸੀ ਦਰਦ ਨੂੰ ਲੁਕਾਉਂਦੀ ਹੈ। 95ਵਾਂ ਅਤੇ 99ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਹੌਲੀ — ਅਤੇ ਸਭ ਤੋਂ ਨਿਰਾਸ਼ — ਉਪਭੋਗਤਾ ਅਸਲ ਵਿੱਚ ਕੀ ਅਨੁਭਵ ਕਰਦੇ ਹਨ
• ਪੜ੍ਹਨ ਬਨਾਮ ਲਿਖੋ, ਕ੍ਰਮਵਾਰ ਬਨਾਮ ਬੇਤਰਤੀਬੇ ਦੁਆਰਾ IOPS ਬ੍ਰੇਕਡਾਊਨ: ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਤੁਹਾਡਾ ਕੰਮ ਦਾ ਬੋਝ I/O-ਬਾਉਂਡ ਹੈ ਅਤੇ ਕਿਸ ਕਿਸਮ ਦਾ I/O ਹਾਵੀ ਹੈ
• ਕੈਸ਼ ਹਿੱਟ ਅਨੁਪਾਤ: ਚੰਗੀ ਤਰ੍ਹਾਂ ਟਿਊਨਡ ਸਿਸਟਮ 'ਤੇ 95% ਤੋਂ ਘੱਟ ਅਨੁਪਾਤ ਡਾਟਾ ਐਕਸੈਸ ਪੈਟਰਨਾਂ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਜੋ ਮੈਮੋਰੀ ਤੋਂ ਨਹੀਂ ਦਿੱਤੇ ਜਾ ਰਹੇ ਹਨ
• ਪ੍ਰਤੀ ਪੰਨਾ ਲੋਡ ਪੁੱਛਗਿੱਛ ਦੀ ਗਿਣਤੀ: ਜੇਕਰ ਇੱਕ ਉਪਭੋਗਤਾ ਕਿਰਿਆ 20-30 ਤੋਂ ਵੱਧ ਡਾਟਾਬੇਸ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਚਾਲੂ ਕਰਦੀ ਹੈ, ਤਾਂ ਲਗਭਗ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇੱਕ ਅਨੁਕੂਲਤਾ ਮੌਕਾ ਹੈ

ਇਸ ਡੇਟਾ ਨਾਲ ਲੈਸ, ਟੀਮਾਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਬਜਾਏ ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵ ਵਾਲੇ ਅਨੁਕੂਲਨ ਨੂੰ ਤਰਜੀਹ ਦੇ ਸਕਦੀਆਂ ਹਨ। ਉਹ ਕਾਰੋਬਾਰ ਜੋ I/O ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਦੇ ਮੈਟ੍ਰਿਕ ਵਜੋਂ ਮੰਨਦੇ ਹਨ — ਅਪਟਾਈਮ, ਗਲਤੀ ਦਰਾਂ, ਅਤੇ ਉਪਭੋਗਤਾ ਸੰਤੁਸ਼ਟੀ ਦੇ ਨਾਲ — ਲਗਾਤਾਰ ਘੱਟ ਕੀਮਤ 'ਤੇ ਤੇਜ਼ ਉਤਪਾਦ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਇੱਕ ਮਾਰਕੀਟ ਵਿੱਚ ਜਿੱਥੇ ਉਪਭੋਗਤਾ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਵਪਾਰਕ ਟੂਲ ਉਪਭੋਗਤਾ ਐਪਸ ਦੇ ਰੂਪ ਵਿੱਚ ਜਵਾਬਦੇਹ ਹੋਣ, ਇਹ ਅਨੁਸ਼ਾਸਨ ਵਿਕਲਪਿਕ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਅੰਤਰ ਹੈ ਜੋ 138,000 ਉਪਭੋਗਤਾਵਾਂ ਤੱਕ ਸੁੰਦਰਤਾ ਨਾਲ ਸਕੇਲ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਜੋ ਆਪਣੀ ਖੁਦ ਦੀ ਗੁੰਝਲਤਾ ਦੇ ਅਧੀਨ ਹੈ।