构建高性能web站点整理.ppt

构建高性能web站点 第一部分：服务器并发处理能力 响应时间的决定因素主要包括发送的数据量和网络带宽 站点服务器每秒处理的请求数称为吞吐率，影响服务器吞吐率的因素有服务器的并发策略、I/O模型、I/O性能、CPU核数，也包括应用程序本身的逻辑复杂度。 如果用户向你抱怨在打开站点首页的时候等待了很久，究竟慢在了哪里？ 增加带宽 减少网页中的HTTP请求 加快服务器脚本计算速度 使用动态内容缓存 使用数据缓存 将动态内容静态化 更换web服务器软件 页面组件分离 合理部署服务器 使用负载均衡 优化数据库 考虑可扩展性 减少视觉等待 减少网页中的HTTP请求 设计更加简单的网页，使其包含较少的图片和脚本，但是这可能牺牲了美观和用户交互 将多个图片合并为一个文件，利用CSS背景图片的偏移技术呈现在网页中，避免了多个图片的下载 合并JavaScript脚本或者CSS样式表 充分利用HTTP中的浏览器端Cache策略，减少重复下载 响应时间与下载速度 响应时间=（数据量比特数/带宽）+(传播距离/传播速度)+处理时间 处理时间就是指数据在交换节点中为了存储转发而进行一些必要所花费的时间，其中重要的组成部分就是数据在缓冲队列中排队所花费的时间。（共享与独享带宽） 下载速度=数据字节量/响应时间 实地计算 Web服务器托管在北京的某互联网数据中心，以10M独享带宽的方式接入互联网。位于西安的一位用户通过小区提供的1M独享带宽的方式接入互联网，他通过PC的浏览器下载该Web服务器上的一个100MB大小的文件，换算成比特也就是800MB，响应时间和下载速度是多少？ 要搞清楚响应时间的消耗，必须根据实际情况，找出转发路径中是否存在一些较低带宽的交换节点，正是这些节点成为影响下载速度的瓶颈所在。 跨国运营商互联和国际出口带宽依然是残酷存在的问题。 服务器并发处理能力 吞吐率：单位时间内服务器处理的请求数 压力测试时，吞吐率的前提包括如下几个条件：并发用户数、总请求数和请求资源描述。 吞吐率是指在一定并发用户数的情况下，服务器处理请求能力的量化表现。 最大并发用户数和最大并发连接数 用户平均请求等待时间主要用于衡量服务器在一定并发用户数的情况下，对于单个用户的服务质量；服务器平均请求处理时间与前者相比，则用于衡量服务器的整体服务质量，它其实就是吞吐率的倒数。 CPU并发计算 服务器之所以可以同时处理多个请求，在于操作系统通过多执行流体系设计使得多个任务可以轮流使用系统资源，这些资源包括CPU、内存以及I/O等。 进程 进程的调度由内核来进行，从内核的观点看，进程的目的就是担当分配系统资源的实体。同时，进程也可以理解为记录程序实例当前运行到什么程度的一组数据，多个进程通过不同的进程描述符与这些数据进行关联。 每个进程都有自己独立的内存地址和生命周期。当子进程被父进程创建后，便将父进程地址空间的所有数据复制到自己的地址空间，完全继承父进程的所有上下文信息，它们之间可以通信，但是不互相依赖，也无权干涉彼此的地址空间。 进程的创建使用fork()系统调用 轻量级进程 由于进程之间相互独立，它们各自维护庞大的地址空间和上下文信息，无法很好地低成本共享数据，所以采用大量进程的web服务器（比如apache的prefork模型）在处理大量并发请求时，内存的大量消耗有时候会成为性能提升的制约因素。 为此，在linux2.0之后，提供对轻量级进程的支持，它有一个新的系统调用clone（）来实现，并由内核直接管理，像普通的进程一样，独立存在，各自拥有进程描述符，但是这些进程已经允许共享一些资源，比如地址空间、打开的文件等。轻量级进程减少了内存的开销，并为多进程应用程序的数据共享提供了直接支持，但是其上下文切换的开销还是在所难免的。 线程 如果我们希望服务器支持较大的并发数，那么就要尽量减少上下文切换次数，最简单的做法就是减少进程数，尽量使用线程并配合其他I/O模型来设计并发策略。 线程有些不是由内核来直接支持，在这种情况下，从内核角度来看，多线程只是一个普通的进程，它是由用户态通过一些库函数模拟实现的多执行流，所以多线程的管理完全在用户态完成，这种实现方式下线程切换的开销相比于进程和轻量级进程都要少些，但是它在多处理器的服务器中表现较差，因为只有内核的进程调度器才有权利分配多个cpu的时间。 POSIX线程的另一种实现是LinuxThreads,它可以说是内核级的线程库，因为它通过clone（）来创建线程，也就是说它的实现原理是将线程和轻量级进程进行一对一关联，每个线程事实上就是一个轻量级进程，这样使得线程完全由内核的进程调度器来管理，所以他对smp的支持较好，但是线程切换的开销相比于用户态线程要多一些。 进程调度器 在单cpu机器上，虽然我们感觉到很多任务在同时进行