Still maintained, or meteor-down?

[dandv]

Just learned about @arunoda's meteor-down and wondering if this package is still maintained.

[arunoda]

I think it should not be [or].
Meteor Down is another attempt on load testing.
I'm sure this project still works, but our one is easy to use :D (I guess)

[alanning]

Hi Dan, we still use this to load-test our startup's product, Share911 so its still supported in that sense. It currently meets our needs so we aren't planning any extra features.

(MD = Meteor Down, MLT = Meteor Load Test)

A quick summary based on my understanding at the time of writing:

• I would agree with Arunoda that MD is easier to use
• Both MD and MLT use DDP to load the target site rather than spinning up VM's (good!)
• MD let's you define the calls and subscriptions in javascript rather than the JSON-style config that MLT requires
• MLT supports spinning up workers on different instances and aggregating results whereas I believe with MD all test instances run on the same box.
• MLT has a few more options re: authentication
• MLT lets you optionally download the initial payload as well
• MD has some metrics built-in (method and pub response times) whereas MLT expects you to use your existing metrics (kadira, cloudwatch, etc)
• MLT has some more options for shaping the load (worker spinup time and such)

@arunoda, please advise if I've misrepresented MD at all.

[arunoda]

Yes. You are all correct.
I need to add one on test scaling.

MD runs on a single server. But it can be converted to a node app with one
package.json file.

So with that, we used heroku to scale our load test. We generated around
100000 concurrent clients without spending a dime :)
On 2015 පෙබ 21, සෙන at ප.ව. 8.10 Adrian Lanning notifications@github.com
wrote:

Hi Dan, we still use this to load-test our startup's product, Share911
http://about.share911.com/ so its still supported in that sense. It
currently meets our needs so we aren't planning any extra features.

(MD = Meteor Down, MLT = Meteor Load Test)

A quick summary based on my understanding at the time of writing:

• I would agree with Arunoda that MD is easier to use
• Both MD and MLT use DDP to load the target site rather than spinning
  up VM's (good!)
• MD let's you define the calls and subscriptions in javascript rather
  than the JSON-style config that MLT requires
• MLT supports spinning up workers on different instances and
  aggregating results whereas I believe with MD all test instances run on the
  same box.
• MLT has a few more options re: authentication
• MLT lets you optionally download the initial payload as well
• MD has some metrics built-in (method and pub response times) whereas
  MLT expects you to use your existing metrics (kadira, cloudwatch, etc)
• MLT has some more options for shaping the load (worker spinup time
  and such)

@arunoda https://github.com/arunoda, please advise if I've
misrepresented MD at all.

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[arunoda]

I also need to add something on auth. We do have authentication support as
well.

We do it by installing a backdoor do the app. And it's activated via an env
variable. So, in the load test definition, just specify the userId to
authenticate the requests.
On 2015 පෙබ 21, සෙන at ප.ව. 10.11 Arunoda Susiripala <
arunoda.susiripala@gmail.com> wrote:

Yes. You are all correct.
I need to add one on test scaling.

MD runs on a single server. But it can be converted to a node app with one
package.json file.

So with that, we used heroku to scale our load test. We generated around
100000 concurrent clients without spending a dime :)
On 2015 පෙබ 21, සෙන at ප.ව. 8.10 Adrian Lanning notifications@github.com
wrote:

Hi Dan, we still use this to load-test our startup's product, Share911
http://about.share911.com/ so its still supported in that sense. It
currently meets our needs so we aren't planning any extra features.

(MD = Meteor Down, MLT = Meteor Load Test)

A quick summary based on my understanding at the time of writing:

• I would agree with Arunoda that MD is easier to use
• Both MD and MLT use DDP to load the target site rather than
  spinning up VM's (good!)
• MD let's you define the calls and subscriptions in javascript
  rather than the JSON-style config that MLT requires
• MLT supports spinning up workers on different instances and
  aggregating results whereas I believe with MD all test instances run on the
  same box.
• MLT has a few more options re: authentication
• MLT lets you optionally download the initial payload as well
• MD has some metrics built-in (method and pub response times)
  whereas MLT expects you to use your existing metrics (kadira, cloudwatch,
  etc)
