DI
Это в стоке? Какую-либо оптимизацию или кастомизацию системы приходилось проводить?
Size: a a a
2021 November 09
NK
Было пару правок в ядре, были отключены парочка трейтов у стандартных моделей системы и были перенесены stmt prepare для sql на сторону бекенда
DI
Потенциальные заказчики дают абстрактную цифру в 100к юзеров (одновременные подключения, как я понимаю). Как тут RPS высчитать точно, не знаю.
DI
Ну, в принципе, не много)
NK
Я бы сказал что практически не было, большинство "оптимизаций" можно было своим же кодом произвести в обход стандартных библиотек
NK
File модель жутко медленная
NK
Рекоменадция: не используй AttachOne / AttachMany на таком проекте, иначе будет смэрть
DI
+ спасибо)
A
hamerium (52.96) увеличил карму ReaZzon (6079.22)
ЮТ
100к онлайна не потянет. Это очень много, надо сразу что то закладывать. У нас на одном проекте вылезло 15 - 20к онлайна, и еле не легли.
ЮТ
Железо было норм, кешам обвешивались. Там сайт достаточно большой изначально. 70к статей, 900к коментов к ним. Расчитаный на 100к уников в месяц изначально
DI
Основная нагрузка на БД была?
NK
У нас да
ЮТ
у нас нет. Кеша изначально было много заложено. Просто все в полку вставало, проц память диск. Дальше только в статическое кеширование уходить
DI
Какие-то попытки оптимизации кодовой базы проводили?
DI
Интересно, где именно затык
DI
Я знаю, что на Laravel некоторые делают что-то близкое к хайлоаду
DI
Архитектура во многом идентична же
ЮТ
не скажу где затык был на том проекте. Не закапывались, там такое случалось раз в год, когда презентация у эпла была. Подходы наверняка надо использовать те же что и у Laravel.
Ни кто не встречал каких то публикаций на эту тему? В целом вопрос тоже интересен.
Ни кто не встречал каких то публикаций на эту тему? В целом вопрос тоже интересен.
NK
У вас монолит был или бек и фронт отдельно?