第一招:釜底抽薪
简介:通过去除无效devicetoken,本地减少发送数,来提高整个任务的发送速度。
有效性:视app决定,有的app卸载用户少,作用不明显,有的app卸载用户90%以上,效果杠杠的。
什么样的devicetoken是无效的,如何识别?简单来说apns返回发送失败时,reason内容为BadDeviceToken和Unregistered的可以判定成无效devicetoken。关于BadDeviceToken很好理解,而Unregistered又是个什么鬼?有如下测试:
- 关闭推送,1小时内发送消息,apns返回success,但是app没有收到消息
- 打开推送,在关闭期间发送的消息收不到,打开后的消息正常收到。devicetoken没有变化
- 关闭推送,第二天发送消息,apns返回success,但是app没有收到消息
- 第二天打开推送,在关闭期间发送的消息收不到,打开后的消息正常收到。devicetoken没有变化
- 卸载后,立马发送消息,apns返回Unregistered
- 重装后,生成新的deivcetoken,对老的deivcetoken发送消息,apns返回success,但是app没有收到消息;对新的deivcetoken发送消息,apns返回success,app收到消息
以上测试基于ios9,ios10还没测试。不过根据历史发送结果来看,Unregistered十有八九就是被卸载了。
第二招:调虎离山
简介:使用netty的发送程序,可以尽量将耗时的代码从EventLoopGroup中移出,或用线程来处理。
有效性:视代码时间开销而定。
最近在弄美国服务器进行发送速度的测试,测试结果后面说。过程中发现,读取/写入国内的redis速度慢的令人发指,导致发送速度不到10条/秒。于是将可以异步处理的写入redis放到线程中去处理了(读取直接删除,反正是测试)。结果发现速度突突突突突突的快。于是国内也将写入redis做了相同的处理,虽然速度提升不是太明显,但总体的感觉还是快了一些。之前想着读写redis肯定非常快,不会造成多少时间开销,但从结果来看还是不能想当然。
第三招:无中生有
其实和无中生有半毛钱关系都没有,只是三十六计里面找不到合适的随便选了个。
简介:提高发送的并行度。
- 单服务器模式下增加channel的个数。
- 大型任务则分发到多个服务器上去执行。至于如何实现调度、如何统计结果、如何处理子任务失败、如何处理长尾问题、如何处理XX问题就不在这里讨论了。
反正自从我实现完多机器并行处理一个任务后,再也没有开发者反馈我们发送速度慢了[大哭]。比如以前慢的时候40分钟、快的时候7分钟发送完的任务,现在变成快的时候90s、慢的时候10分钟。好想给我自己一个赞。
终级大招:走为上计
去美国搞台服务器,性能不用多牛逼,内存够用、cpu还行,虚拟机也可以,速度就是一个突突突突的快啊,同样的程序,速度是国内的10倍以上。还考虑什么分布式调度、考虑什么子任务单点失败、考虑什么长尾、考虑什么结果汇总,麦什么破、锐什么丢死,直接突突突突的单线程都比国内快,就是这么暴力。
最后
速度调优什么的最讨厌了,懒得弄?很简单,来用友盟push,分分钟带你突突突突。
怎么感觉变广告贴了,摔!
另外BadDeviceToken: 什么情况下会导致这个啊
可能苹果最近又改变了返回值吧,最近没做测试了。
BadDeviceToken一般测试环境和正式环境弄错的情况下会出现。