QQ在线
010-59458706

你的APP软件可以支持多少用户

2017-08-03 21:57 5461
【摘要】你的APP软件可以支持多少用户?很多朋友都关心自己的软件可以抗住多少用户。归根结底,是想知道要抗住预期的注册用户量,需要多少成本(多少钱)~_~

  你的APP软件可以支持多少用户 很多朋友都关心自己的软件可以抗住多少用户。归根结底,是想知道要抗住预期的注册用户量,需要多少成本(多少钱)~_~

  网上很多帖子都是讲一些非常专业的东西,比如并发(个人看了网上很多文章,发现其实很多技术人员对并发的理解也不是很正确)、吞吐量、PV、UV等等。


你的APP软件可以支持多少用户


  不是非常懂技术的朋友很难搞清楚这些概念。

  我这篇文章也是从专业的数据出发,但是我会给出一个非常直白的结果,希望直白的告诉你多少钱可以抗住多少用户量。

  仅仅是个人拙见,若有研究这方面的朋友持有不同意见,希望得到与您交流学习的机会,本人特别希望与技术方面的朋友交流学习共同进步。

  1、名词解释

  PV:页面浏览数。可以简单理解为:用户在你的网页上点击一个连接就产生一个PV。精确的解释可问度娘。

  UV:用户浏览量。可以简单理解为:有一个用户在一台设备上打开了你的网站,不管他浏览了多少个页面,都算产生了一个UV。精确的解释可问度娘。

  QPS:秒并发。可简单理解为每秒钟你的网站可以同时允许最多多少人访问(假设这些人在1秒钟内只点击一次连接,并且连接只产生一个请求),并且保证他们都能够显示正确的页面(网上大多表述为:机器不宕机或者不崩溃,个人觉得这不太严谨)。

  2、用户总数与秒并发的关系

  (1)用户总数与秒并发(QPS)的关系

  下面以淘宝网的数据为例进行分析:

  1,2010年淘宝注册会员3.7亿(参考 http://tech.sina.com.cn/i/2011-01-06/20285067308.shtml)

  2,2014年淘宝注册会员约5亿(参考 http://www.baike.com/wiki/

  %25E6%25B7%2598%

  25E5%25AE%259D%

  25E7%25BD%2591)

  3, 2011年淘宝的日均TPS峰值在5万QPS附近。(参考http://www.ha97.com/

  5095.html)

  4,2013年的双12大秒,系统的峰值QPS大约为42万。这个数据基本是年度峰值了,是平时峰值的好几倍。

  (参考http://help.aliyun.com/document_

  detail/pts/test-case/

  PTS-TC09-Large-scale

  DistributedStressTesting.html)

  根据以上数据大体可以推算出注册淘宝用户数和系统QPS峰值的关系是5亿/42万,大约1190:1,考虑淘宝技术上的优化可以大大降低用户对系统压力,针对市面上大部分的软件做个非常保守数据:500:1。可以理解为:当系统秒并发为1的时候可以支撑500个注册用户。

  注意:以上推算是根据淘宝的数据做的的推算。如果你的app应用或者网站是视频、音频或即时通信方面的应用,那么这与普通商城/网站会有很大的区别,在这种情况下以上数据不具有太多参考价值。

  3、用户总数与成本的关系

  上面已推算出用户总数与秒并发的关系,只要我们知道秒并发的成本,就可以大体推算出预期的注册用户需要多少成本。

  这个成本主要由两部分组成:(1)硬件成本,如机房、服务器、固定IP等;(2)软件架构成本,系统越复杂,需要的架构越复杂,软件架构的成本所占比例越大。

  由于本人所在公司目前所接项目大都是总预算几十万的中小型项目,预算上需求方根本不可能购买服务器组建机房,所以大部分都是租的云服务器,极大的节省了硬件成本。

  所以我这里的硬件成本,主要指租赁服务器的成本。

  服务器的配置参数很多,成本也差异较大,这里大约给出一个参考:1核1G内存的服务器,一年大约1000元的成本(这只是一个大约量级,变动因素太多:内存、宽带、IO存储等)。

  而1核1G的这种服务器可以承载多少的并发呢?

  这里就涉及到架构的问题:

  (1)很多小公司或者团队的架构是单服务器,并且软件架构方面也没有做多级缓存和其他一些高资源消耗业务分离的处理。如下示意图:


  


  对于这种单体服务器,我们做过专门的压力测试,单核1G配置的服务器,结果峰值为:23QPS(见图1)。如果考虑图片等静态资源的消耗,实际的业务QPS应该在14左右。


  


http://www.theaty.com/Public/Upload/shop/article/05313483050301999.jpg


  1核1G内存的单体服务器压力测试结果TPS(QPS)峰值为:23.20

  (2)下面这种是我们现在采用的架构,不知道怎么称呼,我就称为西太小型分布架构吧。包含了OSS独立静态服务器、模糊搜索服务器、数据库RDS的读写分离、代码CACHE缓存加速、后台多级缓存、前端缓存、独立的推送服务器。这种架构的硬件和软件成本都比上面的单体服务器要大一些。尤其是软件架构,凡是涉及到分布式,一般提供解决方案的公司要求最低几十万起,更复杂的那就没谱啦。然而,我们公司给客户搭建的西太小型分布架构的成本比单服务器多了几千元的成本(有严重的做广告嫌疑……,见谅推算成本必须要讲)


  


  对于这种架构,在仅增加代码缓存器的基础上我们的测试结果是:188的QPS峰值(见图2),大约是单体服务器的7倍左右,在增加OCS(高速kv缓存服务器)的时候,是304TPS(见图3)。并且采用OSS(高速高可用对象存储服务器)完全分离静态资源的系统压力。以上测试仅是在1核1G内存的低配服务器的测试结果,随着并发的增加和服务器硬件配置的提升,这种小型分布架构对比单体服务器的优势会更加明显。


  


  (图2)单核1G内存服务器配合代码缓存服务器后的压力测试结果TPS(QPS)峰值为:188.40


  


  (图3)单核1G内存服务器 配合代码缓存服务器和OCS(高速kv缓存服务器)的压力测试结果TPS(QPS)峰值为:304

  备注:以上的两种架构基本都是单体架构,并不是说一台服务器可以承载3千的用户,如果要承载3千万的用户,就可以简单的罗列1万台服务器。这种单体架构的承载受限于硬件,是有承载上限的:按阿里云提供的服务器,最多32核,你可以简单的理解(这种理解肯定是不科学的,但是量级也差不太多)为:第一种架构理论上可以支撑500*14*32大约22万的注册用户;而西太单体分布架构理论上限是500*304*32大约480万注册用户。如果用户更多,那么就需要用到负载等(西太小型分布架构很容易升级扩展SLB和CDN 等大型分布架构。不过这个阶段应该需要有专职和专业的技术作配合,因为搞大并发教条解决不了问题,有人说得好解决并发是一个不断测试发现和解决问题的过程,架构是解决问题的结果)。

  4、总结

  通过以上的计算,在硬件采用云服务器的前提下,我们有如下的结果:

  A)架构采用一般的单服务器架构

  假定预期注册用户量为10万,那么每年的费用大约是100000*(1000/(500*14))=约1.43万元。受硬件限制,这种架构通过简单升级硬件(以32核为上限)可承载用户上限理论在22万左右。

  B)架构采用西太小型分布架构

  假定预期注册用户量为50万,那么每年的费用大约是500000*(2000/(500*304))=约6578元。受硬件限制,这种架构通过简单升级硬件(以32核为上限)可承载用户上限理论在480万左右。

  备注:并发是个非常非常复杂且专业的问题,影响因素太多太多,这篇文章仅以一个特定的环境和用例做了一个推断,以上数据您可仅仅作为一个量级参考,本人希望能够给您一个直观的印象。具体的数据只有通过实际测试才能得出,解决并发的过程其实是个不断测试、发现和解决问题的过程。还有上面的硬件是采用租赁云服务器的方式,这种成本对比自建服务器的成本也不在一个量级上。

  北京西太科技是一家专业的APP开发公司,专门针对原生态APP的移动开发商,专注于手机APP开发、微信开发、网站开发等综合型互联网企业。

声明:文章"你的APP软件可以支持多少用户"为西太APP开发公司原创文章,转载请注明出处,谢谢合作!
分享到:

文章排行

周排行榜月排行榜