How to reduce query time?

There is a request to an api that takes too much time (getting old warehouses, a lot of information)

warehouses = do |code|
 data = Net::HTTP.get(URI.parse(URI.encode("параметр=#{code}")))

codes - contains codes of cities
data - all the information about a specific warehouse in the selected city
warehouses - an array with warehouses in the selected codes in the city

For the city, where such warehouses 4, of course, is built quickly. But in the MSC 219 is constructed and they can up to 30 seconds.

Our database can be kept as an option.
But I would like to know:
1) how and where else can you store this data? to reduce the query time. Or still better in the database.
2) can we optimize the code?

UPD: the Logic of this
1) choose the select city
2) city code is sent in the action
3) action build warehouses and their description
4) display on the map

Objective: to obtain a large number of warehouses rapidly. MSC (219 stores) the request lasts for 30 seconds. in a small town, where only 4 of the warehouse, the old warehouse turns quickly.
June 10th 19 at 15:41
2 answers
June 10th 19 at 15:43
The total query time can be reduced if downloading the data from the source asynchronously, using Thread. Here are some examples:

Keep can be different. It depends on the formulation of the problem, which is not listed.
Can't podcasti how to optimize the code because it is not specified.

If asynchronous downloading is not enough for optimization, it suggests another way:
instead of downloading on the warehouses every time in the action of the controller, especially if their size is essential and not quick third-party API returns data, it is better to create a Rake task for periodic updates of data warehouses after a certain promejutok time. Thus, the controller will take the previously saved data from the database, saving time re-downloading data.
How exactly the save data is determined based on the required data structures.
For example, you can store data in the RDBMS so (if I correctly understood the task):
id | city_id (integer) | code (string/integer) | warehouse_data (text)

Among other things, for frequently repeated queries, the data can be taken directly from the cache. Case statistics can be obtained by log analysis queries.

Summing up:
  1. to create a Rake task in which you need to go through all the possible cities and codes saved the data in a DBMS
  2. the controller will be ready to take the data from the database
  3. to cache data according to the query parameters. Well, maybe a more advanced part to make it absolutely as on science: Wikipedia: caching Algorithms
I have updated the question. But the code where the heavy request I uploaded (before anything important happens), and the task - to 219 of the warehouses quickly, not wasting 30 seconds. If this is the city where only 4 of the stock and action is fast. - Joany22 commented on June 10th 19 at 15:46
June 10th 19 at 15:45
Cache the information, periodically update from the API.
not really then understand how to cache. I chose the city of Moscow, its code went into action, there is running code out of the question. and I got say 16 warehouse per city. the next time the client came in, chose Moscow and got the result for the first city? or again he will have to build the query (which is long)? I need to cache? - Joany22 commented on June 10th 19 at 15:48
I'd walked all the city codes, got the answers and saved them in the database. Simmered once a day, in some time (better at night), for the crown was to re-and updated information.

When a client makes a request on your site - you take information from the database, not the API. This process you can optimize and it will work much faster.


The alternative is to cache only replies for certain queries. The first client who demands Moscow will have to wait for 30 seconds, but the following will get the result from cache in fractions of a second. This option is easier to implement, but as for me the first is much better.

You basically can't speed up the work of third-party service accessed via the API on your behalf (if I understood everything correctly and a narrow neck it is). - Joany22 commented on June 10th 19 at 15:51
cool, the correct answer was the same, I have just a little more detailed. - vincenza.Satterfield commented on June 10th 19 at 15:54

Find more questions by tags RubyRuby on Rails