RM
Мало ли может какой то петушок сервер положит багом
Size: a a a
2020 September 06
RM
Надо ещё дампы сделать
RM
И стектрейс воткнуть
CC
Разработка ПО это трейдоффы
RM
Что по логам? Почему многопоточность уступает одному потоку? Я полагаю дело в том, что эти сообщения ещё и дублируются в консоли
RM
Там же консоль это отдельный поток вроде
RM
Может этот поток консоли не тянет столько сообщений обрабатывать
CC
Когда ты говоришь что твое приложение не имеет права проебывать данные или логи за последние пять минут, это означает что ты жертвуешь перфом(либо должен компенсировать его доп хардваром) за это(ведь теперь тебе необходимо после каждой записи данных коммитится)
RM
Когда ты говоришь что твое приложение не имеет права проебывать данные или логи за последние пять минут, это означает что ты жертвуешь перфом(либо должен компенсировать его доп хардваром) за это(ведь теперь тебе необходимо после каждой записи данных коммитится)
Почему это? Там же другой поток управляет записью логов в файл
CC
Поэтому часто принимается решение, что мы имеем право проебать часть логов в угоду постоянно "повышенной" производительности
RM
Если конечно потоки в конфиге задаешь
CC
Почему это? Там же другой поток управляет записью логов в файл
Я говорю в общем случае про возможность терять данные
RM
Тогда можно ещё параметр добавить в конфиг
CC
То есть не всегда стоит жесткое условие "Не теряем данные ни в коем случае"
CC
Да, я к этому и веду
RM
Чтоб настраивать флуш
CC
доработать функционал с буфферизацией и флашем. Для тех кому допустимо терять часть логов, но хочет чтобы было пошустрее самое оно
CC
Ну и подумать над async write
RM
Там можно сделать так чтоб логи уровня еррор и выше флушились сразу
RM
А инфо и прочее клались в буфер