@Rocketer 就是想知道这种评估方法是，这感觉只回答到第 2 点，缓存之类的要怎么估算呢？希望能再给些指点

@SorcererXW 那接口 qps 预估呢？

@fantastM 好的，感谢大佬！

@Jooooooooo 能否举些例子呢？

@liudaolunhuibl 请移步推广节点

@fantastM 太棒了，就是需要类似这样的回复！还有请问下，类似于 4k qps mysql 能不能扛得住，会不会报警这种问题，要怎么思考呢？

@iyaozhen 大佬可以简单回答一下，然后再把写好的文档分享一下~

@Maboroshii 压测确实是一个方案，但是肯定有分析技巧和套路的

@Maboroshii 就是那种用户量大的服务

@jmtung 卧槽，有这个 redis 的预估神器？它估算是怎么估算的？

@dream4ever 请问买的是哪几门课程呢？

@whcoding 公司自建机房

想要问题分析的思路和套路，阿里云并不能告诉我预计业务会增长多少 qps...

@tachikomachann 我知道肯定会有人说具体问题具体分析，但是问题都是是有分析方向的，就比如你怎么估计一个在服务首页下面增加一个功能入口，新业务增加多少 qps 呢？如果你通过接口监控，知道了这个首页的平均 qps 是 1000，运营告诉你，页面底部的点击率是 25%，那预计带来的 qps 就大约是 250qps，这个 qps 不算高，接口逻辑不复杂的话就能轻松扛过去等等

上面说的 转化率就是一个评估 qps 的方向。
导致性能瓶颈的问题有很多，但是排查瓶颈肯定是有套路的

至于你说学习大牛们做性能分析的思路，提出这个问题的我，就是希望能再这里收获一点思路。

感谢回复啦~

@BeautifulSoap 构建 query builder 是在 service 层构建吧？那构建完了我在 service 层直接 execute 这个 builder 不就可以了吗，还要扔到 repository 层？如果扔到 repository 层，那 repository 层只是简单执行并返回结果就好了，感觉有点怪怪的....

我感觉是不是应该是
```
// UserController 层
function List(req request) {
id = req.id
status = req.status
name = req.name
type = req.type
page = req.page
pageSize = req.page_size

res = userService.getUserList(id, status, name, type, page, pageSize)
return res
}

// UserService 层
function getUserList(id, status, name, type, page, pageSize) {

res = userRepository.getUserList(id, status, name, type, page, pageSize)
return res
}


// repository 层
function getUserList(id, status, name, type, page, pageSize) {
db = getDb() // orm 对象
if (id > 0){
db.where('id', id)
}
if (status > 0){
db.where('status', status)
}
if (name != ''){
db.like('name', '%' + name + '%')
}
.......
return db.orderBy(id, 'desc).limit(page, page_size).get()
}

```

其实是再想问下动态查询的时候，repository 层的代码要怎么写比较好

但是我又有另一个疑问是，多条件搜索的时候，case1 这种写法应该怎么写？比如用户管理后台，可以根据用户 id，姓名，状态，类型等进行搜索那就要写个 getUserList(id, name, status, type, page, page_size){ code... } 这样的函数?
@devld
@BeautifulSoap
@xiaoyiqingz
@simonlu9

@mcfog 但是我又有另一个疑问是，多条件搜索的时候，case1 这种写法应该怎么写？比如用户管理后台，可以根据用户 id，姓名，状态，类型等进行搜索那就要写个 getUserList(id, name, status, type, page, page_size){ code... } 这样的函数?

@mcfog 大概了解了