ਇੰਜੀਨੀਅਰਿੰਗ

ਇੰਜੀਨੀਅਰਿੰਗ

Mythex ਕਿਵੇਂ ਬਣਦਾ ਅਤੇ ਚੱਲਦਾ ਹੈ, ਇਹ ਵੀ ਕਿ ਕੀ ਟੁੱਟਿਆ ਅਤੇ ਅਸੀਂ ਉਸਨੂੰ ਕਿਵੇਂ ਠੀਕ ਕੀਤਾ।

• ਅਸਫ਼ਲ ਰੀਪਬਲਿਸ਼ ਕਦੇ ਵੀ ਕੰਮ ਕਰਦੇ ਬੈਕਐਂਡ ਨੂੰ ਨਹੀਂ ਮਿਟਾਉਂਦਾ — ਅਸਫ਼ਲ ਰੀਪਬਲਿਸ਼ ਕਿਸੇ ਐਪ ਦੀ ਲਾਈਵ API ਮਿਟਾ ਸਕਦਾ ਸੀ, ਜਾਂ ਉਸਦਾ ਟੁੱਟਿਆ ਨਵਾਂ ਵਰਜਨ ਚਾਲੂ ਛੱਡ ਸਕਦਾ ਸੀ। Mythex ਇੱਕ ਗਲਤ ਪਬਲਿਸ਼ ਨੂੰ ਕਿਵੇਂ ਉਲਟਾਉਂਦਾ ਹੈ, ਉਸ ਦੇ ਤਿੰਨ ਸੁਧਾਰ।
• ਅਲਰਟ ਜੋ ਹਰ ਸਰਵਰ ਲਈ ਨਹੀਂ, ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਚੱਲਣ — ਰੋਜ਼ਾਨਾ ਇੱਕ ਵਾਰ ਆਉਣ ਵਾਲਾ ਅਲਰਟ ਇੱਕ ਦੁਪਹਿਰ ਵਿੱਚ ਪੰਜ ਵਾਰ ਆਇਆ। ਦੋ ਸਰਵਰਾਂ ਅਤੇ ਡਿਪਲੌਏ ਨਾਲ ਮੈਮੋਰੀ ਡੀਡੁਪ ਕਿਉਂ ਟੁੱਟਦਾ ਹੈ, ਅਤੇ ਸਾਂਝੇ ਸਟੋਰ ਨੇ ਇਸਨੂੰ ਕਿਵੇਂ ਠੀਕ ਕੀਤਾ।
• ਬਿਨਾਂ ਕਿਸੇ ਨੂੰ ਉਡੀਕ ਕਰਵਾਏ ਵੱਡੇ ਵਰਕਸਪੇਸ ਵੱਲ ਜਾਣਾ — 2 GB ਵੱਲ ਜਾਣ ਤੋਂ ਬਾਅਦ ਸਾਡੇ ਇੱਕ ਚੌਥਾਈ ਵਰਕਸਪੇਸ 1 GB 'ਤੇ ਅਟਕੇ ਰਹੇ। ਸਾਡੇ ਪਹਿਲੇ ਫ਼ਿਕਸ ਨੇ ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ ਸੱਤ ਮਿੰਟ ਉਡੀਕ ਕਰਵਾਈ। ਅਸੀਂ ਕੀ ਬਦਲਿਆ, ਅਤੇ ਦੁਬਾਰਾ ਕੀ ਬਦਲਿਆ।
• ਡੇਟਾਬੇਸ ਦੀ ਬਿਲਿੰਗ ਉਸ ਦੇ ਅਸਲ ਵਰਤੋਂ ਅਨੁਸਾਰ — ਅਸੀਂ ਹਰ ਐਪ ਦੇ ਡੇਟਾਬੇਸ ਦੀ ਲਾਗਤ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਂਦੇ ਸੀ, ਅਤੇ ਉਹ ਅੰਦਾਜ਼ਾ ਦੋਹਾਂ ਪਾਸੇ ਗਲਤ ਸੀ। ਹੁਣ ਹਰ ਡੇਟਾਬੇਸ ਮਾਪੀ ਵਰਤੋਂ ਤੋਂ, ਘੰਟਾ-ਦਰ-ਘੰਟਾ ਬਿਲ ਹੁੰਦਾ ਹੈ।
• ਪਬਲਿਸ਼ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਕਰੈਸ਼ ਹੋਣ ਵਾਲੀਆਂ ਐਪਾਂ ਨੂੰ ਫੜਨਾ — ਤਿੰਨ ਪਬਲਿਸ਼ ਸਾਡੇ ਹੈਲਥ ਚੈੱਕ ਵਿੱਚੋਂ ਲੰਘ ਗਏ, ਜਦਕਿ ਹਰ ਬੂਟ 'ਤੇ ਉਹਨਾਂ ਦੀ API ਕੁਝ ਸਕਿੰਟਾਂ ਬਾਅਦ ਕਰੈਸ਼ ਹੋ ਰਹੀ ਸੀ। ਕਾਰਨ: ਪੰਜ ਐਂਟਰੀਆਂ ਦੀ ਸੀਮਾ ਵਾਲੀ ਸੂਚੀ ਵਿੱਚ ਕਰੈਸ਼ ਗਿਣਨਾ।
• ਤਸਵੀਰਾਂ ਨਾਲ ਭਰੇ ਏਜੰਟ ਟਰਨਾਂ ਨੂੰ ਮੈਮਰੀ ਵਿੱਚ ਰੱਖਣਾ — ਏਜੰਟ ਟਰਨ ਕੈਟਾਲਾਗ ਸਕੈਨਾਂ ਨਾਲ 952 MB 'ਤੇ ਮੈਮਰੀ ਤੋਂ ਬਾਹਰ ਹੋਇਆ। ਤਿੰਨ ਵੱਖਰੇ ਕਾਰਨ ਸਨ, ਅਤੇ ਅਸੀਂ ਹਰ ਇੱਕ ਠੀਕ ਕੀਤਾ।
• ਲੰਮੇ ਏਜੰਟ ਟਰਨਾਂ ਨੂੰ ਕੰਟੈਕਸਟ ਵਿੰਡੋ ਦੇ ਅੰਦਰ ਰੱਖਣਾ — ਸਬ-ਏਜੰਟ ਵੱਡੇ ਹੋ ਕੇ ਰੱਦ ਹੁੰਦੇ ਸਨ, ਜਲਦੀ ਰੁਕਦੇ ਸਨ, ਜਾਂ ਰੂਸੀ ਟੋਕਨ ਗਲਤ ਗਿਣਦੇ ਸਨ। ਤਿੰਨ ਹੱਲ ਜੋ ਲੰਮੇ AI ਕੰਮ ਨੂੰ ਮੁਕੰਮਲ ਹੋਣ ਦਿੰਦੇ ਹਨ।
• ਫ਼ੋਨ ਸੌਂਣ 'ਤੇ ਵੀ ਚੈਟ ਚਾਲੂ ਰੱਖਣਾ — ਫ਼ੋਨ ਸੌਂਦੇ ਹਨ ਅਤੇ ਨੈੱਟਵਰਕ ਬਦਲਦੇ ਹਨ। ਦੋ ਬੱਗਾਂ ਕਰਕੇ Mythex ਦੀ ਚੈਟ ਅਟਕਦੀ ਸੀ ਜਾਂ ਅੱਧਾ ਜਵਾਬ ਦਿਖਾਉਂਦੀ ਸੀ। ਦੋਵੇਂ ਠੀਕ ਕੀਤੇ।
• ਇੱਕ ਭਾਰੀ ਚੈਟ ਸਾਡੀ API ਨੂੰ ਕਿਵੇਂ ਬੰਦ ਕਰ ਸਕਦੀ ਸੀ — 28 ਸਤੰਬਰ ਨੂੰ ਸਾਡੇ ਦੋਵੇਂ API ਸਰਵਰ ਇਕੱਠੇ ਮੈਮਰੀ ਤੋਂ ਬਾਹਰ ਹੋ ਗਏ। ਪਹਿਲਾ ਹੱਲ ਵੱਧ ਮੈਮਰੀ ਸੀ; ਅਸਲ ਹੱਲ ਚੈਟ ਇਤਿਹਾਸ ਨੂੰ ਗਿਣਤੀ ਨਾਲ ਨਹੀਂ, ਆਕਾਰ ਨਾਲ ਲੋਡ ਕਰਨਾ ਸੀ।
• ਹੁਣ Publish ਦੋ ਵਾਰ ਦਬਾਉਣ 'ਤੇ ਵੀ ਇੱਕ ਹੀ ਵਾਰ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ — ਇੱਕ ਐਪ ਲਈ ਤਿੰਨ ਪ੍ਰਕਾਸ਼ਨ 84 ms ਦੇ ਫਰਕ ਨਾਲ ਪਹੁੰਚੇ ਅਤੇ ਹਰ ਇੱਕ ਨੇ ਪੂਰਾ ਡਿਪਲੌਇ ਚਲਾਇਆ। ਹੁਣ ਡੇਟਾਬੇਸ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੇ।
• ਆਪਣੀ ਸਾਈਟ ਠੀਕ ਕਰਨ ਤੋਂ ਸਿੱਖੇ SEO ਸਬਕ — ਡੁਪਲੀਕੇਟ FAQ ਮਾਰਕਅੱਪ, Google ਵਿੱਚ ਗ਼ਲਤ ਥੰਬਨੇਲ, ਟੈਮਪਲੇਟ ਪੰਨੇ ਜਿਨ੍ਹਾਂ ’ਤੇ ਕੋਈ ਕਲਿੱਕ ਨਹੀਂ ਸੀ, ਅਤੇ ਇੱਕ ਰਸਤਾ ਜਿਸਨੂੰ ਸਾਡੀ ਐਜ ਰੱਦ ਕਰਦੀ ਸੀ। mythex.ai ’ਤੇ ਜੋ ਮਿਲਿਆ ਅਤੇ ਜੋ ਠੀਕ ਕੀਤਾ।
• ਸਟੈਟਿਕ ਸਾਈਟਾਂ ਹੁਣ ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦਿਆਂ ਵੀ ਚਾਲੂ ਰਹਿੰਦੀਆਂ ਹਨ — ਸਟੈਟਿਕ ਸਾਈਟ ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਵੇਲੇ ਪੁਰਾਣੀ ਸਾਈਟ ਨਵੀਂ ਦੇ ਆਉਣ ਤੱਕ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਬਦਲਾਅ ਸਕਿੰਟਾਂ ਵਿੱਚ ਦਿਸਦੇ ਹਨ।
• ਪ੍ਰੋਗਰੈਸ ਲੇਬਲ ਵਿੱਚ ਲੁਕੀ ਮੈਮੋਰੀ ਖਤਮ ਹੋਣ ਦੀ ਗੜਬੜ — ਸਾਡਾ AI ਏਜੰਟ ਇੱਕ ਵੱਡੀ ਫਾਈਲ ਲਿਖਦੇ ਸਮੇਂ ਮੈਮੋਰੀ ਖਤਮ ਹੋ ਗਿਆ। ਕਾਰਨ ਮਾਡਲ ਜਾਂ ਸਮਾਨਾਂਤਰ ਸਬ-ਏਜੰਟ ਨਹੀਂ ਸੀ, ਸਗੋਂ ਇੱਕ ਸਟੇਟਸ ਲੇਬਲ ਸੀ ਜੋ 41,000 ਵਾਰ ਭੇਜਿਆ ਗਿਆ।
• ਗੁੰਮ ਸਵੈਪ ਫਾਈਲ ਜਿਸਨੇ ਸਾਡੇ ਸਰਵਰ ਜਮਾ ਦਿੱਤੇ — ਪ੍ਰੋਡਕਸ਼ਨ ਸਰਵਰ ਕ੍ਰੈਸ਼ ਹੋਏ ਬਿਨਾਂ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਗਿਆ: ਬਿਨਾਂ ਸਵੈਪ ਵਾਲੀ ਮਸ਼ੀਨ ’ਤੇ ਪੇਜ-ਕੈਸ਼ ਥ੍ਰੈਸ਼ਿੰਗ। ਕੀ ਹੋਇਆ ਅਤੇ ਅਸੀਂ ਕੀ ਬਦਲਿਆ।
• ਡੇਟਾਬੇਸ ਜਗਾਉਣਾ, ਮਰੇ ਹੋਏ ਕਨੈਕਸ਼ਨਾਂ ਤੋਂ ਬਿਨਾਂ — ਸੌਂ ਕੇ ਜਾਗਦੀ ਪ੍ਰਕਾਸ਼ਿਤ ਐਪ ਦੀ ਪਹਿਲੀ ਬੇਨਤੀ ਉਹਨਾਂ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨਾਂ ’ਤੇ 10–12 ਸਕਿੰਟ ਅਟਕੀ ਰਹੀ ਜੋ ਸੌਂਦੇ ਸਮੇਂ ਮਰ ਚੁੱਕੇ ਸਨ। ਅਸੀਂ ਇਸਨੂੰ 2.3 ਸਕਿੰਟ ਤੱਕ ਕਿਵੇਂ ਲਿਆਂਦਾ।
• ਅਸੀਂ ਆਪਣੀਆਂ ਹੀ ਸੇਵਾਵਾਂ ਨੂੰ ਰੇਟ-ਲਿਮਿਟ ਕਰ ਰਹੇ ਸੀ — ਸਾਡੀ API ਦੀ ਪ੍ਰਤੀ-ਪਤਾ ਰੇਟ ਲਿਮਿਟ ਸਾਡੀਆਂ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਇੱਕ ਵਿਅਸਤ ਵਿਅਕਤੀ ਵਾਂਗ ਸਮਝਦੀ ਸੀ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ 429 ਮਿਲਣ ਲੱਗੇ। ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਲੱਭਿਆ ਅਤੇ ਠੀਕ ਕੀਤਾ।
• ਅਸੀਂ Mythex ਦੇ ਸਰਵਰ ARM ’ਤੇ ਕਿਉਂ ਲਿਜਾਏ — ਭਾਰੀ ਕੰਮ ਪ੍ਰੋਜੈਕਟ-ਸੈਂਡਬੌਕਸਾਂ ਵਿੱਚ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਸਾਡੇ ਸਰਵਰ ਆਪਣੀ ਮੈਮੋਰੀ ਦਾ ਲਗਭਗ ਇੱਕ ਤਿਹਾਈ ਵਰਤ ਰਹੇ ਸਨ। ਛੋਟੀਆਂ ARM ਮਸ਼ੀਨਾਂ ਨੇ ਲਾਗਤ ਲਗਭਗ 30% ਘਟਾਈ। ਕਿਵੇਂ।
• ਡਿਪਲਾਇ ਨੂੰ ਜ਼ੀਰੋ 502 ਗਲਤੀਆਂ ਤੱਕ ਕਿਵੇਂ ਲਿਆਂਦਾ — ਸਾਡੇ ਡਿਪਲਾਇਆਂ ਨਾਲ ਲੜਨ ਵਾਲਾ ਵਾਚਡੌਗ ਅਤੇ ਬਹੁਤ ਦੇਰ ਨਾਲ ਨੋਟਿਸ ਕਰਨ ਵਾਲਾ ਲੋਡ ਬੈਲੈਂਸਰ: ਅਸੀਂ ਦੋਵੇਂ ਕਿਵੇਂ ਲੱਭੇ, ਠੀਕ ਕੀਤੇ, ਅਤੇ ਡਿਪਲਾਇ 10 502 ਤੋਂ ਜ਼ੀਰੋ ਤੱਕ ਮਾਪੇ।