Как уменьшить время запросов?

Question

[Андрей]

Есть запрос к api, который выполняется очень долго (получаю инфу о складах, много инфы)

warehouses = codes.map do |code|
  data = Net::HTTP.get(URI.parse(URI.encode("http://endpoint.de?параметр=#{code}")))
  JSON.parse(data)
end

codes - содержит коды городов
data - вся инфа о конкретном складе в выбранном городе
warehouses - массив со складами в выбранном по codes городу

Для города, где таких складов 4, понятное дело, строится быстро. Но в Мск их 219 и строится может до 30 секунд.

В базе сохранять можно, как вариант.
Но я хотел бы узнать:
1) как и где еще можно хранить эти данные? чтобы сократить время запросов. Или все таки лучше в базе.
2) можно как-то оптимизировать код?

UPD: Логика такая
1) выбираю селектом город
2) код города отправляется в экшн
3) в экшне строю склады и их описание
4) отображаю на карте

Задача: получить большое кол-во складов быстро. В мск (219 складов) при этом запрос длится 30 секунд. в маленьком городе, где всего 4 склада, инфа по складам получается быстро.

Answer 1

[d'Ivan]

Общее время запросов можно сократить если скачивать данные с источника асинхронно, при помощи Thread. Здесь есть примеры: ruby-doc.com/docs/ProgrammingRuby/html/tut_threads.html

Сохранять можно по-разному. Это зависит от постановки задачи, которая не указана.
Не могу подказать как оптимизировать код поскольку он не указан.

UPD
Если асинхронного скачивания недостаточно для оптимизации, то напрашивается другой способ:
вместо скачивания о складах каждый раз в экшене контроллера, особенно если их размер существеннен и сторонний API небыстро возвращает данные, лучше создать Rake task для периодического обновления данных о складах через определённый промужуток времени. Таким образом, контроллер будет брать заранее сохранённые данные из БД, экономя время на повторное скачивание данных.
Как именно сохранять данные определяется исходя из требуемой структуры данных.
Допустим, можно хранить данные в РСУБД так (если я верно понял задачу):
id | city_id (integer) | code (string/integer) | warehouse_data (text)

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

Подытожив:

1. создать Rake task, в которой нужно пройтись по всем возможным городам и кодам, сохраня данные в СУБД
   
2. контроллер будет брать готовые данные с БД
   
3. кешировать данные согласно параметрам запроса. Ну и, возможно, более продвинутая часть, чтобы было совсем как по науке: Википедия: Алгоритмы кэширования
   

Comments

[Андрей]

Я немного обновил вопрос. Но код где тяжелый запрос я выложил (до этого ничего важного не происходит), а задача - получить 219 складов быстро, не тратя на это 30 секунд. При это есть города где всего 4 склада, и экшн выполняется быстро.

Answer 2

[Александр]

Кэшируйте у себя информацию, периодически обновляйте из API.

Comments

[Андрей]

не совсем тогда понимаю как кэшировать. Я выбрал город москва, его код отправился в экшн, там выполняется код из вопроса. и я получил скажем 16 складом для одного города. в следующий раз клиент зашел, выбрал Москву и получил результат для первого города? или ему опять придется строить запрос (что долго)? Что мне нужно закешировать?

[Александр]

Андрей Я бы сделал так: прошелся бы по всем кодам городов, получил ответы и сохранил их у себя в БД. Припустим раз в сутки, в какое-то время (лучше ночью), по крону проходился бы повторно и обновлял информацию.

Когда клиент делает запрос у вас на сайте - вы берете информацию у себя из БД, а не по API. Этот процесс вы можете оптимизировать и работать он будет в разы быстрее.

---

Альтернатива - кешировать у себя только ответы по определенным запросам. Первый клиент который запросит Москву будет ждать 30 сек, но следующий уже получит результат из кэша за доли секунды. Этот вариант проще реализовать, но как по мне первый значительно лучше.

Вы в принципе не можете ускорить работу стороннего сервиса к которому обращаетесь по API со своей стороны (если я всё верно понял и узким горлышком является он).

[Александр]

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