两台机器实现QPS3000的服务优化

服务流程：

输入为一句话，分词、匹配百科词条，读redis过滤、从redis读词条summary信息、返回

需求：

业务方的峰值QPS为3000

按照之前相关百科的一套逻辑：单机tornado服务进程数4个

模拟10个并发，压测的QPS为332，响应时间为30ms

$siege -c10 -r5000 -f urls.lst

Transactions:               10000 hits
Availability:              100.00 %
Elapsed time:               30.05 secs
Data transferred:            3.31 MB
Response time:                0.03 secs
Transaction rate:          332.78 trans/sec
Throughput:                0.11 MB/sec
Concurrency:                9.75
Successful transactions:       10000
Failed transactions:               0
Longest transaction:            0.65
Shortest transaction:            0.00

模拟20个并发

$siege -c20 -r5000 -f urls.lst

Transactions:               20000 hits
Availability:              100.00 %
Elapsed time:               58.39 secs
Data transferred:            6.72 MB
Response time:                0.06 secs
Transaction rate:          342.52 trans/sec
Throughput:                0.12 MB/sec
Concurrency:               19.77
Successful transactions:       20000
Failed transactions:               0
Longest transaction:            0.41
Shortest transaction:            0.00

压测的QPS跟刚才几乎差不多，但是响应时间已经上升到了60ms，可见，此时服务已经处理不过来了，大量的请求是处理等待状态的，然而20个并发在业务方来说应该还算少的

优化策略：

第一步：

先增加服务进程数，将单机的服务进程从4提高到10

压测：

$siege -c20 -r5000 -f urls.lst

QPS为700，此时的response time是30ms

Transactions:               20000 hits
Availability:              100.00 %
Elapsed time:               28.26 secs
Data transferred:            6.72 MB
Response time:                0.03 secs
Transaction rate:          707.71 trans/sec
Throughput:                0.24 MB/sec
Concurrency:               19.47
Successful transactions:       20000
Failed transactions:               0
Longest transaction:            0.35
Shortest transaction:            0.00

第二步：

减少词表的数量

词表是百科所有词条的title和词条id的映射关系，总量为2300w，因为这个需求只要求PV大于75000的才返回结果，所以词表也按照这个条件进行过滤，过滤后，词表只剩下了13w

再次压测：

$siege -c20 -r5000 -f urls.lst

可以看到QPS提高到了1081， response time降低到了20ms

Transactions:               20000 hits
Availability:              100.00 %
Elapsed time:               18.50 secs
Data transferred:            5.84 MB
Response time:                0.02 secs
Transaction rate:         1081.08 trans/sec
Throughput:                0.32 MB/sec
Concurrency:               19.67
Successful transactions:       20000
Failed transactions:               0
Longest transaction:            0.09
Shortest transaction:            0.00

第三步：

对query做缓存

因为query都是短文本，根据业务方的反馈，会存在大量的重复的query，所以对query做缓存肯定会起到效果

具体策略：

对query分词，分词后拼接，并计算md5值作为缓存的key， query对应的返回结果作为value缓存到redis中

因为有缓存，所以这个压测不太好测，而且我们暂时也没有线上真实的数据，所以这里无法给出压测的结果，但是效果应该会很好

目前可以大概预估下，加了缓存后，单机的QPS应该能到1500，那么部署两台机器就可以满足需求了

两台机器实现QPS3000的服务优化

猜你喜欢