以下内容均为摘抄，如有侵权，请联系删除。
这个问题⽆法量化，任何⼀个⼤型⽹站都是经历⽤户积累然后成长，从⼀台服务器到多台服务器才能构架⽀撑⽹站现有数据、⽤户、页⾯请求等。⼤型⽹站(如淘宝、京东等)的系统架构并不是开始设计就具备完整的⾼性能、⾼可⽤、安全等特性，它总是随着⽤户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发⽣了很⼤的变化，就连技术⼈员也从⼏个⼈发展到⼀个部门甚⾄⼀条产品线。 所以成熟的系统架构是随业务扩展⽽完善出来的，并不是⼀蹴⽽就；不同业务特征的系统，会有各⾃的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、⽀付，例如腾讯，要解决数亿的⽤户实时消息传输，百度它要处理海量的搜索请求，他们都有各⾃的业务特性，系统架构也有所不同。 1、如果⼀个⽹站访问量很⼩，⽐如某⼩公司的⼩论坛，同时在线可能只有⼏个⼈，并且稳定性和安全性要求⽐较低，那么⼀台配置不太好的服务器就够了，数据库、应⽤服务器全部在上⾯；
2、再⼤⼀点，考虑数据库服务器和应⽤服务器分离，各置⼀台服务器，还可以再增加⼀台做静态请求和
动态请求分离；
3、当⼀台应⽤服务在⾼峰时期很吃⼒以⾄于严重影响访问质量时，可以考虑增加⼀台应⽤服务器做负载均衡来分散压⼒，同时也提⾼了稳定性，如果⼀台应⽤服务器宕机，还有另外⼀台来响应请求（前提是负载均衡能做到⼀台挂了，就把所有请求统统交给另⼀台）；
4、如果安全性要求较⾼，不能有任何的数据丢失，尤其涉及到钱的问题时，需要备份数据库，那么可以做数据库主从，主机宕机⾃动切换到从机；
5、如果访问量持续增多，⽽⼤量数据读操作⾮常频繁，写操作相对较少，则这部分数据可以分离出来缓存到专门的服务器，常见的如Memcache、Redis缓存服务器，这样就可以⼤⼤减少数据库读写的压⼒，这是⾮常有效的减压⽅式；
6、如果部署了N台缓存服务器后数据库仍然还有压⼒，可以考虑对数据库进⾏读写分李，⼀台master主写，N台slave主读，当然要做好数据的同步；
7、如果该⽹站有⼤量的图⽚或者⽂件需要管理，那么需要增加图⽚服务器或⽂件系统服务器，这些服务器通常是分布式的应⽤，如Hadoop等，可以使⽤N台服务器来部署；
8、如果瞬时访问量极⼤，同时请求数到达了⼀定数量级时，后台服务仍然⾮常吃⼒，⽽我们对响应
实时性要求⼀般，则可以增加N台消息队列服务器来做缓冲；
9、再有就是上述服务器⼤规模集了。。。。可以有N⼤。。。
所以，究竟需要多少台服务器，需要根据业务特点及业务系统需求，逐步升级扩容，直到满⾜需求为⽌；国内的⼤型互联⽹公司⽆不如此。
如果上云，建议⾸选活动机，就拿腾讯云的活动机来说，低配置的1核2G1M低⾄99元，3年只需要298元，适⽤于中⼩企业的配置：4核8G5M带宽200G磁盘也才1279元/年，活动可参考：
对于中⼩型企业或者创业公司来说，前期业务量相对较⼩，对整个服务器集的需求也不⼤，往往单台服务器或者简单的负载均衡架构即可满⾜使⽤需求，在这种情况下，云平台的活动机其实是个不错的选择。
⼀秒钟能处理300个请求和并发300 有区别吗？
从1秒钟这个时间尺度上，区别不⼤。
如果改成每秒钟处理300个请求和并发300就有区别了。
后者的概念可以是服务器同时接收了300个请求，但是花了n秒钟把他们处理完。如果这个n⼤于请求的timeout值，就会有部分请求处理失败。
前者的概念可以是不管服务器接收多少请求（可能⾼于300也可能低于300），但是每秒只能处理300个。
在实际应⽤中需要考虑系统性能和稳定性，对于超出系统处理能⼒的请求该如何避免影响核⼼业务。
并发能⼒和线程数量不是⼀回事，但有关系。跟系统能开启的线程数也有⼀些关系，但不是绝对。也就是说，在⼀定范围内，你可以这样认为，但是超出这个范围就不⼀定。
⽐如⼀个⼈挖⼀个坑需要4分钟，2个⼈⼀起挖需要2分钟。但不是24个⼈⼀起挖10秒就能ok。这⾥涉及到资源的冲突，以及⼯序的排序，甚⾄是采⽤的⽅法。⽐如换⼀个⼤型挖掘机也许10秒就ok。
QPS：每秒处理的请求数量。
⽐如你的程序处理⼀个请求平均需要0.1S，那么1秒就可以处理10个请求。QPS⾃然就是10，多线程情况下，这个数字可能就会有所增加。
由PV和QPS如何需要部署的服务器数量？
根据⼆⼋原则，80%的请求集中在20%的时间来计算峰值压⼒：
（每⽇PV * 80%） / （3600s * 24 * 20%） * 每个页⾯的请求数 = 每个页⾯每秒的请求数量
然后除以服务器的QPS值，即可计算得出需要部署的服务器数量
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
杨梅采摘机
问：每天300w PV 的在单台机器上，这台机器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
问：如果⼀台机器的QPS是58，需要⼏台机器来⽀持？泡钉
答：139 / 58 = 3
———————————————————
假如想要建设⼀个能承受500万PV/每天的⽹站，服务器每秒要处理多少个请求才能应对？如何计算？
1、PV是什么：
PV是page view的简写。PV是指页⾯的访问次数，每打开或刷新⼀次页⾯，就算做⼀个pv。
2、计算模型：
每台服务器每秒处理请求的数量=((80%总PV量)/(24⼩时60分60秒40%)) / 服务器数量 。
注：其中关键的参数是80%、40%。表⽰⼀天中有80%的请求发⽣在⼀天的40%的时间内。24⼩时的40%是9.6⼩时，有80%的请求发⽣⼀天的9.6个⼩时当中（很适合互联⽹的应⽤，⽩天请求多，晚上请求少）。
3、简单计算的结果：打猎机
((80%500万)/(24⼩时60分60秒40%))/1 = 115.7个请求/秒
((80%100万)/(24⼩时60分60秒40%))/1 = 23.1个请求/秒
4、初步结论：
现在我们在做压⼒测试时，就有了标准，如果你的服务器⼀秒能处理115.7个请求，就可以承受500万
PV/每天。如果你的服务器⼀秒能处理23.1个请求，就可以承受100万PV/每天。
5、留⾜余量：
以上请求数量是均匀的分布在⽩天的9.6个⼩时中，但实际情况并不会这么均匀的分布，会有⾼峰有低⾕。为了应对⾼峰时段，应该留⼀些余地，最少也要x2倍，x3倍也不为过。
115.7个请求/秒 *2倍=231.4个请求/秒
115.7个请求/秒 *3倍=347.1个请求/秒
23.1个请求/秒 *2倍=46.2个请求/秒
23.1个请求/秒 *3倍=69.3个请求/秒
6、最终结论：
如果你的服务器⼀秒能处理231.4–347.1个请求/秒，就可以应对平均500万PV/每天。
如果你的服务器⼀秒能处理46.2–69.3个请求，就可以应对平均100万PV/每天。
说明：
这⾥说明每秒N个请求，就是QPS。因为我关⼼的是应⽤程序处理业务的能⼒。
7、实际经验：
1、根据实际经验，采⽤两台常规配置的机架式服务器，配置是很常见的配置，例如⼀个4核CPU+4G内存+服务器SAS硬盘。
2、个⼈武断的认为在服务器CPU领域Intel的CPU要优于AMD的CPU，有反对的就反对吧，我都说我武断了（请看CPU性能⽐较），不要太相信AMD的⼴告，⽐较CPU性能简单办法就是⽐价格，不要⽐频率与核⼼数，价格相差不多的性能也相差不多。
3、硬盘的性能很重要，由其是数据库服务器。⼀般的服务器都配1.5万转的SAS硬盘，⾼级⼀点的可以配SSD固态硬盘，性能会更好。最最最最重要的指标是“随机读写性能”⽽不是“顺序读写性能”。（本例还是配置最常见的1.5万转的SAS硬盘吧）
4、⼀台服务器跑Tomcat运⾏j2ee程序,⼀台服务器跑MySQL数据库，程序写的中等⽔平(这个真的不好量化)，是论坛类型的应⽤(总有回帖，不太容易做缓存，也⽆法静态化)。
5、以上软硬件情况下，是可以承受100万PV/每天的。(已留有余量应对突然的访问⾼峰)
8、注意机房的⽹络带宽：
红外线烘干箱有⼈说以上条件我都满⾜了，但实际性能还是达不到⽬标。这时请注意你对外的⽹络的带宽，在国内服务器便宜但带宽很贵，很可能你在机房是与⼤家共享⼀条100M的光纤，实际每个⼈可分到2M左右带宽。再好⼀点5M，再好⼀点双线机房10M独享，这已经很贵了（北京价格）。
⼀天总流量：每个页⾯20k字节*100万个页⾯/1024=19531M字节=19G字节，19531M/9.6⼩时=2034M/⼩时=578K字节/s 如果请求是均匀分布的，需要5M（640K字节）带宽（5Mb=640KB 注意⼤⼩写，b是位，B是字节，差了8倍），
镀锌钢管连接方式但所有请求不可能是均匀分布的，当有⾼峰时5M带宽⼀定不够，X2倍就是10M带宽。10M带宽基本可以满⾜要求。
以上是假设每个页⾯20k字节，基本不包含图⽚，要是包含图⽚就更⼤了，10M带宽也不能满⾜要求了。你⾃已计算吧。
1G=1024M
1M=1024KB
1KB=1024B
1Mb的宽带（运营商叫法）换算为下载速度（传输速率），是0.125MB/s，换算成MB换算成KB是128KB/s。
附：性能测试基本概念
⼀、基本概念：
Throughput（吞吐量）：按照常规理解⽹络吞吐量表⽰在单位时间内通过⽹卡数据量之和，其中即包括本机⽹卡发送出去的数据量也包括本机⽹卡接收到的数据量。 ⼀个100Mb(位)的双⼯⽹卡，最⼤发送数据的速度是12.5M字节/s，最⼤接收数据的速度是12.5M字节/s，可以同时收发数据。
并发⽤户数：是同时执⾏操作的⽤户(线程数)。
响应时间：从请求发出到收到响应花费的时间 。
QPS - Queries Per Second 每秒处理的查询数（如果是数据库，就相当于读取）
TPS - Transactions Per Second 每秒处理的事务数(如果是数据库，就相当于写⼊、修改)
IOPS，每秒磁盘进⾏的I/O操作次数
例如对某个数据库测试，分开两次测QPS与TPS。
QPS（读取）值总是⾼于TPS(写、改)，并且有倍率关系，因为：
1、数据库对查询可能有缓存。
2、机械硬盘或SSD硬盘的读就是⽐写快。
⼆、JMeter测试参数说明：
Label：每⼀个测试单元的名字。
#Samples：表⽰⼀个测试单元⼀共发出了多少个请求。
Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使⽤了 Transaction Controller 时，也可以以Transaction 为单位显⽰平均响应时间。，不重要。
Median：中位数，也就是 50％ ⽤户的响应时间，如果把响应时间从⼩到⼤顺序排序，那么50％的请求的响应时间在这个范围之内。重要。
90% Line：90％ ⽤户的响应时间，如果把响应时间从⼩到⼤顺序排序，那么90％的请求的响应时间
二次沉淀池在这个范围之内。重要 。
Min：最⼩响应时间，不重要。
Max：最⼤响应时间，出现⼏率只不过是千分之⼀甚⾄万分之⼀，不重要。
Error%：本次测试中出现错误的请求的数量
Throughput：吞吐量——默认情况下表⽰每秒完成的请求数（Request per Second），当使⽤了 Transaction Controller 时，也可以表⽰类似 LoadRunner 的 Transaction per Second 数
KB/Sec：每秒从服务器端接收到的数据量(只是接收)，相当于LoadRunner中的Throughput/Sec
三、Apache ab测试参数说明：
RPS：Request per Second，每秒处理的请求数
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议