LAMP架构逻辑关系和优化的思路.ppt

lamp 架构逻辑关系和优化的思路,荣新it培训中心技术研发部,目录,从何而来,知己知彼,结合实际,架构优化,深度挖掘,终极必杀,何去何从,lamp这个特定名词最早出现在1998年,当时，michael kunze为德国计算机杂志ct写作的一篇关于自由软件如何成为商业软件替代品的文章时，创建了lamp这个名词。,lamp这个特定名词最早出现在1998年,lamp这个特定名词最早出现在1998年,因为常被放在一起使用，拥有了越来越高的兼容度，共同组成了一个强大的web应用程序平台。开放源代码的lamp已经与j2ee和.net商业软件形成三足鼎立之势。,linux+apache+mysql+perl/php/python各自独立,从何而来,详细说明-技术角度,php模块方式动态编译到服务中 所有php程序交由php模块处理,提供mysqlclient.so.*.o访问接口 根据查询条件忠实的返回结果集,php 粘合剂,apache,mysql,详细说明-业务角度,linux apache mysql php,linux apache mysql,linux apache,起步,发展,成熟,知己知彼-微观,使用 curl 度量 web 站点的响应时间 $ curl -o /dev/null -s -w %time_connect:%time_starttransfer:%time_total 0.081:0.272:0.779 描述 time_connect 建立到服务器的 tcp 连接所用的时间 time_starttransfer 在发出请求之后，web 服务器返回数据的第一个字节所用的时间 time_total 完成请求所用的时间 在发出请求之后，web 服务器处理请求并开始发回数据所用的时间是 0.272 - 0.081 = 0.191 秒。 客户机从服务器下载数据所用的时间是 0.779 - 0.272 = 0.507 秒。,知己知彼-宏观,使用ab（apache bench）工具可以模拟真实访问网站的情况，拿到第一手数据。 假设我们要对 做测试，仿真 1000 次的联机请求，而且同一时间有 20 个并行的 联机请求的情况，只要在命令列模式下执行 $ ab -n 1000 -c 20 / 理论情况下： 响应时间：1000*0.191=191秒 下载时间：1000*0.507=507秒 而实际情况： 响应时间：800秒 下载时间：2234秒,大军未动，粮草先行,微观与宏观的差异说明了在网站架构中，访问数量的增加对于架构本身的压力并不是简单的乘法运算。 对于整个架构而言访问带来的压力并没有规律可言，往往是不规则的几何倍数增长。 一切皆有可能，正是这种不确定性，导致了网站架构本身需要不断的提升自身的性能来应对可能的突发状况。,服务器负载变化,100,1000,10000,100000,业务,lamp如何满足企业的不同需要？,业务,lamp如何为企业保驾护航？,技术,如何发挥lamp的最大潜能？,技术,稳定？安全？高效？冗余？伸缩？扩展？,结合实际,信息爆炸式增长,障碍集合,内容服务（apache）的关键：内存 动态语言（php）的关键：cpu 数据存储（mysql）的关键：并行写入读取 优化思路： 使用更大内存 使用多个cpu 选择更快的磁盘,解决之道,选用多核cpu（在不能更换现有其他硬件的情况下），多个cpu（在采购硬件之初）。提供并行处理、提高计算能力。 选用低存储时间的内存（一般情况下分为6、7、8、10四个等级，单位是ns）低存储时间意味着内存更高效的工作能力。 选用高转速硬盘，普通硬盘的转速分为5400rpm、7200rpm两种，而服务器专用的scsi硬盘转速基本为10000rpm有的甚至可以达到15000rpm，性能对比可想而知。,障碍集合,增加硬件是一个永无休止的无底洞，永远没有尽头。况且再好的硬件设备也有他所不可超越的极限。硬件相互的配合也是至关重要的，好的cpu没有其他硬件的配合也无法发挥出应有的作用，这就是我们常说的木桶效应。 在成本制约的前提下，如何更好的利用现有资源，才是解决问题的关键。 优化思路： linux操作系统 apache服务器 php语言 mysql数据库,操作系统-linux,安装优化 安装64位操作系统，并启用大内存支持 重新编译内核 合理分配交换分区，一般情况下为物理内存的两倍 配置优化 关闭atime（文件上次被访问的时间） 增加文件系统块文件大小，减少文件碎片加快读写速度 使用raid0+1提高系统i/o的读写能力 使用内存文件系统 禁用一切不必要的服务（x-windows） 关闭ipv6，关闭多余的控制台（保留两个即可） 增加打开文件的数量ulimit -n 8192,应用服务-apache,系统优化 echo 30000 /proc/sys/net/ipv4/tcp_max_syn_backlog 增加排队的syn报文数 echo 30000 /proc/sys/net/ipv4/tcp_max_tw_buckets 增在time-wait最大连接数 echo 30000 /proc/sys/net/ipv4/netdev_max_backlog 使用更多内存用于保存输入报文 编译优化 采用dso模式，不使用cgi模式，并去掉多余的模块 配置优化 设置最大页面文件大小、启用压缩（mod_gzip）关闭dns lookup功能 maxclients 150 （同时运行的最大进程数） maxkeepailverequest 100（最大请求数） perfork模式下（进程模式下） serverlimit 5500 maxclients 5000,胶水语言-php,编译优化 -disable-debug 关闭debug信息 -enable-inline-optimization 性能优化 缓存php脚本，不缓存的php脚本每次都要编译，因此缓存脚本将提升php 25%-100%的性能。 配置优化 set session.save_hander=mm，使会话管理时间减半 启用php的html压缩功能 max_execution_time一个脚本可使用多少 cpu 秒 30 max_input_time一个脚本等待输入数据的时间有多长（秒）60 memory_limit在被取消之前，一个脚本可使用多少内存（字节）32m output_buffering数据发送给客户机之前，有多少数据需要缓存 4096 使用第三方工具。如：apc,数据存储-mysql,系统优化 使用s.m.p支持 使用软件分条能力确保数据库中全部的表都均匀的分布在所有磁盘上。 日志应该位于单独的卷标上，如果可以最好位于单独的磁盘上。 使用hdparm优化磁盘性能 编译优化 使用pgcc并用-o6编译，mysqld服务器比用gcc 快11% 配置优化 记录慢速查询 采用数据库持久连接 key_buffer_size和table_cache 采用合适的数据表类型（myisam、innodb）,障碍集合,apache、php与mysql不同的需求，让我们在优化中无从下手，伯仲之间难以取舍。更有甚者，在资源使用重叠的部分，出现的资源抢占或资源浪费。 优化思路： 为每个应用提供专属平台，cpu给php、scsi给mysql、mem给apache、数据单独存储（i/o） 为每个应用打造定制容器，各个应用完全的分离就像。,访问,apache,php,mysql,解决之道,使用fastcgi的模式将php与web应用服务器剥离 使用mysql的主从模式将数据的读写分离 使用nfs建立数据存储中心,深度挖掘,减轻服务器压力？ 快速插入数据（快速返回）？ 使用id进行数据库查询？ 无限大的存储空间？,解决之道,使用squid反向代理 使用sphinx作为读取数据库的缓冲 使用memcache作为写入数据库的缓冲 使用分布式文件系统存储数据,合并脚本和样式表，内容过期时间优化，减少dns查询，将样式表放在顶部，将脚本放在底部,尽量使用文本，避免使用图片,apache处理php脚本的速度比处理静态页面的速度慢2-10倍，所以应尽量采取静态页面，少用脚本,将不修改的php页面改为html缓冲输出,第三方优化工具，如apache补丁，可以使apache的速度提高4倍。,触类旁通-优化策略,终极必杀,通过以上的方法，不出意外，您的lamp架构已经到达了一个登峰造极的境界。通过测试，我们也将会确实的看到一个惊人的改变，无论是单个连接的处理速度上，还是多个连接的压力下，您的lamp架构都会表现出非凡的能力。 原因很简单，因为我们一直给期望于，力图使用有限的资源去抵抗无限的可能。 在欣喜之余，我们也会发现，我们的lamp依然会有一个终极的极限，并且这个极限是无法超越的。我们似乎总是在和数字做着游戏，每次突破都需要一次近乎翻天覆地的变化，况且数字间的距离越来越小。,解决之道,复制我们现有的lamp（可能是一个，也有可能是多个）将访问平均分配到这两个或多个lamp架构中？ 负载均衡-有多远，走多远！,何去何从,lamp架构的由来 lamp架构各部件的逻辑关系 lamp架构的变迁 lamp架构的优化思路 lamp架构优化的具体实施