Блог Lead JS-разработчика
Автор: @bekharsky
По рекламе: https://telepost.pro/ch/id2415 или https://t.me/it_adv
Чат: https://t.me/htmlshitchat
№5001017849, https://www.gosuslugi.ru/snet/679b74f8dad2d930d2eaa978
Post #3504
2.72K

#такое дня
Тринадцать лет назад я работал в горнодобывающей/камнеобрабатывающей компании и пилил всякие инхаус-проекты: от учёта блоков, добытых на карьере, до их продажи, каталогизации, распиловки. Вплоть до визуального конструктора надгробий (на котором тщетно пытался сделать бизнес, но сегодня не о нём).
И вот сегодня в девять утра позвонил бывший коллега. С проблемой 🫠
Итак: не грузятся продажи больше, чем за пару дней. Сервер выбивает в пятисотую.
Начал диагностику и понял, что падает по памяти. Причём, не потому что много продаж, а потому что может быть много блоков в продаже.
Ну а памяти-то там кот наплакал. Как крутилось на шаред-хостинге со 128 мегабайтами памяти на PHP 5.3, так и крутится.
Как оказалось, я образца 2012 года, для подсчёта продаж просто грузил в памяти вообще все блоки, а потом их уже фильтровал и считал объёмы.
Казалось бы, какая фигня, скажете вы, ну сколько там тех блоков?
Ну так-то за 13 лет добыли почти 24000 блоков и совершили несколько тысяч продаж. А каждый блок — специфика работы — должен был сохранять историю изменений, распилов, расколов и так далее... Ревизии, короче. Это довольно ощутимый объём данных.
Сначала я предложил просто убрать статистику. Но оказалось, это едва ли не самая нужная фишка — даёт моментальную видимость по контрагенту.
Естественно, код был переписан самым простым способом — пакетной обработкой. Грузим по 5000 блоков, считаем объём. И всё прекрасно заработало.
Это, к слову, о преждевременной оптимизации. Довольно плохой масштабирующийся код прекрасно работал в не самой маленькой компании 13 лет :)
Такой вот blast from the past, ничего не скажешь. Кто бы вообще мог подумать, что это всё будет работать столько лет без проблем.
#php #memory
Тринадцать лет назад я работал в горнодобывающей/камнеобрабатывающей компании и пилил всякие инхаус-проекты: от учёта блоков, добытых на карьере, до их продажи, каталогизации, распиловки. Вплоть до визуального конструктора надгробий (на котором тщетно пытался сделать бизнес, но сегодня не о нём).
И вот сегодня в девять утра позвонил бывший коллега. С проблемой 🫠
Итак: не грузятся продажи больше, чем за пару дней. Сервер выбивает в пятисотую.
Начал диагностику и понял, что падает по памяти. Причём, не потому что много продаж, а потому что может быть много блоков в продаже.
Ну а памяти-то там кот наплакал. Как крутилось на шаред-хостинге со 128 мегабайтами памяти на PHP 5.3, так и крутится.
Как оказалось, я образца 2012 года, для подсчёта продаж просто грузил в памяти вообще все блоки, а потом их уже фильтровал и считал объёмы.
Казалось бы, какая фигня, скажете вы, ну сколько там тех блоков?
Ну так-то за 13 лет добыли почти 24000 блоков и совершили несколько тысяч продаж. А каждый блок — специфика работы — должен был сохранять историю изменений, распилов, расколов и так далее... Ревизии, короче. Это довольно ощутимый объём данных.
Сначала я предложил просто убрать статистику. Но оказалось, это едва ли не самая нужная фишка — даёт моментальную видимость по контрагенту.
Естественно, код был переписан самым простым способом — пакетной обработкой. Грузим по 5000 блоков, считаем объём. И всё прекрасно заработало.
Это, к слову, о преждевременной оптимизации. Довольно плохой масштабирующийся код прекрасно работал в не самой маленькой компании 13 лет :)
Такой вот blast from the past, ничего не скажешь. Кто бы вообще мог подумать, что это всё будет работать столько лет без проблем.
#php #memory
- ❤ 21
- 👍 4












