上海城市精神：海纳百川、追求卓越、开明睿智、大气谦和
您现在的位置： >
智能床垫实时监测父母健康 记录分析睡眠数据
　　看着的不容易，相信大家都有自己的愿望，以后"我"一定要……孝心来不及等待，虽然岁数大了，但依旧在为子女操劳，可能身体有些伤病也从未向子女提起，不是他们能忍受，而是不想让女子有太多的牵挂。是时候关心下了，或许这个床垫可以为您提供不少帮助。
不要"以后" 床垫健康
　　这款漫活床垫可连续不间断监测使用者的心跳频率、呼吸频率、翻身动作、离床/在床等生理体征信息，构建个人的健康数据中心；历史数据永久云端存储，可随时随地查看使用者历史记录，便于就医问诊看号；当用户心跳、呼吸频率过高或过低时，设备可基于短信的形式推送到您的手机上，有助于看护家人健康；如果长时间卧床同样会发出提醒；健康知识、就医信息、用药常识等定期推送给您；好友添加，可随时查看对方健康数据。
目前该产品已经登录众筹，最低众筹价格为1980元，有兴趣的朋友可以多多了解。
侬好上海由新民网出品微信号：helloshanghai2013
吃喝玩乐、上海故事、同城活动每天热爱上海多一点，加入小侬家族就对啦！
新民晚报官方微信微信号：xmwb1929
有用、有益、有趣
街谈巷议微信微信号：xinminwangshi
街头访谈，麻辣点评
新闻热词榜
数据加载中……
吃完再也不怕冻手冻脚啦！
又到年底，元旦、春节在即，又将迎来一个出境旅游高峰。如今，旅游已...
好了，不管你有气质没气质，豪小编只想说一句：有话好好说！别自拍
李燕萍6年如一日悉心关爱外来脑瘫儿童
寒冷的冬季已经来临，北京也再次迎来了雨雪天气。随着气温的骤降，您...
新民晚报官方网站
All rights reserved| | | | | | | | | | | | |
OnlyLady移动版
扫一下你距离潮咖只有这一步
OnlyLady官方微信
有趣有范儿 全屏新风尚
Jawbone大数据分析报告：中国睡眠情况调查
Jawbone一直致力于帮助UP用户改善睡眠质量。睡眠是身体健康极为重要的一部分，充足的睡眠有助于改善记忆力和创造力，减轻体重和缓解压力，取得更加优秀的学习成绩，还可以延长寿命。我们在分析睡眠汇总数据时，发现其……
中国拥有13.5亿人口，是世界上人口最多的国家，陆地面积居世界第二位。其领土横跨60多个经度，约占地球横向跨度的1/6。中国还采用统一的标准时区&北京时间。例如，在立冬当天（12月21日），东北城市哈尔滨的日出时间是7:11，日落时间是15:51。西部城市乌鲁木齐的日出时间是9:40，日落时间是18:35。而南部城市，比如香港，日出时间为早晨 6:58，日落时间为17:44，白天相比而言较长。这对不同城市居民的睡眠质量会产生怎样的影响呢？
平均就寝时间
在这张图表中，我们可以看到地理位置和太阳高度对平均就寝时间的影响。在中国的最东端，日落时间早，平均就寝时间为23:00。在西部和南部地区，日落时间晚，就寝时间为凌晨 1:00 以后。所以，我们身体的新陈代谢，也就是调节我们日常行为习惯的化学反应，与太阳调节时点之间有着密切的关系。
再来看看城市数据。我们在之前的研究中得出过一个结论：世界各大主要城市每晚的平均睡眠时间均不足7小时，中国的数据也印证了这一结论。西藏首府拉萨的睡眠时间最短，平均每晚6小时22分钟。也许是因为这里海拔高达3,600米，易使人缺氧，而缺氧对会睡眠产生负面影响。东部城市苏州的睡眠时间最长，平均每晚6小时45分钟。附近的无锡平均睡眠时间也长达6小时43分钟。
此外，不仅各个城市的平均睡眠时间存在差异，就寝时间和起床时间也大不相同。东部城市哈尔滨最早入睡、最早醒来，就寝时间和起床时间分别为 23:27 和 6:58。起床时间最晚的是西部城市乌鲁木齐，平均起床时间为上午 8:29。其次是南部城市香港和澳门，就寝时间为00:30以后，起床时间约为上午8:00。我们的睡眠不仅受地理位置的影响，还受居住地文化和特征，以及我们自身因素的影响。
全年睡眠异常情况
最后，我们来观察一下全年的睡眠变化。该图表显示了中国所有UP用户全年的就寝时间、起床时间和夜间睡眠总时间的变化情况。由此我们也会发现节假日或其他活动对人们睡眠时间的影响。
1、年度无眠夜之最&&世界杯总决赛。日至7月13日世界杯期间，中国UP用户的睡眠出现明显异常。世界杯总决赛&德国与阿根廷的对战于北京时间7月14日凌晨3点开始，中国UP用户当晚的平均睡眠时间比平时减少了31分钟，是中国一年之中睡眠时间减少最多的一晚。
2、就寝时间最晚&&跨年夜和除夕。中国在跨年夜和除夕的就寝时间最晚，分别为00:42 和00:59。除夕还会上演全球最盛大的电视广播节目&&CCTV春节联欢晚会。约八亿人会与自己的家人一起守岁，观看演出，迎接新年。
3、特殊工作日。为弥补国庆节假期占用的工作日，中国将部分周六和周日指定为&特殊工作日&，纳入工作日当中。像十月初的&国庆节黄金周&这样的假日能够帮助人们补充睡眠。但是，黄金周前后的两个休息日变成了特殊工作日，也就是9月28日星期天和10月11日星期六。在这两天中，人们的睡眠时间相比平时的休息日短。
4、光棍节，中国的&网络星期一&购物节。二三十岁的单身男女参加相亲和卡拉OK活动，以此来庆祝11月11日光棍节（名副其实！）。2009年，阿里巴巴于当天发起优惠促销活动。到2014年，已经发展成为销售额达93亿美元的促销盛会（2013年美国&网络星期一&购物节销售额为18亿美元）。人们会在 11月 10日熬夜等待在线促销活动。
通过以上对中国UP用户睡眠模式的研究，我们也可以了解很多中国地理和文化方面的趣事。
技术说明：该研究的数据来自于成千上万名使用Jawbone UP产品追踪自己睡眠的用户。人口较少地区会并入相邻地区，从而得出这些重要的结论。该技术的研究结果比省级研究更加精确。因为总睡眠时间不包括躺在床上但没有入睡的时间（入睡时间和夜间苏醒时间），所以就寝时间和起床时间之差大于总睡眠时间。统计过程中，所有数据均为匿名，且以合计形式呈现。
原文链接：/blog/sleep-china/?locale=cn
布瑞&威尔特
首席数据科学家
布瑞热爱跑车和优质数据。在Jawbone，他坚持&让数据说话&的理念。
他还是一名儿童排球教练。
详情请关注：@brianwilt。（本文系onlylady独家原创内容，未经允许不得转载）
我要分享：
您觉得这篇文章 ：
OnlyLady移动版
距离潮咖只有这一步
微信关注OnlyLady
福利天天撒
OnlyLady官方微信
2015年春季，YOGA 3 Pro发布糖果粉、薄荷绿两款全球限量多彩版笔记本，在产品性能不减的同时，清
安全提问：
0) {$('#loginanswer_row_L9KF9').show();} else {$('#loginanswer_row_L9KF9').hide();}" name="questionid" width="213" id="loginquestionid">
安全提问(未设置请忽略)
母亲的名字
爷爷的名字
父亲出生的城市
你其中一位老师的名字
你个人计算机的型号
你最喜欢的餐馆名称
驾驶执照最后四位数字
输入下图中的字符
快速登录：
最新推荐What's New
相关视频Related Video
精彩专栏Experts
热点专题HOT TOPIC
达人专栏Experts3054人阅读
这里所说的程序是指对外提供tcp/ip交互协议的服务性程序。网络程序性能分析很重要，比如随着网络请求流量越来越大，我们需要知道已部署的服务能不能满足需求。这里采用对网络服务程序进行建模的方法分析影响程序性能的各要素，并计算相关性能值，它不够精确，但对我们使用其它工具对网络程序进行性能测试提供很好的理论指导。
１．网络请求
& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & 图1
什么是网络请求？如图1是《UNIX 网络编程》一书中表示网络交互过程的一幅图，整个请求是指从客户端到服务端 write-&read-&write-&read的一个过程。对于服务端需要关心的是read-处理-write的过程。
connect相关操作在此是忽略的，因为其对服务端性能并没有什么影响。
一个请求中，在服务端read可能进行多次，如http协议中，我们可能先要读取头部信息，然后再读取一次数据实体，对于一个请求更为精确的定义是：
把相邻的操作都合并，如多次连续read合并为一个，从一个read开始到下一个read开始的过程即为一个请求。
在一个长连接里就可以发生多个请求，因为有多个read-处理-write过程
服务端的请求处理过程总结如下：
1.从网络接口读取数据
2.处理请求
3.将处理结果发送至网络接口
２．性能指标
这里参考&&High Performance MySQL&& 一书 38页对于相关性能值的解释说明，本人即看此书看到这里时想到要写本文。
吞吐量：每秒处理的请求数(事务数),请求定义见上节
响应时间(延迟)：请求处理响应时间,对于服务端来说即一个read-处理-write流程的时间。下面会使用响应时间和延迟两种说法，意义一样。
并发度：某一刻处于请求处理过程的请求数。如图2所示，不同请求处于不同的处理过程，竖着的红线表示当前时刻的时间线，与时间线相交的请求数目即为并发度。
可伸缩性：作者的意思应该是别把系统的所有资源用到极限，要留有一定余地，以使整个系统具有可伸缩性，预防可能突然增大的请求流量。接下来的性能值计算都以极限值为标准，但实际使用过程中，不能让服务的性能值处于极限值上。
& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & 图2
３．性能函数表达式
吞吐量 = f1(CPU能力，CPU个数，磁盘IO能力，网络带宽能力，请求处理模型，网络流量，CPU计算时间，磁盘IO量，进程数)
响应时间 = f2(CPU能力，CPU个数，磁盘IO能力，网络带宽能力，请求处理模型，网络流量，CPU计算时间，磁盘IO量)
并发度 = f3(客户请求量，请求处理模型,
吞吐量，响应时间)
红色：正相关
绿色：负相关
硬件变量： CPU能力，CPU个数，磁盘IO能力，网络带宽能力（难以控制）
软件变量：请求处理模型，网络流量，CPU计算时间，磁盘IO量（控制难度中等）
参数变量：进程数，系统软件参数（较易控制）
对于任一单一变量来说，在其它变量值固定的情况下，它都有一个最大（小）值，超过这个最大(小)值，性能计算指示的值不随它的值变大（小）而变化，这是其它某个变量达到了瓶颈值，例如I/O能力有限的情况下，再怎么提高进程数对吞吐量也没用，我们将这种情况称为软限制。另外一些变量有一些限制值，该变量的值不可能超过该值，比如同时运行的进程数受限于CPU的个数，我们将这种情况称为硬限制。软限制由硬限制引起，当然对于某一组变量来说不存在如上限制的情况。
网络延时及连接队列长度不会影响性能量度，因为这两个变量从逻辑上讲跟网络服务程序的处理过程无关。网络延时是请求开始及完成后中间的信息传输过程，连接队列只是请求正式开始前一个暂存的机制。
４．硬件建模
相关硬件一个时刻只能给一个进程使用，除非有多个硬件设计如CPU才能实现同一时刻的并发，资源不够时需要等待。
CPU:每一个进程顺序执行指令,多个CPU可以并发。CPU使用率达到100%，进程可能有等待。
磁盘I/O : 多个进程I/O需要进行排队。假设需要的时间只根据读取或写入的数据量有关，不考虑寻道时间等。有可能出现IO等待
网络I/O:&多个进程I/O需要进行排队，也假设网络I/O的时间只跟要读取或发送的数据量有关。有可能出现IO等待
内存:&对于性能影响较小，往往只是作为磁盘的缓存来使用，加速磁盘I/O，对性能分析无益，可以忽略。
能力值
CPU　　　　　　
H1　　　　
N1　　　　　
个　　　　　
５．软件数据
&对于每一个请求来说，相关数据量如下：
执行指令数
磁盘I/O量　　　　
S2　　　　　
K　　　　　
６．请求处理模型
最普通的请求模型是，每个进程从队列取得连接，然后等待读取数据，然后执行CPU计算，然后进行I/O处理,然后写回数据,CPU计算与磁盘I/O往往是交叉进行，不过将其统一成两个不两阶段，不影响性能值计算，另外网络的读写也合并在一起。
各执行阶段可用图表示如下：
& & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & & &图3
我们还有一些基本假设：
1.连接队列总有有可以读取的连接，即让客户端请求的吞吐量大于或等于服务端的吞吐量，以测试服务端的极限性能，让客户端的请求不至于成为瓶颈。
2.每个请求都是完全相同的，这是为了简化性能计算，并且不影响分析结果。
3.从连接列表获取连接后，马上进行读数据，读取时间只跟网络整体带宽有关。
７．如何计算并发度
基本计算规则： &根据并发度的定义，以其中一个请求为标准，并发度即该请求从开始到结束期间，从连接队列新拿到的连接数（只要离开了连接队列，我们就认为其进入了read-write处理中，跟上述假设3是吻合的）。抽象成公式如下：
并发度 = &请求处理时间*吞吐量
再以图形描述下上面的公式。如下图，横线的表示一个请求处理过程，长度为处理时间，假设A点表示处理起始点，B点是结束点，随着时间进行，所有横线以一定速度往右行走，左结点穿过B线表示相应请求完成，那横线左结点穿过B竖线的速度即为吞吐量，再假设吞吐量在处理各阶段保持不变，那横线进入A竖线的速度也应该等于吞吐量，于是一个请求的时间内进入A竖线的请求数为 ：请求处理时间*吞吐量
& & & & & & & & & & & & & & & & &　　　　　　　　　　　　 图 4
但如果各个处理阶段吞吐量不同的话，吞吐量取最大值，更精确的公式如下：
并发度 = &请求处理时间* max(吞吐量1,吞吐量2…吞吐量n)
８．如何计算进程数
基本计算规则: &类似于并发度的计算规则，对于同一处理类型的进程来说，以某一个进程为标准，从开始到结束期间，新进入的需要处理的事件即需要的进程数。如果对一个请求有不同类型的处理阶段，且由不同进程处理，所需要的进程数是不同阶段进程数相加:
进程数 = 阶段1处理时间*阶段1吞吐量+阶段2处理时间*阶段2吞吐量+…阶段n处理时间*阶段n吞吐量
如果一个请求完全由一个进程处理，即两者完全绑定，则: 进程数 = 并发度
９．如何计算延时
延时是不同处理阶段延时的相加，如之前所述的三个阶段：
请求总的耗时 = 网络耗时+CPU执行耗时+磁盘I/O耗时
网络耗时: &根据网络距离、数据传播速度计算网络耗时在这里显得没有意义，我们只想得出各变量之间的关系，所以我们定义单位带宽单位数据量的耗时为X,可以得出网络耗时为 &X*S3/H3
这里有个前提是接入带宽越高，同一请求的数据传播也越快，事实上这也跟整个网络的带宽有关。
CPU执行耗时: & 即使有多个CPU，也不能对同一个请求进行并发处理，所以执行耗时为 S1/H1
磁盘I/O执行耗时： 在没有等待情况下的耗时为 S2/H2
１０．如何计算吞吐量
基本计算规则：一个请求各个处理阶段吞吐量的最小值，实际就是系统处理瓶颈决定整个的吞吐量。
吞吐量 = min(网络吞吐量，CPU吞吐量，磁盘I/O吞吐量)
&各阶段吞吐量计算如下：
网络吞吐量： &H3/S3
CPU吞吐量： N1*H1/S1
磁盘I/O吞吐量： H2/S2& &
１１．性能值具体的计算
我们根据之前的规则计算各性能值
请求处理分为多个过程，整理处理的能力跟最小处理过程有关，这是请求的处理瓶颈所在，如图5所示，即
&吞吐量 = min(H3/S3,N1*H1/S1,H2/S2)
　　　　　　　　　　　　　　　　　　　　图5
设网络处理与CPU执行之间的队列为Q1,CPU执行与磁盘I/O之间的队列为Q2
分两种情况分析，第一种请求到达的速率小于等于吞吐量，这时内部的队列中应该是没有累积数据的，队列Q1,Q2保持为空。将各阶段耗时相加即为：
延时 = X*S3/H3+S1/H1+S2/H2
我们定义这种待处理队列为空的状态为H-S-E状态，而有积累数据直到队列满的状态为H-S-F状态，当请求到达速度大于吞吐量时即可到达H-S-F状态。H-S-F状态下的延迟计算如下：
假设Q1的长度为L1,Q2的长度为L2,单个请求的延迟相对于H-S-E状态的延迟只是多了队列中等待的时间，计算出它即可，我们假设H3/S3 & N1*H1/S1 & H2/S2，当前一个处理阶段吞吐量大于后一个时，队列中才可能积累数据。
队列等待时间 = Y*L1*(S1/H1)+ L2*(S2/H2)
H-S-F下的延迟 =X*S3/H3+S1/H1+S2/H2+ L1*(S1/H1)+L2*(S2/H2)
队列长度越大，延迟越大，在请求速度没有控制的情况下，请求的延迟将会变得巨大。
需要注意的是，CPU运算对各进程的调度是按时间片来分的，并不是等一个进程完全执行完再执行另一个，这可以防止进程饥饿，并且将等待时间平摊，所以我们计算的CPU等待时间要加个计算系数，即Y*L1(S1/H1)。
根据并发度的定义，在队列中的请求都算是正在处理中请求。根据计算规则，为处理时间乘以吞吐量，H-S-E的并发度为
min(H3/S3,N1*H1/S1,H2/S2)* (X*S3/H3+S1/H1+S2/H2)
H-S-F的并发度为：
min(H3/S3,N1*H1/S1,H2/S2)*(X*S3/H3+S1/H1+S2/H2+L1*(S1/H1)+L2*(S2/H2))
在H-S-E状态下，随着请求速度提高，并发度同时提高，而处理延迟并不会增加，而一旦到了H-S-F状态，并发度升高会导致严重的请求延迟增加，往往这是一个很坏的状态。
假设一个请求跟一个进程是绑定的，即一个进程只有在处理完一个请求后才会处理另一外，所以所需要的进程数跟并发度是相等。当然可能还有一些其它特殊功能的进程，往往较少，可以忽略。
如之前所述，为了防止进程饥饿，CPU调度进程采用时间片法，每个进程轮流一个小的时间片，这就涉及到进程切换，在CPU计算密集型请求中，这个切换也是一个较大开销，所以启动并发度数目的进程CPU执行的吞吐量达不到N1*H1/S1，我们应该要将进程数减少到一个适当的程度以获得最大吞吐量，这个只能通过实际测量获得最佳进程数。
以上情况说明对进程数的控制很重要，不能无限制随着请求数目增加进程，这会导致系统吞吐量下降以及延迟的增加，apache的模型类似这种，所以在极端情况下它的性能并不高。
之前讨论的H-S-F状态下，Q1,Q2队列可能会满，实际上我们可以在应用层增加一个队列，让Q1,Q2保持为空的状态，从连接队列获取连接后，将其放进这个队列，然后启动固定数目的进程从该队列中获取读或写事件进行处理。将队列从操作系统内核移至应用层的队列，不但有更大的控制灵活性，如控制队列长度，也能够很好控制启动的进程数目，在这种情况下，我们也能保证所有事件都能得到处理。
当然，将队列由应用层实现，并不会提高系统整理吞吐量以及延迟，只是更方便控制了。那队列设置多长合适呢？一般来说处理延迟不应该超过客户端的超时时间，设队列长度为L,超时时间为T,由此可得出如下式子：
L*( X*S3/H3+S1/H1+S2/H2) & T
L & T*(X*S3/H3+S1/H1+S2/H2)
１２．请求处理模型优化
公平对待等待中的连接，优化应用层队列
&在之前的性能计算中，我们提到增加应用层队列，以实现对进程数的控制，但实际上与我们之前的一个假设有冲突，将连接从队列中拿出来后放到另一个队列，这样这个连接并不能立即进行读数据的操作，我们可以优化一下，所有进入这个队列的连接都可以立即进行读数据的操作，这并不是平常我们所说的 “队列”了，是一种特殊的数据结构，我们往往通过系统调用select或epoll 来实现，所以拿到的连接都可以进行数据操作，这实现了一种事件驱动的模式，这种模式一定程序减少了应用层队列等待时间，它避免了前一个连接因传输慢而导致后一个连接不能传输数据的情况，当然因为我们的进程数因为是控制在一定数量的，仍然可能会有“队列”等待的情况，延迟值计算跟之前是一样的。
这种“队列”，更像一种竖着的队列，进入队列中的连接都可以进行接下来的处理流程，如图6所示。
&　　　　　　　　　　　　　　　　　　　图6
如果将所有的到来的请求都放入“队列”，这是一种事件驱动模式，如之前所述，这可能会导致所有请求延迟增加。
缓冲各阶段吞吐量性能差，增加新的应用层队列
一般来说网络数据读取的吞吐量是高于CPU处理的吞吐量，之前的模型只有最前端有队列，整体吞吐量受限于最小吞吐量，不过我们可以在网络数据读取与CPU处理间建立新的应用层队列，让网络数据处理以更高的吞吐量运行，如图7所示，当然积累的待处理请求不能超过新的队列长度。
将应用队列放在最前端的延迟值为：
L*( X*S3/H3+S1/H1+S2/H2)
&增加新的队列后延迟值为：
X*S3/H3+L’*(S1/H2+S2/H2)
在队列长度相同的情况下，增加新的应用层队列后请求延迟值会降低，当然整体吞吐量不会改变。
　　　　　　　　　　　　　　　　　　　图7
解绑请求与进程，减少所需进程数
&之前对需要的进程数计算是基于进程跟请求完全绑定的，这种情况进程在等待I/O时会进入睡眠状态，这其实是对进程资源的一种浪费，如果将请求与进程解绑，让一个进程在等待某种I/O请求时不是去睡眠，而是继续去干其它事，于是我们可以以更少的进程数完成我们的吞吐量及延迟要求。
如果进程一直在“干活”而不会“睡觉”那应该需要多少进程数呢？进程一直干活需要使用CPU，所以这是跟CPU个数有关系的，在这种情况下需要的进程数是：
N1是CPU个数，Z是一个系数，一般应该在1到2之间。
解绑请求与进程是比较复杂的，也根本没有一种方法拆分让进程完全不“睡觉”，例如有些数据读取到一个进程中后总不能让另一个进程去处理的，数据在不同进程间不能共享，这也是Z系数会大于1的原因。
对一个请求拆分越细致对进程资源的浪费就越小，但编程就越复杂，也可能会导致增加CPU计算时间，这是需要衡量的问题，具体不再展开，具体编程是一个很复杂的问题。
１３．CPU密集型和I/O密集型对性能值的影响
之前我们讨论的是三阶段情况下各性能值的计算，现实情况有些是CPU密集或I/O密集型的服务，即极端化下的两阶段，即只有网络请求和CPU计算或只能网络请求和I/O处理。简单讨论下这种两阶段服务计算性能时特别的地方。
只有网络处理和CPU计算两个阶段。
吞吐量及延迟的计算一样，只是少了一个阶段。
因为只有CPU计算，不用对请求进行复杂的拆分，只需要启动少量进程，如跟CPU个数一样，即可以达到最佳的吞吐量值。模型优化第三条可以不采用了。
&另外CPU密集型服务处理时间会相对较短，网络数据处理时间占总体时间会较大，需要使用模型优化第二条。
也适宜事事件驱动的方式，并发度会很高，延迟不会增加特别厉害。
只有网络处理和I/O读写两个阶段（CPU的时间小到忽略不计）
同样的，吞吐量及延迟的计算一样，只是少了一个阶段。
&请求拆分以避免进程睡眼是较难的，这时启动的进程数应该跟如下公式相关
min(H3/S3,H2/S2)* (X*S3/H3+S2/H2)
这将远远多于CPU的个数。
另外I/O密集型服务处理时间会相对较长，模型优化第二条也一般不采用，因为其带来的延迟减少占总延迟比是很小的，增加一个队列反而增加了编程复杂度，而且队列相关的CPU时间可能甚至要高于网络处理延迟减少的时间，导致得不偿失。
不适宜事件驱动的方式，因为I/O处理耗时长，会让请求延时急剧上升。
１４．多系统性能值计算
之前我们讨论的值计算都是基于单一系统，而现实中是一个请求可能要经过多个不同的系统，如一个http请求，先经过nginx,再经过php,最后到mysql,如图8所示
　　　　　　　　　　　　　　　　　　　　图8
这种情况下性能值有什么不同呢？计算与单个系统各阶段计算类似
是各系统的最小吞吐量值
各系统延迟值相加
吞吐量*总的延时
事件驱动模式可以提高并发度，但一般我们只在第一个接入系统实现事件驱动模式就可以提高整个系统的并发度，所以我们无须在所有后续都实现事件驱动，如php或mysql，在后续系统实现事件驱动的一个坏处是后面系统的到达处理极限不能很好的反应到前面的系统，导致并发度越来越大，而导致整个系统的延迟极高。
php的进程模型里就没有网络处理与CPU计算中间的应用层队列，当PHP模块吃紧时会很快反应到nginx模块。
各个系统的进程数可以依照之前公式算出来，我们关心的一个问题是，A系统调用B系统时，A系统应该启动多少进程。假设B系统的吞吐量为吞吐量B，每个请求的耗时为耗时B
&为了使B系统达到相应吞吐量，则A系统发起的请求吞吐量也必须达到相同值，所以调用方进程数在同步调用（进程可能投入睡眠状态）下计算如下
A系统进程数 = A系统吞吐量*耗时A
A系统吞吐量 = B系统吞吐量
耗时A =耗时B
A系统进程数 = B系统吞吐量*耗时B
１５．如何进行性能测试
现实世界比我们之前说的几个简单公式远远复杂多了，不可能有一个精确的公式可以描述出来，所以性能值我们也不能说填充几个参数就可以像算数学题一样算出来，再加上我们面对的系统都是多个系统组合而成，直接算更不可能了，那些简单公式只是指导致我们进行测试。对于一个系统来说，真正的性能值需要通过工具测试出来，如用siege工具。
用工具进行测试的思路
吞吐量是一个比较固定的值，先观测它。根据之前的公式
A系统进程数 = B系统吞吐量*耗时B
B系统吞吐量 = A系统进程数/耗时B
可知为了观察到最大的吞吐量应该不断提高工具的并发进程数，直到吞吐量不再上升。
当吞吐量不再上升时说明已到了之前说所的H-S-F状态临界点，如果进一步提高客户端的并发，延时将会上升，这时我们可以得出延时的最小值。
客户端的并发度与待测系统的并发度不一定相同，但可以肯定的是他们是正相关关系。
当延时处于最小值，吞吐量处于最大值时，这时得出的并发度是最佳并发度。最佳并发度不代表最大并发度，最大并发度对于事件驱动模型来说，甚至是无限的，只要不超过客户端超时时间，但过长的时间不是我们能接受的。首先我们定义一个可以接受的最大延时，然我进一步提高客户端的并发度，直到延时达个这个值，这时得到的服务器的并发值才是有实际意义的最大并发度值。
性能测试工具siege
Ben: $ siege -u /Admin.jsp-d1 -r10 -c25
..Siege 2.65
..Preparing 25 concurrent users for battle.
The server is now under siege...done
Transactions: 250 hits
Elapsed time: 14.67 secs
Data transferred: 448000 bytes
Response time: 0.43 secs
Transaction rate: 17.04 trans/sec
Throughput: 30538.51 bytes/sec
Concurrency: 7.38
Status code 200: 250
Successful transactions: 250
Failed transactions: 0
Transaction rate 指吞吐量 &
Response time &指延时
Concurrency 指并发度
如何寻找瓶颈
有时我们需要找到整个系统的瓶劲，以提高性能值。首先我们应该找到整个系统是哪个子系统的的处理出现了瓶劲，是nginx,php还是mysql。然后研究一个子系统，是网络读取，CPU还是磁盘I/O出现了瓶颈，或是进程数启得少了，或是我们要优化自己的程序。具体操作比较复杂，可另成文，不展开讨论。
1. UNIX 网络编程
2. High Performance MySQL
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：35320次
排名：千里之外
原创：13篇
转载：11篇
评论：14条
(1)(3)(1)(1)(1)(3)(1)(3)(1)(3)(6)
() () () ()