ಎಂಜಿನಿಯರಿಂಗ್

ಎಂಜಿನಿಯರಿಂಗ್

Mythex ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಿ ನಡೆಸಲಾಗುತ್ತದೆ, ಏನು ಮುರಿದುಹೋಯಿತು ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸಿದೆವು ಎಂಬುದೂ ಸೇರಿದಂತೆ.

• ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ವಿಫಲ ರಿಪಬ್ಲಿಶ್ ಎಂದಿಗೂ ಅಳಿಸುವುದಿಲ್ಲ — ವಿಫಲ ರಿಪಬ್ಲಿಶ್ ಆ್ಯಪ್‌ನ ಲೈವ್ API ಅನ್ನು ಅಳಿಸಬಹುದಿತ್ತು, ಅಥವಾ ತಪ್ಪಾದ ಆವೃತ್ತಿಯನ್ನು ಓಡಿಸಬಹುದಿತ್ತು. ವಿಫಲ ಪ್ರಕಟಣೆಯನ್ನು Mythex ಹೇಗೆ ರದ್ದುಗೊಳಿಸುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಮೂರು ಸುಧಾರಣೆಗಳು.
• ಒಂದು ಬಾರಿ ಮಾತ್ರ ಹೋಗುವ ಎಚ್ಚರಿಕೆಗಳು, ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ಒಂದೊಂದಲ್ಲ — ದಿನಕ್ಕೊಮ್ಮೆ ಹೋಗಬೇಕಿದ್ದ ಎಚ್ಚರಿಕೆ ಒಂದು ಮಧ್ಯಾಹ್ನ ಐದು ಬಾರಿ ಬಂತು. ಎರಡು ಸರ್ವರ್ ಮತ್ತು ಡಿಪ್ಲಾಯ್‌ಗಳಲ್ಲಿ ಮೆಮೊರಿ ಡಿಡ್ಡ್ಯೂಪ್ ಏಕೆ ಮುರಿಯುತ್ತದೆ, ಮತ್ತು ಹಂಚಿಕೆಯ ಸ್ಟೋರ್ ಅದನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸಿತು.
• ದೊಡ್ಡ ವರ್ಕ್‌ಸ್ಪೇಸ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸುವುದು, ಯಾರನ್ನೂ ಕಾಯಿಸದೆ — ಕಾಲು ಭಾಗ ವರ್ಕ್‌ಸ್ಪೇಸ್‌ಗಳು 2 GB ಗೆ ಬದಲಾದ ನಂತರವೂ 1 GB ನಲ್ಲೇ ಉಳಿದಿದ್ದವು. ನಮ್ಮ ಮೊದಲ ಪರಿಹಾರ ಒಬ್ಬರನ್ನು ಏಳು ನಿಮಿಷ ಕಾಯಿಸಿತು. ನಾವು ಬದಲಿಸಿದ್ದು ಮತ್ತು ಮತ್ತೆ ಬದಲಿಸಿದ್ದು.
• ಬಿಲ್ಲಿಂಗ್ ಡೇಟಾಬೇಸ್‌ಗಳು: ಅವು ನಿಜವಾಗಿ ಬಳಸುವುದರ ಆಧಾರದ ಮೇಲೆ — ಡೇಟಾಬೇಸ್ ವೆಚ್ಚವನ್ನು ನಾವು ಅಂದಾಜು ಮಾಡುತ್ತಿದ್ದೆವು, ಮತ್ತು ಅದು ಎರಡೂ ಕಡೆ ತಪ್ಪಾಗಿತ್ತು. ಈಗ ಪ್ರತಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿಜವಾದ ಬಳಕೆಯಿಂದ, ಗಂಟೆಗಂಟೆಗೆ ಬಿಲ್ ಮಾಡಲಾಗುತ್ತದೆ.
• ಪ್ರಕಟಿಸಿದ ತಕ್ಷಣ ಕ್ರ್ಯಾಶ್ ಆಗುವ ಆ್ಯಪ್‌ಗಳನ್ನು ಹಿಡಿಯುವುದು — ಮೂರು ಪ್ರಕಟಣೆಗಳು ಆರೋಗ್ಯ ಪರಿಶೀಲನೆ ಪಾಸಾದವು, ಆದರೆ ಅವುಗಳ API ಪ್ರತಿ ಬೂಟ್‌ನಲ್ಲಿ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತಿತ್ತು. ಕಾರಣ: ಐದು ನಮೂದುಗಳ ಪಟ್ಟಿಯಲ್ಲಿ ಕ್ರ್ಯಾಶ್‌ಗಳನ್ನು ಎಣಿಸಿದ್ದು.
• ಚಿತ್ರ-ಭಾರಿ ಏಜೆಂಟ್ ಸುತ್ತುಗಳನ್ನು ಮೆಮೊರಿಯೊಳಗೆ ಇಡುವುದು — ಕ್ಯಾಟಲಾಗ್ ಚಿತ್ರಗಳನ್ನು ನೋಡುತ್ತಿದ್ದ ಏಜೆಂಟ್ ಸುತ್ತು 952 MB ನಲ್ಲಿ ಮೆಮೊರಿ ಖಾಲಿಯಾಯಿತು. ಮೂರು ಕಾರಣಗಳು ಮತ್ತು ಅವುಗಳ ಸರಿಪಡಿಕೆ.
• ದೀರ್ಘ ಏಜೆಂಟ್ ಸುತ್ತುಗಳನ್ನು ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋದೊಳಗೆ ಇಡುವುದು — ಉಪ-ಏಜೆಂಟ್‌ಗಳು ಮಾದರಿ ನಿರಾಕರಿಸುವವರೆಗೆ ಬೆಳೆದವು, ಜಾಗ ಉಳಿಸಲು ಬೇಗ ನಿಂತವು, ರಷ್ಯನ್ ಟೋಕನ್‌ಗಳನ್ನು ತಪ್ಪಾಗಿ ಎಣಿಸಿದವು. ಮೂರು ಸರಿಪಡಿಕೆಗಳು.
• ಫೋನ್ ನಿದ್ರೆಗೆ ಹೋದಾಗ ಚಾಟ್ ಜೀವಂತವಾಗಿಡುವುದು — ಫೋನ್ ನಿದ್ರಿಸಿದಾಗ ಚಾಟ್ ಸ್ಥಗಿತಗೊಂಡಿತು ಅಥವಾ ಅರ್ಧ ಉತ್ತರ ತೋರಿಸಿತು. ಎರಡು ದೋಷಗಳನ್ನು ಹೇಗೆ ಕಂಡುಕೊಂಡು ಸರಿಪಡಿಸಿದೆವು.
• ಒಂದು ಭಾರಿ ಚಾಟ್ ನಮ್ಮ API ಅನ್ನು ಹೇಗೆ ನಿಲ್ಲಿಸಬಹುದಿತ್ತು — ಸೆಪ್ಟೆಂಬರ್ 28 ರಂದು ನಮ್ಮ ಎರಡೂ API ಸರ್ವರ್‌ಗಳು ಒಟ್ಟಿಗೇ ಮೆಮೊರಿ ಖಾಲಿಯಾದವು. ಮೊದಲ ಪರಿಹಾರ ಹೆಚ್ಚು ಮೆಮೊರಿ; ನಿಜವಾದ ಪರಿಹಾರ ಚಾಟ್ ಇತಿಹಾಸವನ್ನು ಸಂಖ್ಯೆಯಿಂದಲ್ಲ, ಗಾತ್ರದ ಆಧಾರದ ಮೇಲೆ ಲೋಡ್ ಮಾಡುವುದು.
• Publish ಎರಡು ಬಾರಿ ಒತ್ತಿದರೆ ಈಗ ಒಮ್ಮೆ ಮಾತ್ರ ಪ್ರಕಟವಾಗುತ್ತದೆ — ಒಂದೇ ಆ್ಯಪ್‌ಗೆ ಮೂರು ಪ್ರಕಟಣೆಗಳು 84ms ಅಂತರದಲ್ಲಿ ಬಂದು ಮೂರೂ ಡೆಪ್ಲಾಯ್ ನಡೆಸಿದವು. ಡೇಟಾಬೇಸ್ ಯಾರು ಪ್ರಕಟಿಸಬೇಕೆಂದು ನಿರ್ಧರಿಸುವ ಬಗೆ ಮತ್ತು ಉಳಿದವರಿಗೆ ಸತ್ಯ ಹೇಳುವ ಬಗೆ.
• ನಮ್ಮದೇ ಸೈಟ್ ಸರಿಪಡಿಸಿದ್ದರಿಂದ ಕಲಿತ SEO ಪಾಠಗಳು — ನಕಲಿ FAQ ಮಾರ್ಕಪ್, Google ನಲ್ಲಿ ತಪ್ಪು ಥಂಬ್‌ನೇಲ್, ಯಾರೂ ಕ್ಲಿಕ್ ಮಾಡದ ಟೆಂಪ್ಲೇಟ್ ಪುಟಗಳು ಮತ್ತು ನಮ್ಮ ಎಡ್ಜ್ ತಿರಸ್ಕರಿಸಿದ ಒಂದು ಮಾರ್ಗ: mythex.ai ನಲ್ಲಿ ನಾವು ಕಂಡುಕೊಂಡು ಸರಿಪಡಿಸಿದ್ದು.
• ಸ್ಟ್ಯಾಟಿಕ್ ಸೈಟ್‌ಗಳು ಮರು-ಪ್ರಕಟಣೆಯ ವೇಳೆಯೂ ಚಾಲ್ತಿಯಲ್ಲಿರುತ್ತವೆ — ಸ್ಟ್ಯಾಟಿಕ್ ಸೈಟ್ ಮರು-ಪ್ರಕಟಿಸಿದಾಗ ಹೊಸ ಬಿಲ್ಡ್ ಸಿದ್ಧವಾಗುವವರೆಗೆ ಹಳೆಯ ಸೈಟ್ ಕಾಣಿಸುತ್ತದೆ, ಬದಲಾವಣೆಗಳು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ತೋರಿಸುತ್ತವೆ.
• ಪ್ರಗತಿ ಲೇಬಲ್‌ನಲ್ಲಿ ಅಡಗಿದ್ದ ಔಟ್-ಆಫ್-ಮೆಮೊರಿ ಕ್ರ್ಯಾಶ್ — ನಮ್ಮ AI ಏಜೆಂಟ್ ಒಂದು ದೊಡ್ಡ ಫೈಲ್ ಬರೆಯುತ್ತಿದ್ದಾಗ ಮೆಮೊರಿ ಖಾಲಿಯಾಯಿತು. ಕಾರಣ ಮಾಡೆಲ್ ಅಥವಾ ಸಮಾನಾಂತರ ಸಬ್-ಏಜೆಂಟ್‌ಗಳಲ್ಲ — 41,000 ಬಾರಿ ಕಳುಹಿಸಲಾದ ಸ್ಥಿತಿ ಲೇಬಲ್ ಆಗಿತ್ತು.
• ನಮ್ಮ ಸರ್ವರ್‌ಗಳನ್ನು ಹೆಪ್ಪುಗಟ್ಟಿಸಿದ ಕಾಣೆಯಾಗಿದ್ದ ಸ್ವಾಪ್ ಫೈಲ್ — ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗದೆಯೇ ಉತ್ತರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿತು — ಸ್ವಾಪ್ ಇಲ್ಲದ ಯಂತ್ರದಲ್ಲಿ ಪೇಜ್-ಕ್ಯಾಶ್ ಥ್ರ್ಯಾಶಿಂಗ್ ಆಗಿತ್ತು. ಏನಾಯಿತು ಮತ್ತು ನಾವು ಏನನ್ನು ಬದಲಿಸಿದೆವು.
• ಡೆಡ್ ಕನೆಕ್ಷನ್‌ಗಳಿಲ್ಲದೆ ಡೇಟಾಬೇಸ್‌ಗಳನ್ನು ಎಚ್ಚರಗೊಳಿಸುವುದು — ನಿದ್ರೆಯಿಂದ ಎಚ್ಚರಗೊಳ್ಳುವ ಆ್ಯಪ್ ಸತ್ತ ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್‌ಗಳ ಮೇಲೆ 10–12 ಸೆಕೆಂಡ್ ಹಿಡಿದಿಡುತ್ತಿತ್ತು. ಅದನ್ನು 2.3 ಸೆಕೆಂಡ್‌ಗೆ ಹೇಗೆ ಇಳಿಸಿದೆವು ಎಂಬುದು ಇಲ್ಲಿದೆ.
• ನಾವೇ ನಮ್ಮ ಸ್ವಂತ ಸೇವೆಗಳ ರೇಟ್ ಅನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತಿದ್ದೆವು — ನಮ್ಮ API ಯ ಪ್ರತಿ-ವಿಳಾಸದ ಮಿತಿ ನಮ್ಮ ಸ್ವಂತ ಸೇವೆಗಳನ್ನು ನಿರಾಕರಿಸಿತು, ಅವು 429 ಪಡೆಯಲಾರಂಭಿಸಿದವು. ಅದನ್ನು ಹೇಗೆ ಕಂಡುಹಿಡಿದು ಸರಿಪಡಿಸಿದೆವು.
• Mythex ನ ಸರ್ವರ್‌ಗಳನ್ನು ARM ಗೆ ಏಕೆ ಸ್ಥಳಾಂತರಿಸಿದೆವು — ಕೆಲಸ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗಳಿಗೆ ಸ್ಥಳಾಂತರಗೊಂಡ ನಂತರ ನಮ್ಮ ಸರ್ವರ್‌ಗಳು ಮೆಮೊರಿಯ ಮೂರನೇ ಒಂದು ಭಾಗ ಬಳಸುತ್ತಿದ್ದವು. ಚಿಕ್ಕ ARM ಇನ್‌ಸ್ಟೆನ್ಸ್‌ಗಳು ವೆಚ್ಚವನ್ನು ಸುಮಾರು 30% ಕಡಿಮೆ ಮಾಡಿದವು.
• ಡಿಪ್ಲಾಯ್‌ಗಳನ್ನು ಶೂನ್ಯ 502 ದೋಷಗಳಿಗೆ ಹೇಗೆ ಇಳಿಸಿದೆವು — ಡಿಪ್ಲಾಯ್‌ಗಳ ಜೊತೆ ಓಡಿದ ವಾಚ್‌ಡಾಗ್ ಮತ್ತು ತಡವಾಗಿ ಗಮನಿಸಿದ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್: ಇವೆರಡನ್ನೂ ಸರಿಪಡಿಸಿ, ಡಿಪ್ಲಾಯ್‌ಗಳನ್ನು 10 ರಿಂದ ಶೂನ್ಯ 502 ಗಳಿಗೆ ಇಳಿಸಿದ ಬಗೆ.