meteor-load-test
meteor-load-test copied to clipboard
alanning
Still maintained, or meteor-down?
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)
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.
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 [email protected] 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 https://github.com/alanning/meteor-load-test/issues/11#issuecomment-75374343 .
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 < [email protected]> 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 [email protected] 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 https://github.com/alanning/meteor-load-test/issues/11#issuecomment-75374343 .
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.
Good idea. On 2015 පෙබ 22, ඉරිදා at පෙ.ව. 3.00 Dan Dascalescu [email protected] 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 https://github.com/alanning/meteor-load-test/issues/11#issuecomment-75393919 .
@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.
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 [email protected] 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 https://github.com/alanning/meteor-load-test/issues/11#issuecomment-123496512 .
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 [email protected] 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 [email protected] 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 https://github.com/alanning/meteor-load-test/issues/11#issuecomment-123496512 .
— Reply to this email directly or view it on GitHub.
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 [email protected] 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 < [email protected]> 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 [email protected] 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 < https://github.com/alanning/meteor-load-test/issues/11#issuecomment-123496512
.
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/alanning/meteor-load-test/issues/11#issuecomment-123530353 .