程序员的自我修养
Home » 分类目录 » APNs

玄学出奇迹

1条评论1,216次浏览

2016-11-03开始,APNs HTTP/2 API速度突然变得奇慢无比,建立连接各种超时,handshake各种超时。50个channel的情况下每秒能发送的消息只有个位数。简直哔了狗了。

初步排除一番后,发现10台服务器当中只有5台服务出了上述问题,另外5台的发送速度居然比平常还要快。于是怀疑集团为了双十一把网络调整了,让pe联系集团网络部的查了一通,返回结果,并没有任何调整。

接着怀疑是不是这五台机器的硬件出问题了,又查了一通,发现并没有。

最后怀疑程序出问题了。为啥最后才怀疑程序?我这服务线上无故障跑了好几个月了,突然出问题,还是几台机器在同一时间出问题,打死我都不相信。结果也表示,程序没有任何异常。

最后只能让苹果背锅了,认定是苹果的APNs HTTP/2 API服务抽风了,和这5台服务器命中相克。于是只能将大部分发送任务放到老版本API上去,少部分流量放到APNs HTTP/2 API上,然后关闭了出问题的那5台机器。

经过3天的观察,发现之前认为没有问题的另外5台服务器居然也出现了同样的问题。又是各种查后无果。期间抓包发现居然有高达20%的网络重传。

就在我即将崩溃,准备裸奔释放情绪的时候。突然间无意的发现,貌似这些发送比较慢的任务的remote ip地址第三位比较集中。苹果服务器ip前两位是固定的17.188。而那些发送比较慢的第三位基本上都是12X、13X以及少量的14Y(y<4)。难道是巧合?于是把所以机器上的所有发送慢的任务的ip全部查了一通,发现居然没有一个反例。于是我不由自主的得出一个玄学结论:remote ip第三位比较小的(比如小于145)发送速度慢,大于145的发送速度快。为了验证我的猜想,我又把所有服务器上的所有发送速度快的任务查了一遍,发现卧了个槽,居然还是没有反例,没有一个例外能推翻我的玄学猜测。

然后我将所有的结果汇总,发现remote ip第三位小于等于142的速度奇慢,各种超时,而且没有例外。而第三位大于等于144的速度奇快。然后让pe那边分析了一下抓到的包,发现20%的网络重传也全部都是remote ip第三位小于等于142的ip。进一步证实了我的玄学猜测是正确的。

接下来,修改程序上线,不连接那些remote ip第三位小于等于142的。经过1天的观察,卧槽,真的没有一个慢的任务。

对此我只想说,玄学出奇迹。

至于为何会这样,我只能猜测要么苹果的这2组ip地址的服务器在不同机房,有一个机房出了问题;要么就是苹果在灰度测试新的服务,因为抛开那些发送速度离奇慢的任务,其他的任务发送速度都翻了2-3倍。然而苹果官网上找遍了也没有一个公告什么的。

什么是玄学?玄学就是,今天编程不宜面朝东面,不然bug多;今天不宜上线,不然服务必挂之类的迷信。
1

分类:APNs
标签:,

APNs http2接口速度调优

2条评论1,719次浏览

第一招:釜底抽薪

简介:通过去除无效devicetoken,本地减少发送数,来提高整个任务的发送速度。

有效性:视app决定,有的app卸载用户少,作用不明显,有的app卸载用户90%以上,效果杠杠的。

什么样的devicetoken是无效的,如何识别?简单来说apns返回发送失败时,reason内容为BadDeviceToken和Unregistered的可以判定成无效devicetoken。关于BadDeviceToken很好理解,而Unregistered又是个什么鬼?有如下测试:

  1. 关闭推送,1小时内发送消息,apns返回success,但是app没有收到消息
  2. 打开推送,在关闭期间发送的消息收不到,打开后的消息正常收到。devicetoken没有变化
  3. 关闭推送,第二天发送消息,apns返回success,但是app没有收到消息
  4. 第二天打开推送,在关闭期间发送的消息收不到,打开后的消息正常收到。devicetoken没有变化
  5. 卸载后,立马发送消息,apns返回Unregistered
  6. 重装后,生成新的deivcetoken,对老的deivcetoken发送消息,apns返回success,但是app没有收到消息;对新的deivcetoken发送消息,apns返回success,app收到消息

以上测试基于ios9,ios10还没测试。不过根据历史发送结果来看,Unregistered十有八九就是被卸载了。

第二招:调虎离山

简介:使用netty的发送程序,可以尽量将耗时的代码从EventLoopGroup中移出,或用线程来处理。

