Асинхронные запросы к БД в Rails. Как?

Question

[Роман Назаркин]

Всем доброго времени суток.

Есть задача - подсчитать количество запросов к определенной странице сайта, построенного на основе RoR, но при этом нужно сохранить максимальное быстродействие страницы(скорость ответа сервера не должна падать).

Моя мысль такова: сначала генерируем страницу(не выполняя запрос к БД), затем отдаем её посетителю, закрываем соединение и только после этого делаем запрос к БД.

А теперь вопрос: возможно ли реализовать подобный механизм и какими средствами?
И в попутку - может есть более оптимальный способ реализовать подобное?

Comments

[vsuhachev]

Так в итоге что вы хотите получить? Статистику посещений? Непонятно причем тут какие-то асинхронные запросы...

[Роман Назаркин]

vsuhachev: мне нужно посчитать количество обращений к странице, но при этом не замедляя страницу(её быстродействие, скажем так, очень принципиально), поэтому и ищу решения..

Answer 1

[anyd3v]

почитайте про асинхронные очереди, как пример rubyamqp.info/articles/getting_started

Comments

[Роман Назаркин]

Разве без очередей не обойтись? Ведь это все равно замедление, как минимум на отправку сообщения в эту самую очередь тоже требуется время..

[anyd3v]

можете eventmashine обойтись. А что значит на "отправку сообщения"? вы просто отправить эвент в eventmashine? я не думаю что время будет соизмеримо с другими операциями. В любом случае вам надо сделать действие и это действие будет "стоить сколько то времени"

[Роман Назаркин]

anyd3v: да, но почему нельзя выполнять это действие после того как запрос выполнен и ответ сформирован? тогда снаружи никаких изменений видно не будет.

[anyd3v]

вы смотрели after_filter?

[Роман Назаркин]

anyd3v: да, он запускается до отправки данных на клиент, но после обработки view => не асинхронно..

Answer 2

[Viktor Vsk]

1. Синдром преждевременной оптимизации детектед.
2. Если бы в данном случае (в конкретном проекте, ресурсе, приложении) дейсвтительно была бы такая острая необходимость сэкономить время на форк процесса или постановку в очередь, то этим занимались бы не вы.
3. В таких случаях можно использовать триггеры, коллбеки, хранимые процедуры в базе, что вообще правильно, в принципе. Хотя использование очередей тоже логично. Что в итоге окажется примлемее из этих двух подходов (по быстродействию, надежности, масштабируемости, поддерживаемости) - надо выяснять уже на месте. Кстати, заметьте, перечислены только некоторые из важных пунктов, кроме быстродействия (да и то, какого ? на клиенте, на сервере приложения, на сервере базы?...), которое всегда хочется впихнуть везде, если ничего не знаешь.
4. Если все же хочется потратить впустую часть жизни, что бы удовлетворить синдром, указанный в первом пункте, сначала ознакомьтесь, что такое output buffering, как он работает в определенных руби-серверах (вебрик, монгрелл, юникорн, пума...), а так же реверс-прокси (нджинкс, апач...) и как быть с рэк-миддлварами, которые не поддерживают стриминг. Плюс, какие проблемы могут появиться с хедерами.
Вот, с чего можно начать:
stackoverflow.com/questions/2832010/what-is-output...
blog.plataformatec.com.br/2012/06/why-your-web-fra...
blogs.sequoiainc.com/blogs/easy-streams-with-rails...
stackoverflow.com/questions/2148114/why-use-output...
www.sitepoint.com/php-streaming-output-buffering-e...
weblog.rubyonrails.org/2011/4/18/why-http-streaming
railscasts.com/episodes/266-http-streaming
https://gist.github.com/igrigorik/3058839
blog.phusion.nl/2012/08/03/why-rails-4-live-stream...
evaleverything.com/2013/09/07/response-streams-wit...

Comments

[Роман Назаркин]

Язвительный ответ. Я бы на вашем месте не тратил время на написание первых трех пунктов, но все равно спасибо.

И да, по первому - а выполнить задачу сразу как положено, чтобы потом к ней не возвращаться - уже не тренд, плохой тон?

[Viktor Vsk]

Роман Назаркин: вы никогда не решите задачу сначала как положено. И уж тем более, если задача, как таковая, четко не очерчена (например, количество rps, отношение select/insert в базе, допустимый пинг, возможности горизонтального\вертикального масштабирования...)

Если не верите, создайте еще один вопрос, что-то типа "На сайте есть много страниц и я хочу посчитать количество визитов, укажите, пожалуйста, на возможные подводные камни". И там постараемся все вместе пофантазировать и представить 100500 ситуаций, которые при каких-то специфичных условиях могут случиться.

И в итоге, если вы не начнете ставить и решать реальные задачи, а будете бороться с мельницами-производительностями - то голова станет болеть очень сильно)

Answer 3

[vsuhachev]

Если вам нужно считать количество обращений к странице без "побочных эффектов" то есть минимум 2 пути

1) Использовать внешние счетчики Яндекс-метрика, Гугл-аналитака и т.п.
2) Считать статистику по логам веб-сервера. Есть различные программы для такого анализа, ищите

Каждый метод имеет свои особенности: N1 - больше заточен на детектирование людей, N2 - попадает полная статистика в том числе боты, поисковые машины и т.д.

Answer 4

[Борис Пеньковский]

Запускайте свой механизм в бефор/афтер фильтре через

Thread.new do
  call_some_method(params)
end

Answer 5

[Сергей]

Добавьте запрос с самой страницы: ajax или загрузка однопиксельной картинки - как угодно.

Вполне может быть, что, например, страница кешируется web-сервером и не каждый её запрос доходит до приложения. Или запрос делает поисковый бот - такие «просмотры» вам наверное тоже не нужны.