1
votes

I have "Google cloud function" in region europe-west1 (Belgium) which creates tasks in "Google cloud task queue" located in europe-west3 (Germany). It's similar to tutorial: https://cloud.google.com/tasks/docs/tutorial-gcf

It takes about 1-2 seconds for cloud function to create a task. It's not optimized solution because CF has to wait idle so long.

  1. How to optimize task creation time?

  2. Will moving of Cloud function and Task queue to one region significantly improve task creation speed?

  3. Can I just stop cloud function when send "task queue creation" request and don't wait for response? Of course, it's bad practice and I would like to avoid this.

import { v2beta3 } from '@google-cloud/tasks';

// cloud function
(req, res) => {
  const client = new v2beta3.CloudTasksClient();
  ...
  // send "create task" request
  client.createTask(...);

  setTimeout(() => {
    // Stop cloud function without processing of queue response
    res.sendStatus(200);
  }, 100);
}
2

2 Answers

0
votes
  1. The API will take as long as it needs to take. I don't believe there is any way to speed up that module.

  2. That sounds like something you could experiment with.

  3. No, a Cloud Function can not terminate until all of its async work is also complete, otherwise Cloud Function will clamp down on the resources in that function, and that work might not finish. You should be using promises to determine when async work completes, and only send the response afterward.

0
votes

Ad 1. If you define task name in createTask, this might provide opportunity for optimization. Providing task name affects performance because of additional lookup. Lookup cost is lower if you don't assign task name in advance. If you require it, ensure that subsequent task IDs you use are not sequential. For instance, lookup in a long collection of sequentially-named tasks like taskname1, taskname2, taskname3 is slower than for sa7239112, 92sdkdskfs, 4812kdfsdf.

Documentation:

Because there is an extra lookup cost to identify duplicate task names, these calls have significantly increased latency. Using hashed strings for the task id or for the prefix of the task id is recommended. Choosing task ids that are sequential or have sequential prefixes, for example using a timestamp, causes an increase in latency and error rates in all task commands. The infrastructure relies on an approximately uniform distribution of task ids to store and serve tasks efficiently.