Heroku Запрос Timeout (H12) с большими данными

Question

У меня есть Ruby On Rails приложение, которое получает много данных с сайтов социальных сетей, как Twitter, Facebook и т.д.

Существует индексная страница, которая показывает запись как выгружаемая. Я использую Kaminari для подкачки.

Моя проблема - большие данные, я думаю. Предположим, у меня есть миллионы записей и вы хотите показать их на моей индексной странице с Каминари. Когда я пытался запустить систему браузером, Heroku дает мне ошибку H12 (тайм-аут запроса).

Что я могу сделать для улучшения производительности своего приложения? У меня есть идея получить только записи, которые будут показаны на индексной странице. Аналогично, при нажатии на ссылку второй страницы Каминари, только выборка второй записи страницы из базы данных. Идея в основном такова, но я не знаю, с чего начать и как ее реализовать.

Вот пример кусок кода из моего контроллера:

@ca_responses = @ca_responses_for_adaptors.where(:ca_request_id => @conditions) 
               .order(sort_column + " " + sort_direction) 
               .page(params[:page]).per(5) 

@ca_responses: Мои записи

@ca_responses_for_adaptor: отчеты, основанные на адаптере. Думайте как администратор, и это возвращает все записи.

@ условия: получение указанных записей адаптера. Например, получение только записей, связанных с Twitter, и т. Д.

Answer 1

Вы можете начать с создания таблицы кеша страницы, которая будет заполнена вашими данными для ваших результатов поиска. Это может быть один подход. Там может быть немного недостатков, но если бы я знал точную проблему, я мог бы предложить лучшее решение. Я сомневаюсь, что вы будете перечислять миллион пользователей на одной странице, а затем получить доступ к ним с помощью постраничного страниц или я ошибаюсь

EDIT (?):

Там могут быть некоторые проблемы с нумерацией страниц. Во-первых, разбиение на разбивающиеся драгоценные камни работает так: они извлекают все данные, а затем, когда вы нажимаете на номер страницы, он извлекает только 5 элементов (или, тем не менее, вы их установили) из всего списка. Проблема здесь fetching all the data before paginating. Если у вас миллион записей, это может занять некоторое время для каждой страницы. Вы можете определить новый метод, который будет запускать SQL-запрос, чтобы выбрать один объем данных из базы данных, и вы можете установить команду offset для извлечения данных только для этой страницы. В этом случае paginate gem бесполезен, поэтому вам нужно будет удалить его.

Второй вариант заключается в том, что вы можете использовать что-то вроде user_cashe, что-то в этом роде. Под этим я хочу создать новую таблицу, в которой будет всего несколько записей - записи, которые будут отображаться на экране. Таблица будет меньше, чем пользовательская таблица usuall, а затем быстрее будет искать ее.

Могут быть другие более продвинутые решения, но я сомневаюсь, что вы могли (захотите) использовать его в своем приложении.

Answer 2

Kaminari уже разбивает ваши записи так, как ожидалось.

Heroku подвержен случайным ошибкам таймаута из-за его random router.

Попробуйте воспроизвести на местном. У вас могут быть узкие места в вашем коде, которые делают ваш запрос слишком длинным для возврата. У вас не должно возникнуть проблемы с запросом 5 элементов из базы данных, поэтому у вас может быть код до или после этого, который занимает много времени.

Если все в порядке на локальном с производственными данными, вы можете добавить new_relic, чтобы проанализировать ваши запросы и посмотреть, возникает ли какая-либо проблема специально для производства (и почему).

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