You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's useful to be able to take a large request with many pages into smaller requests so they can be run in parallel or asynchronously. Datetime is convenient way to split up requests.
The ItemSearch class should have a function(s) to return an array of Request objects. The simplest of these can just take in a num_requests parameter that will take the datetime range and split it into num_requests requests.
A more complicated function would take in the approximate number of Items to return in each request. A series of requests can be made to get number of hits to divide up the requests roughly equally (as in the above code link).
The text was updated successfully, but these errors were encountered:
It also hints that async requests could help with performance (#4). We spend ~90% of our time waiting on I/O, and the rest on parsing JSON, so we're mostly (but not entirely) IO bound / non-blocking.
It's useful to be able to take a large request with many pages into smaller requests so they can be run in parallel or asynchronously. Datetime is convenient way to split up requests.
The code in the Cirrus stac-api feeder code is one example of doing this with sat-search.
The ItemSearch class should have a function(s) to return an array of Request objects. The simplest of these can just take in a
num_requests
parameter that will take the datetime range and split it intonum_requests
requests.A more complicated function would take in the approximate number of Items to return in each request. A series of requests can be made to get number of hits to divide up the requests roughly equally (as in the above code link).
The text was updated successfully, but these errors were encountered: