Earth Engine has different environments for processing data: interactive and batch. These two environments (or "realms") handle different types of queries and have very different performance characteristics, so it's important to understand when and how to use each.
Also called the "synchronous" or "online" stack, this environment is optimized for answering small requests which finish quickly (responses are limited to tens of megabytes of data and must finish processing within five minutes). Many requests can be made in parallel up to the quota limits.
The interactive environment is composed of different API endpoints: standard and high volume.
The standard endpoint is appropriate for most human-driven usage, and it's what powers the Code Editor and Earth Engine Apps. Specifically, this endpoint is best suited for latency-sensitive applications which involve a low volume of concurrent, non-programmatic requests.
The high-volume API endpoint is designed to handle more requests in parallel than the standard endpoint, with the tradeoff of higher average latency and reduced caching. The high-volume API is often the best choice when making many requests programmatically. See more in the High Volume API docs.
Also called the "asynchronous" or "offline" stack, this environment is optimized
for high-latency parallel processing of large amounts of data. Requests are
submitted as tasks to batch processing endpoints, usually by calling data
export functions (e.g.,
ee.batch.*) from the Earth Engine client libraries. Each batch task has a
maximum lifetime of ten days. Up to 3000 tasks can be submitted per user, but
each individual user is limited to a small number of concurrently running tasks.
Tasks are held in a per-user queue, starting in the order in which they were
submitted. Tasks progress from the
SUBMITTED (queued) state to the
state when they're assigned to a batch processor. Each processor is
responsible for orchestrating a varying number of batch workers to run the
computation and produce the task's results. The number of workers for a task is
determined by the EE service's ability to parallelize the job and is not
Tasks complete successfully when they create the necessary artifacts (Earth Engine assets, files in Google Cloud Storage, etc.).
If a task fails for a reason which won't be fixed by retrying (e.g., the data
are invalid), the task will be marked as
FAILED and won't be run again.
If a task fails for a reason which could be intermittent (e.g., it timed out
when running a computation), Earth Engine will automatically attempt to retry it
and populate the
retries field. Tasks can fail up to five times, and the final
failure will cause the entire task to be marked as
Each task has an alphanumeric ID of the form
are displayed on the
Tasks tab of the Code Editor,
or in the Task Manager. You can also
obtain task IDs and information about tasks from the
earthengine task command. If you
are starting tasks programmatically, you get the task ID from
ee.data.newTaskId. When requesting
help to debug an export or ingestion task, provide this task ID as a copyable
string (not a screenshot).
List of task states
Tasks can have the following
UNSUBMITTED, still pending on the client
READY, queued on the server
RUNNING, currently running
COMPLETED, completed successfully
FAILED, completed unsuccessfully
CANCEL_REQUESTED, still running but has been requested to be cancelled (i.e., not a guarantee that the task will be cancelled)
CANCELLED, cancelled by the owner