Functions execution spikes.

91 views
Skip to first unread message

Mads Jon Nielsen

unread,
Apr 18, 2017, 9:40:20 AM4/18/17
to Firebase Google Group
Ping 0
380 ms, pong!

Ping 1
230 ms, pong!

Ping 2
254 ms, pong!

Ping 3
209 ms, pong!

Ping 4
385 ms, pong!

Ping 5
169 ms, pong!

Ping 6
162 ms, pong!

Ping 7
1463 ms, pong!

Ping 8
170 ms, pong!

Hey, i've made a small test that sets a field "ping" in the realtime database, a cloud function "processes", the ping, and sets a field "pong" in the database that the client is subscribed to. 

160-250ms is expected, but sometimes the function execution times are big, which in turn gives the user a high "ping" "pong" timing. 

Am I doing something wrong here, or is this expected?

Yours
  Mads Jon Nielsen

Cloud Function
/**
* A user has send a ping action.
*/
exports.onPingAction = functions.database.ref('/users/{uid}/action/ping/{refreshToken}').onWrite(e => {
const uid = e.params['uid'];
const refreshToken = e.params['refreshToken'];

return admin.database().ref(`/users/${uid}/response/pong/${refreshToken}`).set(e.data.val());
});


Client Code.
const uid = firebase.auth().currentUser.uid;
const refreshToken = firebase.auth().currentUser.refreshToken;
const pingKeys = {};
let pingKeyInc = 0;

const sendPing = () => {
if (firebase.auth().currentUser !== null) {
const pingKey = pingKeyInc++;
pingKeys[pingKey] = Date.now();
console.log(`Ping ${pingKey}`);
return firebase.database().ref(`/users/${uid}/action/ping/${refreshToken}`).set(pingKey);
} else {
return Promise.reject('You are not signed in');
}
};

firebase.database().ref(`/users/${uid}/response/ping/${refreshToken}`).on('value', (e) => {
const pongKey = e.val();
const ms = Date.now() - pingKeys[pongKey];
console.log(`${ms} ms, pong!\n`);
// Send new ping.
sendPing();
});


Doug Stevenson

unread,
Apr 18, 2017, 8:07:24 PM4/18/17
to Firebase Google Group
Firstly, please bear in mind that Cloud Functions is a beta product, and provides no SLA.  You can expect it to be a little rough around the edges before it exits beta.

Second, note that when a new node.js instance is created for an invocation of a function, there is naturally going to be some time lost to "cold start" of that invocation.  If and when that instance gets reused, that cost will no longer apply.  There may also going to be unpredictable variability in the network between your machine the server.  Basically, there can be hidden conditions that you can't predict that could affect the round trip timing.

Finally, it's hard to tell from your client code how often you're trying to ping.  As it's shown, it looks like it will do a single ping.  Is there a loop of some sort missing from what you're doing?

Doug

Mads Jon Nielsen

unread,
Apr 19, 2017, 10:53:23 AM4/19/17
to Firebase Google Group
firebase.database().ref(`/users/${uid}/response/ping/${refreshToken}`).on('value', (e) => {
    const pongKey = e.val();
    const ms = Date.now() - pingKeys[pongKey];
    console.log(`${ms} ms, pong!\n`);
    // Send new ping, when pong is received.
    sendPing();
});

// Send initial ping
sendPing();

Hey, Doug thanks for the answer.

I forgot the initial sendPing. 
After a pong, a new ping is sent.

Yeah, Kato told me about node instances spinning up and down. 
Only one client is pinging, so i'm wondering, why the instance is in fact spinning up and down causing 1463ms pings, shouldn't there always be one instance running?

I'm currently in the process of proving that Firebase will be suitable for a mobile app, we creating. 
Spikes in network traffic is usually a dealbreaker for my boss :-D

I guess i'll have to try setting up my own node servers on appengine using firebase-queue, unless anything can be done to circumvent this issue.

Doug Stevenson

unread,
Apr 19, 2017, 11:39:33 AM4/19/17
to fireba...@googlegroups.com
Don't make any assumptions about how many instances are alive at any given moment.  That's an implementation detail abstracted away by Google infrastructure.  But I will say that if you are pounding a single instance with traffic, doesn't it make sense for the infrastructure to spin up a second instance at some point in anticipation of further load from a second potential client that might be doing the same thing?

In any event, that is the tradeoff when using "serverless" infrastructure.  You don't think about or even know about instances at all - it just automatically scales up or down to meet demand.  If you do need to know or want to know about instances, it might be better to run your own.

Doug


--
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/muklfSitOho/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/fe18b927-e215-47dc-932f-f1921f8ecc65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages