Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

strategy for tuning the hystrix configuration #866

Closed
igorsechyn opened this issue Aug 21, 2015 · 2 comments
Closed

strategy for tuning the hystrix configuration #866

igorsechyn opened this issue Aug 21, 2015 · 2 comments
Labels

Comments

@igorsechyn
Copy link

Hello,

first of all thank you for a great tool. I have recently started writing microservices for NodeJs and was searching for something similar in javascript. Although there are some options, none of them seemed to be complete or met my requirements. So I started an attempt of porting Hystrix to javascript and am trying to introduce it into our nodejs services and eventually into java services as well. One of the most frequent questions I get, is how to find the best configuration for commands in terms of timeouts, thresholds, etc... Is there some strategy behind it? Or is it just observing the behaviour in production and tuning the config based on the results?

Thanks a lot, Igor.

P.S. if you guys are interested in the js lib, it can be found here https://bitbucket.org/igor_sechyn/hystrixjs/overview. I would love to have some feedback.

@mattrjacobs
Copy link
Contributor

That's great, @igorsechyn ! I'll check out the HystrixJs port.

The specific question you asked is a good one (and common for us as well). This just came up in #862 (comment), so please check out the answer I gave there. Also, please see #131 for even more context.

I believe that there is more that can be done to solve this problem, but at the end of the day, it will always require some production data to accurately tune. Taking threadpool sizing as an example, without knowing the distribution of threadpool and queue utilization and the number of rejected tasks, you're left with a guess-and-check approach that walks through config space until you reach an optimal point. However, if you had those, you could very straightforwardly choose a desired % of thread pool rejections, then look at your distribution to find the proper sizing.

You should see some Github activity around metrics like those coming soon from me.

Also, as you productize your library and get experience with production traffic/tuning, any insights you can offer would be very welcome.

@igorsechyn
Copy link
Author

Thank you for a quick reply, @mattrjacobs. Those are really interesting topics, will definitely spend some time digging myself into it.

Will definitely post some feedback as soon as we have more insights.

cheers, Igor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants