Инженерство

Инженерство

Как е изграден и как работи Mythex, включително какво се счупи и как го поправихме.

• Неуспешно повторно публикуване никога не изтрива работещ бекенд — Неуспешно повторно публикуване можеше да изтрие живото API на приложение. Три корекции в начина, по който Mythex отменя публикация, която се е провалила.
• Сигнали, които се задействат веднъж, а не веднъж на всеки сървър — Сигнал, който трябва да стига до нас веднъж на ден, дойде пет пъти за един следобед. Как споделеното състояние поправи дедупликацията при няколко сървъра.
• Преминаване към по-големи работни пространства без чакане за никого — Една четвърт от работните пространства останаха на 1 GB след преминаването към 2 GB. Първата корекция накара човек да чака седем минути. Какво променихме.
• Таксуване на базите данни според това, което наистина се използва — Преди оценявахме разхода за база данни на всяко приложение, а оценката грешеше в двете посоки. Сега всяка база се таксува според измерено използване, час по час.
• Улавяне на приложения, които се срутват веднага след публикуване — Три публикации минаха проверката, докато API-то им се срутваше при всеки старт. Причината: броене на сривове в списък с пет записа.
• Агентски ходове с много изображения, които се побират в паметта — Един агентски ход, който гледаше сканирания на каталог, изчерпа паметта при 952 MB. Три отделни причини, всяка държеше изображенията твърде дълго, и как ги оправихме.
• Дългите агентски ходове в рамките на контекстния прозорец — Подагентите растяха, докато моделът ги отхвърли, спираха рано, за да спестят място, или грешно броеха токените на руски. Три поправки, които завършват дългата работа.
• Чатът остава жив, когато телефонът заспи — Телефоните заспиват, сменят табове и губят мрежа. Два бъга караха чата на Mythex да засяда или да показва половин отговор. Как ги намерихме и поправихме.
• Как един тежък чат можеше да свали нашето API — На 28 септември и двата API сървъра изчерпаха паметта си едновременно. Първата поправка беше повече памет; истинската — зареждане на историята по размер.
• Натискането на Publish два пъти вече публикува веднъж — Три заявки за публикуване на едно приложение пристигнаха на 84 ms една от друга и стартираха три деплоя. Как базата данни решава кой публикува.
• Уроци за SEO от поправката на собствения ни сайт — Дублирана FAQ разметка, грешна миниатюра в Google, страници с шаблони без кликвания и път, който edge-ът ни отхвърляше. Какво открихме и поправихме.
• Статичните сайтове вече остават онлайн, докато се публикуват наново — Преиздаването на статичен сайт преди изпразваше live файловете, преди да качи новия билд. Сега старият сайт работи, докато новият е на място, и промените се виждат за секунди.
• Грешката с липсваща памет, скрита в етикет за напредък — Агентът ни изчерпа паметта, докато записваше голям файл. Причината не беше моделът или паралелните подагенти, а етикет за статус, изпратен 41 000 пъти.
• Липсващият swap файл, който замрази сървърите ни — Производствен сървър спря да отговаря, без да се срине — без убиване заради памет, само page-cache thrashing на машина без swap. Какво се случи и какво променихме.
• Събуждане на бази данни без мъртви връзки — Публикувано приложение, което се събуждаше от сън, държеше първата си заявка 10–12 секунди върху връзки към базата, умрели докато спеше. Как стигнахме до 2,3 секунди.
• Ограничавахме собствените си услуги — Пер-адресният лимит на нашия API третираше собствените ни услуги като един зает човек и в продукцията те започнаха да получават 429. Как го открихме и поправихме.
• Защо преместихме сървърите на Mythex на ARM — След като тежката работа се премести в изолирани среди, сървърите ни ползваха една трета от паметта си. По-малките ARM инстанции намалиха разходите с около 30%.
• Как стигнахме до нула 502 грешки при деплойте — Watchdog, който се състезаваше с деплойте, и балансьор, който забелязваше твърде късно: как открихме и двете, поправихме ги и измерихме деплойте от 10 502 до нула.