Optimizing Networking

The simplicity of Cloud Functions lets you quickly develop code and run it in a serverless environment. At moderate scale, the cost of running functions is low, and optimizing your code might not seem like a high priority. As your deployment scales up, however, optimizing your code becomes increasingly important.

This document describes how to optimize your functions' networking. Some of the benefits of optimizing networking are as follows:

  • Reduce CPU time spent in establishing new connections at each function call.
  • Reduce the likelihood of running out of connection or DNS quotas.

Maintaining Persistent Connections

This section gives examples of how to maintain persistent connections in a function. Failure to do so can result in quickly exhausting connection quotas.

The following scenarios are covered in this section:

However, the same techniques apply to most HTTP request libraries including Axios and Superagent.

HTTP/S Requests

This section shows examples of optimized functions that make HTTP requests.

This optimized code snippet maintains persistent connections via a custom HTTP agent with the keep-alive option instead of creating a new connection every function invocation:

const http = require('http');
const functions = require('firebase-functions');
const agent = new http.Agent({keepAlive: true});

exports.function = functions.https.onRequest((request, response) => {
    req = http.request({
        host: '',
        port: 80,
        path: '',
        method: 'GET',
        agent: agent,
    }, res => {
        let rawData = '';
        res.on('data', chunk => { rawData += chunk; });
        res.on('end', () => {
            response.status(200).send(`Data: ${rawData}`);
    req.on('error', e => {
        response.status(500).send(`Error: ${e.message}`);

The same approach works for HTTPS—just use https.Agent instead of http.Agent.

Accessing Google APIs

This section shows examples of optimized functions that access Google APIs.

This example uses Cloud Pub/Sub, but this approach works also for other client libraries—for example, Cloud Natural Language or Cloud Spanner. However, note that the savings may depend on the current implementation of a particular client library.

Creating a PubSub client object results in one connection and two DNS queries per invocation. To avoid unnecessary connections and DNS queries, create the PubSub client object in global scope as shown in the sample below:

const PubSub = require('@google-cloud/pubsub');
const functions = require('firebase-functions');
const pubsub = PubSub();

exports.function = functions.https.onRequest((req, res) => {
    const topic = pubsub.topic('');

    topic.publish('Test message', err => {
        if (err) {
            res.status(500).send(`Error publishing the message: ${err}`);
        } else {
            res.status(200).send('1 message published');

Testing Your Function

To measure how many connections your function performs on average, simply deploy it as a HTTP function and use a performance-testing framework to invoke it at certain QPS. One possible choice is Artillery, which you can invoke with a single line:

$ artillery quick -d 300 -r 30 <URL>

This command fetches the given URL at 30 QPS for 300 seconds.

After performing the test, check the usage of your connection quota on the Cloud Functions API quota page in Cloud Console. If the usage is consistently around 30 (or its multiple), you are establishing one (or several) connections in every invocation. After you optimize your code, you should see a few (10-30) connections occur only at the beginning of the test.

You can also compare the CPU cost before and after the optimization on the CPU quota plot on the same page.

Send feedback about...

Need help? Visit our support page.