几个关于网站架构和性能的问题（我在知乎上的问答）

1 并发

---

1.1 这个并发是怎么界定的？
由于我的以为按照计算机的逻辑，应该是不会有“同一刻”进来的请求，多多少少都会有前后的吧？
若是按照秒来计算，不一样的请求可能都在30秒过来，可是他们的毫秒数但是不同的，算是并发么？
因此这个并发是怎么计算？

说到并发，必定要说起并行了。 “并行”是指不管从微观仍是宏观，两者都是一块儿执行的，就好像两我的各拿一把铁锨在挖坑，一小时后，每人一个大坑。  而“并发”在微观上不是同时执行的，只是把时间分红若干段，使多个进程快速交替的执行，从宏观外来看，好像是这些进程都在执行，这就好像两我的用同一把铁锨，轮流挖坑，一小时后，两我的各挖一个小一点的坑，要想挖两个大一点得坑，必定会用两个小时。  从以上本质不难看出，“并发”执行，在多个进程存在资源冲突时，并无从根本提升执行效率。 真正的同时处理请求，必须在多核服务器或者分布式系统上。英特尔的超线程技术也只是作到在纳秒级的线程切换，也没法达到同时处理。 同时必须说起的就是——Amahl定律 Amahl定律是计算机科学中很是重要的定律，它定义了串行系统并行优化后加速比的计算公式和理论上限。 加速比定义：加速比=优化前系统耗时/优化后系统耗时 所谓加速比，就是优化前的耗时与优化后耗时的比值。加速比越高，代表优化效果越明显。 Amahl定律给出了加速比与系统并行度和处理器数量的关系。设加速比为Speedup，系统内必须串行化的程序比重为F，CPU处理器数量为N，则有： 根据此公式，若是CPU处理器数量趋近于无穷，那么加速比与系统的串行化率成反比，若是系统中必须有50%的代码串行执行，那么系统的最大加速比为2。

1.2 并发测试
一般对一个应用咱们会提出这么一个问题（也许表达不严谨，望更正）：

1秒内可以响应的最大请求数是多少？
单个请求响应的最长时间是多少？

上面两个问题若是要测出结果的话通常怎么作，好比要求哪些前提条件，网络、带宽什么的？

这两个问题，其实分别表明了性能测试中两大基础概念了。分别为吞吐量与响应时间。这两个东西不能分开独立考虑的。当吞吐量爬高时，响应时间必然增加，固然与此同此还有可能服务器端内存泄漏直接崩溃。 测试实施环境的话，环境风险因素尽可能要避免，好比用无线网络、负载发生器环境纯净不能有360、防火墙、其余高消耗资源应用。在较为纯净的环境下，利用 控制变量法_百度百科 减小环境干扰。 至于性能分析： 前端：各类页面元素加载能够利用firebug、IE的开发者工具、chrome的开发者工具、httpwatch等； 服务应用：能够用VisulaVM 性能：分析 JVM 性能的免费工具 系统资源：对于unix,linux,aix能够用nmon，针对于aix还能够用svmon，固然iostat、vmstat等也是经常使用的；对windows而言能够用Logman，资源监视器 数据库：如今成熟的数据库产品多如牛毛，尤为是nosql的异军突起。我也经常感受无能为力。对于oracle品味性能之道<五>：SQL分析工具，品味性能之道<六>：图形化SQL分析工具；对于mysql而言详解MySQL中EXPLAIN解释命令 网络通讯：OmniPeek 基础之协议分析

2 队列

---

其实这个跟并发应该是有关系的，常常听到这么一句：流量太大，响应不过来，只好对用户请求进行排队处理，问题来了：

2.1 什么状况下须要排队？ 
按照个人理解，web server如IIS tomcat他们应该有本身的队列吧？也就是说他们应该可以负载起必定数量的请求，是否是超出这个数量就会挂起，致使超时，因此才须要开发者本身对请求进行排队？
若是是这样的话，怎么才能知道你的web server所能负载的最大请求数？
BTW，这个同1，所能负载的最大请求数是个什么概念，1s内？ 仍是某个瞬间？

这要根据大家的服务器设备、网络带宽、负载均衡部署等实际状况来看的。同时还要看大家的开发人员代码质量。在考虑这些之后，你能够尝试着花三小时时间，不断的多进程的朝服务器发送请求，同时统计成功响应请求数目。 每秒响应次数=成功响应请求数目/累计负载时间 每次请求服务器时，不断递增客户端进程数，直至达到每秒响应次数没法递增或者增速放缓。 经过这种方式，不断的提升多进程发送请求的能力，就能发现你的web server所能负载的最大请求数。 吞吐量是指对网络、设备、端口、虚电路或其余设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。注：每一个请求包含的字节数是不尽相同的。并发一千万个十字节的请求，跟并发一百万个百字节的请求，是极大不一样的。 因此在考虑吞吐量的同时，还要引入一个概念每秒处理事务数（TPS） 每秒处理事务数是评价系统性能均以每秒钟完成的技术交易的数量来衡量。 系统总体处理能力取决于处理能力最低模块的TPS 值（木桶原理）。

