Pull to refresh

Comments 18

Java 11 (Spring MVC)

Трейсинг туда должне втыкаться на ура (добавлением одной зависимости, поднятем одного типового сервера для хранения трейсов, ну и адрес прописать в когфигах).

Трейсинг для запросов в базу идёт из коробки. В клиенте для кэша возможно тоже уже всё есть. Но если нет, по по трейсу быстро найдёте места, где тратится время и лекго туда добавите трассирование.

Вы правы)
Скоро будет другая статья с очередными приключениями, там как раз трейсинг помог

Для чего вам БД, если все данные храните в кеше? Может быть отказаться от реляционной бд и хранить все данные в редис?

В БД хранятся данные долгосрочные, в кеше - те, которые, скажем так, в активном использовании.

Реляционная бд отдаёт инфу достаточно быстро, для того, чтобы использовать её непосредственно из приложения не задумываясь про дополнительный кэш. Конечно если нет ошибок проектирования. Поэтому я задал свой вопрос.

Безусловно РБД инфу отдает быстро, особенно если создать правильные индексы и т.д.. В среднем запрос к БД (для получения данных, которые сейчас лежат в кеше) происходит за 80-100мс. В целом результат норм, но поскольку верхний порог - 65мс, то приходится искать другие пути.

Рсубд может отдавать данные за 15 мкс. Nginx с php, может отдать json построенный на данных бд, за 30 мкс. Важна верная конфигурация рсубд, оптимальная структура таблицы и оптимальный запрос.

беда, когда никто не представляет где находится Apache Ignite

Уже в который раз наблюдаю статью на тему "как мы криво напроектировали, а потом героически снизили время отклика в разы".

Чисто для развлечения - стоит посчитать, сколько ещё юных самородков напишут подобные статьи за ближайший год? Делайте ставки, господа!

Не стоит забывать, что сервис может достаться "в наследство" вместе со всеми своими болячками.

Согласен. Правда ошибки проектирования тоже не стоит игнорировать, даже будучи белым и пушистым. И ещё красивее было бы, если причастный к косякам всё осознал и показал свою историю в назидание потомкам.

К сожалению, причастные к тому моменту либо уже уволились, либо ушли на другие проекты)

Наверное классно, когда все разработки - это новые проекты. Большинству же приходится работать с тем, что есть.

Почему бы не развернуть играйт прямо в приложении? На старте скачивать из БД данные в кэш

Правило оптимизации номер один - оптимизировать то, что нужно оптимизировать.

Прежде чем тюнить GC, даже если у вас нет Sentry, OpenTelemetry, Jaeger, Prometheus, всегда можно навтыкать логов и найти узкое место.

По-вашему, включить логи и поменять тип GC - это значит тюнить?)

По-моему, сначала снимаются все возможные метрики и выявляются аномалии, а затем принимаются меры

Sign up to leave a comment.

Articles