• MLT has some more options for shaping the load (worker spinup time
  and such)

@arunoda https://github.com/arunoda, please advise if I've
misrepresented MD at all.

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[alanning]

Right, I saw the auth part. I didn't mean to say that MD does not support auth, just that MLT has more options there at this time. MLT performs an actual client login over DDP and supports username and password as well as OAUTH via use of resumeTokens.

This may be something you want to consider adding to MD as well as right now MD doesn't capture the load from clients connecting.

EDIT: By "connecting" in this case I mean the credential validation flow. I know MD captures the load from connected client's subscriptions and method calls.

[dandv]

@alanning, @arunoda - thanks for the comparison!

[arunoda]

Good idea.
On 2015 පෙබ 22, ඉරිදා at පෙ.ව. 3.00 Dan Dascalescu notifications@github.com
wrote:

@alanning https://github.com/alanning, @arunoda
https://github.com/arunoda - thanks for the comparison!

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[darrenangle]

@arunoda Can you describe your process for load testing using Heroku? Did you use it to create loads from multiple IP addresses? meteor-down is great, but we're hitting some limitations re: all of the load from a single IP. Any advice? Thanks for all your work.

[arunoda]

Yep. They should get from the same IP. But, that's okay for the testing
purpose.
Why that's going to be a problem?

On Wed, Jul 22, 2015 at 3:50 AM Darren Angle notifications@github.com
wrote:

@arunoda https://github.com/arunoda Can you describe your process for
load testing using Heroku? Did you use it to create loads from multiple IP
addresses? meteor-down is great, but we're hitting some limitations re: all
of the load from a single IP. Any advice? Thanks for all your work.

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[darrenangle]

I'm looking to test the autoscaling features of Modulus with a realistic test, but they send all traffic from the same IP to a single server, even under heavy load.

Makes sense, session redundancy across multiple, auto scaling servers is hard- but it would awesome to distribute the ddp/meteor-specific test with multiple ips to see how Modulus handles load balancing and scaling.

Other load testing solutions I've found can do get requests from all over the globe just fine, but I'd like the meteor-specific insight into the sub and method performance that meteor-down provides.

On Jul 21, 2015, at 7:43 PM, Arunoda Susiripala notifications@github.com wrote:

Yep. They should get from the same IP. But, that's okay for the testing
purpose.
Why that's going to be a problem?

On Wed, Jul 22, 2015 at 3:50 AM Darren Angle notifications@github.com
wrote:

@arunoda https://github.com/arunoda Can you describe your process for
load testing using Heroku? Did you use it to create loads from multiple IP
addresses? meteor-down is great, but we're hitting some limitations re: all
of the load from a single IP. Any advice? Thanks for all your work.

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

—
Reply to this email directly or view it on GitHub.

[arunoda]

Yes. This is a not a so called load testing service :)
So, here's my idea then.

Use modulus instead of heroku to do the test. Do it with multiple apps.
Then, use choose each to app to use different data center.

On Wed, Jul 22, 2015 at 7:27 AM Darren Angle notifications@github.com
wrote:

I'm looking to test the autoscaling features of Modulus with a realistic
test, but they send all traffic from the same IP to a single server, even
under heavy load.

Makes sense, session redundancy across multiple, auto scaling servers is
hard- but it would awesome to distribute the ddp/meteor-specific test with
multiple ips to see how Modulus handles load balancing and scaling.

Other load testing solutions I've found can do get requests from all over
the globe just fine, but I'd like the meteor-specific insight into the sub
and method performance that meteor-down provides.

On Jul 21, 2015, at 7:43 PM, Arunoda Susiripala <
notifications@github.com> wrote:

Yep. They should get from the same IP. But, that's okay for the testing
purpose.
Why that's going to be a problem?

On Wed, Jul 22, 2015 at 3:50 AM Darren Angle notifications@github.com
wrote:

@arunoda https://github.com/arunoda Can you describe your process
for
load testing using Heroku? Did you use it to create loads from
multiple IP
addresses? meteor-down is great, but we're hitting some limitations
re: all
of the load from a single IP. Any advice? Thanks for all your work.

—
Reply to this email directly or view it on GitHub
<
#11 (comment)

.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[darrenangle]

Thanks @arunoda.