2.2 若是须要排队，在哪一个层排队？
假设我是J2EE应用，servlet接受请求的，那么我是在servlet的入口处就作排队仍是其余地方？

public void doGet(HttpRequest req,HttpResponse res){
	//这里对req排队？
}

系统配置不合理，线程数、链接端口数、内存大小、缓存大小等； 数据库查询效率低下致使了排队，一条查询耗时都是30余秒堵在这很常见吧，还有诸如数据库Index设计不合理，表空间配置不合理，SGA&PGA配置不合理； 编码处理业务逻辑不合理致使了排队，明明能并行处理的业务使用了串行处理，在循环中使用了字符串的+=操做，固然严重点的还有疫苗：Java HashMap的死循环；

2.3 有没有取代排队的办法
除了添加服务器进行负载均衡，有没有别的办法？ 

我在想若是某个业务方法是同步的，好比

public void synchronized operation(){}

这种状况下操做系统会不会自动排队？

出现性能瓶颈缘由不只仅是排队，经常同步的操做是为了必要的数据原子性而设计。除了添加服务器进行负载均衡，还有如下方法： 业务：更改业务逻辑，将原有的串行处理改成并行处理； 代码：多线程代码段，作好变量同步，推荐看Java并发编程实战 (豆瓣) 数据库：作好sql优化； 部署：增长应用节点，以提高应用吞吐量； 有时只是缓存过小稍微调整下就行了； 有时jvm设置不合理修改下相应的配置就行了； 解决性能问题品味性能之道<三>：方法论

3 负载均衡

---

3.1 负载均衡的适用场景是什么
我的理解，若是单个服务器可以知足需求的话，无端增长了n台服务器来负载是否是反而会下降响应时间？

的确负载均衡器自己的性能也要考虑地； 同时作负载均衡不断的横向扩展服务器架构，

3.2 负载均衡环境下的应用部署
对于我来讲，感受多台服务器下面的应用部署就是个噩梦，由于咱们的应用随时均可能更改，并且改动的地方也不集中，每次逐个操做真的很崩溃。

大家须要一个集群运维管理平台，通常大公司会本身开发，最近我也在本身写个简略的版本将就用，不过我只设计了应用的部署，数据库那块的部署管理没打算弄。这东西还在作的过程当中。（我能说我上班太闲了，本身个弄着玩的么？） 最终这玩意夭折了，我太懒了...

3.3 负载均衡下的session共享如何处理，是否是采用单点登陆解决？

nginx负载均衡器处理session共享的几种方法 1) 不使用session，换做cookie 2) 应用服务器自行实现共享 3) ip_hash 4) upstream_hash 5) redis存放seesionid信息 web应用有session的概念，同时数据库也有session的概念，其实负载均衡不止应用负载均衡的。 HTTP重定向负载均衡 DNS域名解析负载均衡 反向代理负载均衡 IP负载均衡 数据链路层负载均衡 ASP.NET性能优化之分布式Session Session服务器配置指南与使用经验

4 数据库读写操做

---

单个请求读写都没有问题，可是假设某个瞬间有n个请求过来，而且“同时”要写操做，那么需不须要开发人员在这个逻辑里面作一些额外的工做？好比再排个队之类？仍是啥都不关，交给数据库处理？

我也不是专攻数据库的，给点我知道的。读写分离，index调优，sql调优，清理数据库磁盘碎片，作memcached数据库缓存； （ps：请留意接下来的博客发布，我已经计划好了关于mysql数据库的东西）

5 其余

---

5.1 多语言组合
常听到某某网站采用了前端php+后端java的方式，一直很奇怪，怎么融合的？（但愿这个详细点）

通讯拆包封包嘛！ SOA面向服务，Restful资源服务，Message Queue等等。

5.2 还没想好

 

处理性能瓶颈须要必定的功力的，推荐看看葛一鸣《Java程序性能优化 (豆瓣)》、罗敏《品悟性能优化 (豆瓣)》、《Effective Java 第二版 中文版/Sun公司核心技术丛书 (豆瓣)》、《Web性能优化 (豆瓣)》、《Java性能优化权威指南 (豆瓣)》 引自 @张易 若是你所在的网站属于小型网站（PV百万）如下，建议进行数据库调优，提升代码质量并适当引入缓存。 若是你所在网站属中小型网站（PV百万至千万），建议在以上操做的前提下，分离服务器职责，但服务器总数量应控制在3-5台（我经历过的生产环境，PV300w加大量数据库读写应用，两台服务器绰绰有余），适当引入热备冷备和负载均衡。 若是你所在网站属大型网站（PV千万级以上），建议在以上操做的前提下，聘用专业系统运维及应用运维维护服务器。固然，那个时候，你就不须要来知乎上提问了，问专业人士吧。 网站的性能，和代码质量，服务配置，服务器数量都有着密不可分的关系，具体如何取舍，还应根据我的状况自行斟酌。

来自为知笔记(Wiz)