Promises to enable clean load test scripts as complexity increases

[convexset]

The following changes were made:

• Added Meteor.apply (via Client.prototype)
• Added Meteor.call_GetPromise (via Client.prototype)
• Added Meteor.apply_GetPromise (via Client.prototype)
• Added Meteor.subscribe_GetPromise (via Client.prototype)

The Promise methods enable more complicated load tests. For instance, for the simple todos example, a good load test would:

• start subscriptions to get all lists
  • one for public lists
  • another subscriptions for private lists
• for each list so obtained, subscribe to the list items

This implies a level of asyncrony that vanilla Meteor.subscribe with callbacks cannot provide for. The same applies for methods. What we need are simple promises. So here is the described load test for Meteor's todos example:

LoadTester.addTask('get-all-data', function(Meteor, complete) {
    Promise.resolve()
        .then(function() {
            // Subscribe to both public lists and private lists
            return Promise.all([
                new Promise(function(resolve, reject) {
                    Meteor.subscribe('publicLists', function() {
                        resolve();
                    });
                }),
                Meteor.subscribe_GetPromise('privateLists')
            ]);
        })
        .then(function() {
            // For each available list, subscribe to the contents of each list
            return Promise.all(
                Object.keys(Meteor.collections.lists).map(
                    id => Meteor.subscribe_GetPromise('todos', id)
                )
            );
        })
        .then(function() {
            // Report what was done and complete task
            console.log(Object.keys(Meteor.collections.todos).length + ' todos from ' + Object.keys(Meteor.collections.lists).length + ' lists downloaded.');
            complete();
        });
});

Don't mind the LoadTest object and the complete method. It's part of a "quickstart" I've been goofing around with.

[arunoda]

I like this.

[arunoda]

Will merge soon.

[convexset]

cool

[convexset]

Would you be open to including a bit more syntactic sugar in meteor-down?

Stuff such as:

• packaging operations into tasks
• managing precedences
• controlling the number of concurrent activities (e.g.: at most two concurrent "heavy methods" where there are 10, possibly different, items in the "heavy method" categoy)

I rolled a lot of that into a "quickstart" for meteor-down:

https://github.com/convexset/meteor-down-quickstart

It's more of a distro. since underscore and lodash are packed in to make it a real "quick start". Playing with that has led to me thinking about proper "operations orchestration" in load testing.

I see the whole "operations orchestration" thing as useful for load testing, because for me, load testing is all about playing out use cases. Some of this was implemented a long time ago in a meteor package (some of it is ugly, first few months as a JS developer).

Perhaps things could be extended into "demographically realistic" load testing to "sample" use cases (with given probabilities).

What do you think about including this stuff in meteor-down?

[rhyslbw]

Any update on this?

[krishaamer]

This looks awesome!

[santiq]

This is great!