有效性:视代码时间开销而定。

最近在弄美国服务器进行发送速度的测试,测试结果后面说。过程中发现,读取/写入国内的redis速度慢的令人发指,导致发送速度不到10条/秒。于是将可以异步处理的写入redis放到线程中去处理了(读取直接删除,反正是测试)。结果发现速度突突突突突突的快。于是国内也将写入redis做了相同的处理,虽然速度提升不是太明显,但总体的感觉还是快了一些。之前想着读写redis肯定非常快,不会造成多少时间开销,但从结果来看还是不能想当然。

第三招:无中生有

其实和无中生有半毛钱关系都没有,只是三十六计里面找不到合适的随便选了个。

简介:提高发送的并行度。

  1. 单服务器模式下增加channel的个数。
  2. 大型任务则分发到多个服务器上去执行。至于如何实现调度、如何统计结果、如何处理子任务失败、如何处理长尾问题、如何处理XX问题就不在这里讨论了。

反正自从我实现完多机器并行处理一个任务后,再也没有开发者反馈我们发送速度慢了[大哭]。比如以前慢的时候40分钟、快的时候7分钟发送完的任务,现在变成快的时候90s、慢的时候10分钟。好想给我自己一个赞。

终级大招:走为上计

去美国搞台服务器,性能不用多牛逼,内存够用、cpu还行,虚拟机也可以,速度就是一个突突突突的快啊,同样的程序,速度是国内的10倍以上。还考虑什么分布式调度、考虑什么子任务单点失败、考虑什么长尾、考虑什么结果汇总,麦什么破、锐什么丢死,直接突突突突的单线程都比国内快,就是这么暴力。

最后

速度调优什么的最讨厌了,懒得弄?很简单,来用友盟push,分分钟带你突突突突。

怎么感觉变广告贴了,摔!

分类:APNs
标签:

APNS HTTP/2 client端遇到的坑

8条评论4,786次浏览

MAX_CONCURRENT_STREAMS

这个坑排查时间最长。苹果官方文档上没有关于settings的说明,但测试和生产环境中服务器返回的settings是settings={HEADER_TABLE_SIZE=4096, MAX_CONCURRENT_STREAMS=500, MAX_FRAME_SIZE=16384, MAX_HEADER_LIST_SIZE=8000}。而MAX_CONCURRENT_STREAMS=500的意思就是一个channel(就netty而言)最多同时并发500个stream。

若本地不限制stream的并发数,则会报错:Stream does not exist: $streamId。解决方法很简单,自己实现一个Channel进行计数即可。当服务器返回结果时调用decr()。

(更多…)

分类:APNs, Scala语言
标签:,
11
profile
  • 文章总数:81篇
  • 评论总数:241条
  • 分类总数:32个
  • 标签总数:45个
  • 运行时间:1253天

大家好,欢迎来到selfup.cn。

这不是一个只谈技术的博客,这里记录我成长的点点滴滴,coding、riding and everthing!

最新评论
  • Anonymous: :?: :razz: :sad:
  • Anonymous: 牛
  • Anonymous: 楼主你好,我偶尔也会 遇到Reconnect due to socket error: java.nio.channels.ClosedCha...
  • Anonymous: sdfs
  • Anonymous: :arrow: :neutral: :cry:
  • Anonymous: java.io.NotSerializableExcepti on: DStream checkpointing has been enabled but the DStreams with their...
  • wick: HI,请问一下,U,S,V得到 ,怎么得到近似矩阵 (用spark java),谢谢。
  • Michael Whitaker: Thank you for this blog, it was very helpful in troubleshooting my own issues. It seems that no...
  • Anonymous: :mad:
  • Anonymous: :???:
  • Anonymous: :mad: :mad: :mad:
  • 洋流: 哥们,我问个问题,你 把testOnborrow去掉了。。 如果得到的jedis资源...
  • 洋流: 哥们,我问个问题,你 把testOnborrow去掉了。。 如果得到的jedis资源...
  • Anonymous: :razz: :evil: :grin:
  • 张瑞昌: 有很多,比较常见的是 Jacob迭代法,一次迭代O (n^3),迭代次数不清楚 ...
  • Anonymous: :mrgreen:
  • lc277: 你好 我想问下一般删除节点 要多久,要删除的datano de大概用了1t,解除...
  • Anonymous: 你好 我想问下一般删除节点 要多久,要删除的datano de大概用了1t,解除...
  • Anonymous: :smile: :grin: :eek:
  • 李雪璇: 想要完整代码,可以帮 忙发给我吗