队列处理的一次优化实践 (Yaf Worker Manager)

  1. workermanager的一些优化
  2. 配置文件
  3. 命令行参数=>配置文件
  4. 还有什么疑惑?
  5. 参考,希望对你也有帮助:
  6. 最后

队列处理的一次优化实践--让队列给我们带来更多性能提升(Yaf Worker Manager)

先上出队列的worker性能测试结果:

powered by echarts.baidu.com

php进程数 job数量 处理time 效率
1 5366   359sec 14 jobs/sec
10 5366   45sec 119 jobs/sec
50 5366 14sec 383 jobs/sec

无论如何,此次beanstalkd消息队列带来的性能提升是非常明显的,要知道,在优化之前,短信应用的到达率很低很低,使用队列的结果就是很稳定,很高效,甚至是能取得皆大欢喜的结果,甚是欣喜。

workermanager的一些优化

接下来是对现有beanstalk worker manager的一些改进,首先要说的是现在典阳所做的从gearmanManager扩展过来的workerManager已经非常优秀:

yaf + worker manager 在编写的时候考虑到的因素:

现有的配置情况是和beanstalk混合在一起的,在worker数量越来越多的情况下,还是有点混乱的:
beanstalkd.ini

[WorkerManager]
; beanstalkd servers
host = 127.0.0.1:11300
[WechatRefundQuery]
; We are guaranteed 1 workers that can do job Paygw
count = 0
timeout = 5
service=WechatRefundQuery
[Sms]
; We are guaranteed 1 workers that can do job Sms
count = 10
timeout = 5
service=Sms

在现有的基础上,需要增加环境文件,也就是不同环境的应用文件,就像yaf的application.ini一样:
sms.ini

[common]
; We are guaranteed 1 workers that can do job Sms
count = 1
timeout = 5
service=Sms
[develop]
; We are guaranteed 1 workers that can do job Sms
count = 0
timeout = 5
service=Sms
[qa]
; We are guaranteed 1 workers that can do job Sms
count = 0
timeout = 5
service=Sms
[online]
; We are guaranteed 1 workers that can do job Sms
count = 10
timeout = 5
service=Sms

在考虑这样的变化的时候,我们还需要考虑配置文件的加载顺序,谁先加载谁的问题,比如现有的想法,
如果worker在启动的时候就将配置文件加载了进来(包括beanstalkd和service),并且,在修改配置文件的情况下需要重启worker。(修改worker业务代码的情况是不需要重启worker的,因为她会自动检测新代码改动),
这样,worker必然加载在application 之前,也就是

这样的变化,需要在workerManager启动的时候将相应环境的队列服务配置文件都加载进来,之前在Application 中是bootstrap 来完成的,但是在这个地方,应该也不会有太大的困难,我们试着开个分支实现以下:

配置文件

并且我发现,其实在配置文件中,还多写了和配置节名相同的service名称配置,其实这是不必须的。所以也可以下下刀子。

[develop]
; We are guaranteed 1 workers that can do job Sms
count = 0
timeout = 5

命令行参数=>配置文件

public funtion run($config = array())
public funtion getopt($config = array())

本函数中的参数$config即为命令行参数,这个文件现在是作为启动守护进程时的参数进行传递的,看这个情况,完全可以在这个位置就传递进去,然后和其他的配置文件合并。

当为run函数传递一个命令行的配置文件时,日志却打印不出来了

YafWorkerManagerfor beanstalkd

抽象的WorkerManager和扩展的workerManager两个类文件其实在注册本地类库之后其实并没什么其他的作用,就像其他在global中的类库一样,所以还是非常可以考虑把他们移到global中去,另外一个需要这样做的原因是我们在worker的处理也只是对beanstalkd-worker-manager.php的操作。

现在先实现能在本地中将worker加载出来的情况,如果可以的话,可以考虑将抽象的WorkerManager和扩展的workerManager两个类文件移到全局类库(yaf).

还有什么疑惑?

同时需要考虑的其他问题有:一台机器上面实例化了两个相同的Yaf Application,这个时候会不会有影响。

最后,无论如何我们现在始终在应用的使用阶段,但是相信离自己的基础组件已经不远了。

echarts代码:

option = {
title : {
text: '队列处理短信发送测试图',
subtext: '横轴为进程数,job总数:5366'
},
tooltip : {
trigger: 'axis'
},
legend: {
data:['耗时','效率']
},
toolbox: {
show : true,
feature : {
mark : {show: true},
dataView : {show: true, readOnly: false},
magicType : {show: true, type: ['line', 'bar']},
restore : {show: true},
saveAsImage : {show: true}
}
},
calculable : true,
xAxis : [
{
type : 'category',
data : ['1','10','50']
}
],
yAxis : [
{
type : 'value'
}
],
series : [
{
name:'耗时',
type:'bar',
data:[359, 45, 19],
},
{
name:'效率',
type:'bar',
data:[14, 119, 383],
}
]
};

参考,希望对你也有帮助:

https://github.com/brianlmoon/GearmanManager

最后

为了看今晚的欧冠半决赛巴萨对阵拜仁的比赛,彻夜编码也是拼了。。。

script>