web端测试 多个用户完全相同的时间请求，怎么模拟

1 怎样的性能测试结果才是有效的
11 错误观点
性能测试工具运行一定用户数都成功，则表示该服务器能支持这么多用户数。这是错误的。
解答：
A
因为一次有效的测试结果，不只用户都运行成功，同时需要保证访问一个页面或一次交易的响应时间在合理范围。“2-5-8原则”，简单说，就是当用户访问一
个页面或一次交易能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-8秒以内
得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟透了，或者认为
系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。
B 测试场景不一定模拟了真实业务场景，因为浏览器是并发多线程多TCP完成一个页面的，而测试工具基本都是1，2个线程；对服务器的压力是不一样的，真实环境的TCP压力是性能测试工具虚拟环境的几倍。
2 影响WEB服务器性能指标的因素有哪些
为什么性能测试工具，需要提供事务（页面或交易、全脚本）指标、TCP连接、吞吐量、服务器资源监控、请求数/响应数。
1) 硬件资源：如CPU、内存、网卡吞吐量、I/O能力、SWAP交换能力
2) 线程数：这里介绍JAVA的WEB服务器，默认每线程占用的内存为2M，而32为系统JAVA进程（如tomcat、JBoss）占得空间只有2G（一般比这个小），因此线程数有限制；64为无限制线程，但CPU要跟得上
3) TCP连接数： *** 作系统的TCP连接数理论值一般很大， *** 作系统对TCP连接设置有默认值（怎么配置，可以网上搜索，这里不介绍）；但实际测试中TCP连接在几百，就出现测试的响应时间很长。抓包分析，原来是三次握手的SYN包服务器不及时响应，导致SYN重传（3秒后，9秒后）。
如果SYN丢了，则会重发，但是第一次是3秒后，第2次是在9秒后，如果重发才收到的SYN_ACK，则导致TCP连接超长，从而导致业务响应时间延长。
4) 响应时间：服务器响应时间小，用户体验才好，在大量用户并发的情况下，>

国内的不清楚,给你看看YOUTUBE的

YouTube的架构扩展

在西雅图扩展性的技术研讨会上，YouTube的CuongDo做了关于YouTubeScalability的报告。视频内容在GoogleVideo上有(地址)，可惜国内用户看不到。

KyleCordes对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(KyleCordes的介绍是本文的主要来源)

简单的说YouTube的数据流量,"一天的YouTube流量相当于发送750亿封电子邮件",2006年中就有消息说每日PV超过1亿,现在更夸张了,"每天有10亿次下载以及6,5000次上传",真假姑且不论,的确是超乎寻常的海量国内的互联网应用,但从数据量来看,怕是只有51com有这个规模但技术上和YouTube就没法子比了

1Web服务器

YouTube出于开发速度的考虑，大部分代码都是Python开发的。Web服务器有部分是Apache，用FastCGI模式。对于视频内容则用Lig>

2视频

视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个Web页面上更是有多个，每秒钟因为这个带来的磁盘IO请求太大。YouTube技术人员启用了单独的服务器群组来承担这个压力，并且针对Cache和OS做了部分优化。另一方面，缩略图请求的压力导致Lig>

出于冗余的考虑，每个视频文件放在一组迷你Cluster上，所谓"迷你Cluster"就是一组具有相同内容的服务器。最火的视频放在CDN上，这样自己的服务器只需要承担一些"漏网"的随即访问即可。YouTube使用简单、廉价、通用的硬件，这一点和Google风格倒是一致。至于维护手段，也都是常见的工具，如rsync,SSH等，只不过人家更手熟罢了。

3数据库

YouTube用MySQL存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到SWAP颠簸的问题，解决办法是删掉了SWAP分区!管用。

最初的DB只有10块硬盘，RAID10，后来追加了一组RAID1。够省的。这一波Web20公司很少有用Oracle的(我知道的只有Bebo,参见这里)在扩展性方面，路线也是和其他站点类似，复制，分散IO。最终的解决之道是"分区",这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者ID上做文章,应用程序控制查找机制)

YouTube也用Memcached

---