Та не, там транзакции не имеющие отношения к пользователям, но пользователи имеют возможность видеть те транзакции, которые подходят под их условия. Как бы так пояснить... Транзакции - это транзакции некоторых Штук. И вот Вася может смотреть только транзакции по Штуке1 и Штуке2, а Петя по Штуке2, Штуке3 и Штуке4. Но перед тем, как эти транзакции показываются пользователями - они обрабатываются. Например, Вася может видеть не только информацию по транзакции, но и некоторые связующие данные. Таким образом, когда Вася ходит по страницам, каждый раз из БД дёргаются эти транзакции, с ними проводятся некоторые операции (подсчет, формирование и т.д.) зависящие от пользователя и выдаются на страницу. Т.е. вот этот механизм подготовки получается нужно переложить на механизм сборки транзакций. За счет этого и увеличится нагрузка на обработчик, потому как ему придётся не просто собирать, но и готовить для каждого пользователя своё "представление".
Как альтернативу рассматриваю запуск отдельной задачи, которая будет запускаться при появлении новых транзакций, чтобы не задерживать сборщик. Но это ладно, главное, что понятно стало как со стороны пользователя уменьшить нагрузку.
Про таблицу писал, потому что не работал ранее с кэшированием и тут скорее просто выразился так.
В целом, суть ясна. Чуть увеличится нагрузка на обработчик транзакций (ввиду предварительной подготовки для пользователей), но это не смертельно. В любом случае, всё стало яснее. Спасибо за помощь!
И ещё вопрос. В какой статье не погляжу, везде когда кладут данные в кэш - выставляют ключ. Но ключ, совершенно не привязан к пользователю. Т.е. например $redis.set("categories", categories) Но по хорошему ведь нужно в кэш класть с ключом не categories, а что-то вроде этого: categories+current_user.id.to_s Логично ведь?
Да, понимаете вы правильно. Это самописное приложение, есть доступ до всего. Сейчас 1.5 секунды и количество данных считается низким (примерно 1-1.5% от того, что может быть) и это уже 1.5 секунды. Будет больше - будет дольше. Основные затраты времени сейчас делятся примерно так: около половины секунды на выборку и около секунды на обработку. Считаем это очень долгим, особенно при расчете, что данных будет значительно больше.
На тему транзакций. Работа с ними ведётся отдельным worker'ом на той же БД. Возможно это важно.
Немного не знаком с кэшированием (особенно в RoR), поэтому хотел бы переспросить вас, правильно ли я понимаю, что логика примерно такая... При первом показе блока данных, сами данные грузятся как обычно и попадают таблицу с кэша с пометкой актуальности (флажок или дата). Затем, когда транзакции изменились, worker смотрит кэш пользователей и обновляет статус (помечая флажок или дату как неактуальные). Затем, когда пользователь перешёл на новую страницу, срабатывает новая выборка, так как кэш неактуален, судя по флажку или дате. Верно понимаю?
Технически, когда появляется новая транзакция, я могу где-то делать пометку. Но получается, что между переходами, нужно как-то смотреть что в кэше и насколько актуально это.
Это не критично, но пользователю важна эта информация. Скажем так, он будет чуть напрягаться, если будет видеть опоздавшие данные. А я не хотел бы, чтобы он напрягался.
Да я уже вижу, что там все конфиги и вообще полный nginx. Только теперь его надо как-то удалить, чтобы не создать ещё больших проблем. Я-то использовал тот, что поставил из исходников, а там видимо лежит из пакетов который.
Полагаешь, что там другой nginx висел? Я смотрел, но было:
user@serv:/var/www/apps/testapp$ netstat -tulpn | grep :8080
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN -
