Безусловно РБД инфу отдает быстро, особенно если создать правильные индексы и т.д.. В среднем запрос к БД (для получения данных, которые сейчас лежат в кеше) происходит за 80-100мс. В целом результат норм, но поскольку верхний порог - 65мс, то приходится искать другие пути.
Я понимаю, о чем вы. Но в данном случае вариант с переопределением equals и hashCode не рассматривался, поскольку разбирается случай именно с модификацией объекта, который уже существует в коллекции.
Структура не используется неправильно. Посыл скорее в том, что при использовании mutable объектов могут возникать подобные ситуации, и к ним нужно быть внимательнее.
Как скажешь
По-вашему, включить логи и поменять тип GC - это значит тюнить?)
Безусловно РБД инфу отдает быстро, особенно если создать правильные индексы и т.д.. В среднем запрос к БД (для получения данных, которые сейчас лежат в кеше) происходит за 80-100мс. В целом результат норм, но поскольку верхний порог - 65мс, то приходится искать другие пути.
К сожалению, причастные к тому моменту либо уже уволились, либо ушли на другие проекты)
Не стоит забывать, что сервис может достаться "в наследство" вместе со всеми своими болячками.
В БД хранятся данные долгосрочные, в кеше - те, которые, скажем так, в активном использовании.
Данная тема может быть очевидна для вас, как для человека с опытом, но новичкам может быть полезно.
Я понимаю, о чем вы. Но в данном случае вариант с переопределением equals и hashCode не рассматривался, поскольку разбирается случай именно с модификацией объекта, который уже существует в коллекции.
Естественно. Поэтому у статьи уровень сложности простой, и она не нацелена на "прожженных" джавистов.
Структура не используется неправильно. Посыл скорее в том, что при использовании mutable объектов могут возникать подобные ситуации, и к ним нужно быть внимательнее.
Вы правы)
Скоро будет другая статья с очередными приключениями, там как раз трейсинг помог