TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Chef Part 2 - Performance

21 pointsby matan_aabout 12 years ago

2 comments

druiidabout 12 years ago
To me this seems kind of like what I was afraid of way-back-when, when choosing a CM system. I eventually went with Puppet because basically I was afraid of this kind of thing happening. Because Chef uses Ruby for the configuration language this seemed to me both an advantage and a huge disadvantage.<p>Basically, Chef is giving you enough rope etc. With Puppet at least, you CAN get into trouble and make your manifests take these kinds of length of time to compile, but it's relatively difficult. Additionally, I believe the equal of 'searching' in Chef is PuppetDB. In my experience at least, resolving stored facts from PuppetDB is extremely fast, as in, fast enough that you don't know it's actually doing much of anything on a database level.<p>Really I think the take-away from this is be careful what you do with CM. It could end up making more, not less work for you!
评论 #5420829 未加载
macrosabout 12 years ago
There is a partial_search available with chef server 11 that makes this problem much less painful. Search returns the entire node object for each match, which can be a ton of data as the node count rises. With partial_search you specify just the attributes that you to be returned.