1.1 这个并发是怎么界定的？
因为个人觉得按照计算机的逻辑，应该是不会有“同一刻”进来的请求，多多少少都会有先后的吧？
如果按照秒来计算，不同的请求可能都在30秒过来，但是他们的毫秒数可是不一样的，算是并发么？
所以这个并发是怎么计算？
| 说到并发，一定要提及并行了。 “并行”是指无论从微观还是宏观，二者都是一起执行的，就好像两个人各拿一把铁锨在挖坑，一小时后，每人一个大坑。 而“并发”在微观上不是同时执行的，只是把时间分成若干段，使多个进程快速交替的执行，从宏观外来看，好像是这些进程都在执行，这就好像两个人用同一把铁锨，轮流挖坑，一小时后，两个人各挖一个小一点的坑，要想挖两个大一点得坑，一定会用两个小时。 从以上本质不难看出，“并发”执行，在多个进程存在资源冲突时，并没有从根本提高执行效率。 真正的同时处理请求，必须在多核服务器或者分布式系统上。英特尔的超线程技术也只是做到在纳秒级的线程切换，也无法达到同时处理。 同时必须提及的就是——Amahl定律 Amahl定律是计算机科学中非常重要的定律，它定义了串行系统并行优化后加速比的计算公式和理论上限。 加速比定义：加速比=优化前系统耗时/优化后系统耗时 所谓加速比，就是优化前的耗时与优化后耗时的比值。加速比越高，表明优化效果越明显。 Amahl定律给出了加速比与系统并行度和处理器数量的关系。设加速比为Speedup，系统内必须串行化的程序比重为F，CPU处理器数量为N，则有： 根据此公式，如果CPU处理器数量趋近于无穷，那么加速比与系统的串行化率成反比，如果系统中必须有50%的代码串行执行，那么系统的最大加速比为2。 |
1.2 并发测试
通常对一个应用我们会提出这么一个问题（也许表达不严谨，望更正）：
1秒内能够响应的最大请求数是多少？上面两个问题如果要测出结果的话一般怎么做，比如要求哪些前提条件，网络、带宽什么的？
单个请求响应的最长时间是多少？
| 这两个问题，其实分别代表了性能测试中两大基础概念了。分别为吞吐量与响应时间。这两个东西不能分开独立考虑的。当吞吐量爬高时，响应时间必然增长，当然与此同此还有可能服务器端内存泄漏直接崩溃。 测试实施环境的话，环境风险因素尽量要避免，比如用无线网络、负载发生器环境纯净不能有360、防火墙、其他高消耗资源应用。在较为纯净的环境下，利用控制变量法_百度百科减少环境干扰。 至于性能分析：
|
2 队列
其实这个跟并发应该是有关系的，经常听到这么一句：流量太大，响应不过来，只好对用户请求进行排队处理，问题来了：
2.1 什么情况下需要排队？
按照我的理解，web server如IIS tomcat他们应该有自己的队列吧？也就是说他们应该能够负载起一定数量的请求，是不是超出这个数量就会挂起，导致超时，所以才需要开发者自己对请求进行排队？
如果是这样的话，怎么才能知道你的web server所能负载的最大请求数？
BTW，这个同1，所能负载的最大请求数是个什么概念，1s内？ 还是某个瞬间？
其实这个跟并发应该是有关系的，经常听到这么一句：流量太大，响应不过来，只好对用户请求进行排队处理，问题来了：
2.1 什么情况下需要排队？
按照我的理解，web server如IIS tomcat他们应该有自己的队列吧？也就是说他们应该能够负载起一定数量的请求，是不是超出这个数量就会挂起，导致超时，所以才需要开发者自己对请求进行排队？
如果是这样的话，怎么才能知道你的web server所能负载的最大请求数？
BTW，这个同1，所能负载的最大请求数是个什么概念，1s内？ 还是某个瞬间？
| 这要根据你们的服务器设备、网络带宽、负载均衡部署等实际情况来看的。同时还要看你们的开发人员代码质量。在考虑这些以后，你可以尝试着花三小时时间，不断的多进程的朝服务器发送请求，同时统计成功响应请求数目。 每秒响应次数=成功响应请求数目/累计负载时间 每次请求服务器时，不断递增客户端进程数，直至达到每秒响应次数无法递增或者增速放缓。 通过这种方式，不断的提高多进程发送请求的能力，就能发现你的web server所能负载的最大请求数。 吞吐量是指对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。注：每个请求包含的字节数是不尽相同的。并发一千万个十字节的请求，跟并发一百万个百字节的请求，是极大不同的。 所以在考虑吞吐量的同时，还要引入一个概念每秒处理事务数（TPS） 每秒处理事务数是评价系统性能均以每秒钟完成的技术交易的数量来衡量。 系统整体处理能力取决于处理能力最低模块的TPS 值（木桶原理）。 |
2.2 如果需要排队，在哪个层排队？
假设我是J2EE应用，servlet接受请求的，那么我是在servlet的入口处就做排队还是其他地方？
2.3 有没有取代排队的办法
除了添加服务器进行负载均衡，有没有别的办法？
我在想如果某个业务方法是同步的，比如
这种情况下操作系统会不会自动排队？
假设我是J2EE应用，servlet接受请求的，那么我是在servlet的入口处就做排队还是其他地方？
public void doGet(HttpRequest req,HttpResponse res){
//这里对req排队？
}
| 系统配置不合理，线程数、连接端口数、内存大小、缓存大小等； 数据库查询效率低下导致了排队，一条查询耗时都是30余秒堵在这很常见吧，还有诸如数据库Index设计不合理，表空间配置不合理，SGA&PGA配置不合理； 编码处理业务逻辑不合理导致了排队，明明能并行处理的业务使用了串行处理，在循环中使用了字符串的+=操作，当然严重点的还有疫苗：Java HashMap的死循环； |
除了添加服务器进行负载均衡，有没有别的办法？
我在想如果某个业务方法是同步的，比如
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的概念，其实负载均衡不止应用负载均衡的。
Session服务器配置指南与使用经验 |
4 数据库读写操作
单个请求读写都没有问题，但是假设某个瞬间有n个请求过来，并且“同时”要写操作，那么需不需要开发人员在这个逻辑里面做一些额外的工作？比如再排个队之类？还是啥都不关，交给数据库处理？
| 我也不是专攻数据库的，给点我知道的。读写分离，index调优，sql调优，清理数据库磁盘碎片，做memcached数据库缓存； （ps：请留意接下来的博客发布，我已经计划好了关于mysql数据库的东西） |
5 其他
5.1 多语言组合
常听到某某网站采用了前端php+后端java的方式，一直很奇怪，怎么融合的？（希望这个详细点）
5.2 还没想好
5.1 多语言组合
常听到某某网站采用了前端php+后端java的方式，一直很奇怪，怎么融合的？（希望这个详细点）
| 通信拆包封包嘛！ SOA面向服务，Restful资源服务，Message Queue等等。 |
5.2 还没想好
| 处理性能瓶颈需要一定的功力的，推荐看看葛一鸣《Java程序性能优化 (豆瓣)》、罗敏《品悟性能优化 (豆瓣)》、《Effective Java 第二版 中文版/Sun公司核心技术丛书 (豆瓣)》、《Web性能优化 (豆瓣)》、《Java性能优化权威指南 (豆瓣)》 引自 @张易 如果你所在的网站属于小型网站（PV百万）以下，建议进行数据库调优，提高代码质量并适当引入缓存。 如果你所在网站属中小型网站（PV百万至千万），建议在以上操作的前提下，分离服务器职责，但服务器总数量应控制在3-5台（我经历过的生产环境，PV300w加大量数据库读写应用，两台服务器绰绰有余），适当引入热备冷备和负载均衡。 如果你所在网站属大型网站（PV千万级以上），建议在以上操作的前提下，聘用专业系统运维及应用运维维护服务器。当然，那个时候，你就不需要来知乎上提问了，问专业人士吧。 网站的性能，和代码质量，服务配置，服务器数量都有着密不可分的关系，具体如何取舍，还应根据个人情况自行斟酌。 |