TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Chef Part 2 - Performance

21 点作者 matan_a大约 12 年前

2 条评论

druiid大约 12 年前
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 未加载
macros大约 12 年前
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.