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

上传人:laozhun 文档编号:2227825 上传时间:2023-02-03 格式:PPT 页数:37 大小:4.82MB
返回 下载 相关 举报
LAMP架构逻辑关系和优化的思路.ppt_第1页
第1页 / 共37页
LAMP架构逻辑关系和优化的思路.ppt_第2页
第2页 / 共37页
LAMP架构逻辑关系和优化的思路.ppt_第3页
第3页 / 共37页
LAMP架构逻辑关系和优化的思路.ppt_第4页
第4页 / 共37页
LAMP架构逻辑关系和优化的思路.ppt_第5页
第5页 / 共37页
点击查看更多>>
资源描述

《LAMP架构逻辑关系和优化的思路.ppt》由会员分享,可在线阅读,更多相关《LAMP架构逻辑关系和优化的思路.ppt(37页珍藏版)》请在三一办公上搜索。

1、LAMP 架构逻辑关系和优化的思路,荣新IT培训中心技术研发部,目录,从何而来,知己知彼,结合实际,架构优化,深度挖掘,终极必杀,何去何从,LAMP这个特定名词最早出现在1998年,当时,Michael Kunze为德国计算机杂志ct写作的一篇关于自由软件如何成为商业软件替代品的文章时,创建了LAMP这个名词。,LAMP这个特定名词最早出现在1998年,LAMP这个特定名词最早出现在1998年,因为常被放在一起使用,拥有了越来越高的兼容度,共同组成了一个强大的Web应用程序平台。开放源代码的LAMP已经与J2EE和.Net商业软件形成三足鼎立之势。,Linux+Apache+Mysql+Per

2、l/PHP/Python各自独立,从何而来,详细说明-技术角度,PHP模块方式动态编译到服务中所有PHP程序交由PHP模块处理,提供mysqlclient.so.*.o访问接口根据查询条件忠实的返回结果集,PHP粘合剂,Apache,MySQL,详细说明-业务角度,LinuxApacheMySQLPHP,LinuxApacheMySQL,LinuxApache,起步,发展,成熟,知己知彼-微观,使用 CURL 度量 Web 站点的响应时间$curl-o/dev/null-s-w%time_connect:%time_starttransfer:%time_total http:/0.081:0

3、.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 个并行的 联机请求的情

4、况,只要在命令列模式下执行$ab-n 1000-c 20 http:/理论情况下:响应时间:1000*0.191=191秒下载时间:1000*0.507=507秒而实际情况:响应时间:800秒下载时间:2234秒,大军未动,粮草先行,微观与宏观的差异说明了在网站架构中,访问数量的增加对于架构本身的压力并不是简单的乘法运算。对于整个架构而言访问带来的压力并没有规律可言,往往是不规则的几何倍数增长。一切皆有可能,正是这种不确定性,导致了网站架构本身需要不断的提升自身的性能来应对可能的突发状况。,服务器负载变化,100,1000,10000,100000,业务,LAMP如何满足企业的不同需要?,业务

5、,LAMP如何为企业保驾护航?,技术,如何发挥LAMP的最大潜能?,技术,稳定?安全?高效?冗余?伸缩?扩展?,结合实际,信息爆炸式增长,障碍集合,内容服务(Apache)的关键:内存动态语言(PHP)的关键:CPU数据存储(Mysql)的关键:并行写入读取优化思路:使用更大内存使用多个CPU选择更快的磁盘,解决之道,选用多核CPU(在不能更换现有其他硬件的情况下),多个CPU(在采购硬件之初)。提供并行处理、提高计算能力。选用低存储时间的内存(一般情况下分为6、7、8、10四个等级,单位是ns)低存储时间意味着内存更高效的工作能力。选用高转速硬盘,普通硬盘的转速分为5400rpm、7200r

6、pm两种,而服务器专用的SCSI硬盘转速基本为10000rpm有的甚至可以达到15000rpm,性能对比可想而知。,障碍集合,增加硬件是一个永无休止的无底洞,永远没有尽头。况且再好的硬件设备也有他所不可超越的极限。硬件相互的配合也是至关重要的,好的CPU没有其他硬件的配合也无法发挥出应有的作用,这就是我们常说的木桶效应。在成本制约的前提下,如何更好的利用现有资源,才是解决问题的关键。优化思路:Linux操作系统Apache服务器PHP语言MySQL数据库,操作系统-Linux,安装优化安装64位操作系统,并启用大内存支持重新编译内核合理分配交换分区,一般情况下为物理内存的两倍配置优化关闭ati

7、me(文件上次被访问的时间)增加文件系统块文件大小,减少文件碎片加快读写速度使用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

8、/netdev_max_backlog使用更多内存用于保存输入报文编译优化采用DSO模式,不使用CGI模式,并去掉多余的模块配置优化设置最大页面文件大小、启用压缩(mod_gzip)关闭DNS lookup功能MaxClients 150(同时运行的最大进程数)MaxKeepAilveRequest100(最大请求数)Perfork模式下(进程模式下)ServerLimit 5500 MaxClients 5000,胶水语言-PHP,编译优化-disable-debug关闭debug信息-enable-inline-optimization 性能优化缓存PHP脚本,不缓存的PHP脚本每次都要编

9、译,因此缓存脚本将提升PHP 25%-100%的性能。配置优化set session.save_hander=mm,使会话管理时间减半启用php的html压缩功能max_execution_time一个脚本可使用多少 CPU 秒 30max_input_time一个脚本等待输入数据的时间有多长(秒)60memory_limit在被取消之前,一个脚本可使用多少内存(字节)32Moutput_buffering数据发送给客户机之前,有多少数据需要缓存 4096使用第三方工具。如:APC,数据存储-Mysql,系统优化使用S.M.P支持使用软件分条能力确保数据库中全部的表都均匀的分布在所有磁盘上。日

10、志应该位于单独的卷标上,如果可以最好位于单独的磁盘上。使用hdparm优化磁盘性能编译优化使用pgcc并用-O6编译,mysqld服务器比用gcc 快11%配置优化记录慢速查询采用数据库持久连接key_buffer_size和table_cache采用合适的数据表类型(MyISAM、InnoDB),障碍集合,Apache、PHP与MySQL不同的需求,让我们在优化中无从下手,伯仲之间难以取舍。更有甚者,在资源使用重叠的部分,出现的资源抢占或资源浪费。优化思路:为每个应用提供专属平台,CPU给PHP、SCSI给MySQL、MEM给Apache、数据单独存储(I/O)为每个应用打造定制容器,各个应

11、用完全的分离就像。,访问,Apache,PHP,MySQL,解决之道,使用FastCGI的模式将PHP与WEB应用服务器剥离使用MySQL的主从模式将数据的读写分离使用NFS建立数据存储中心,深度挖掘,减轻服务器压力?快速插入数据(快速返回)?使用ID进行数据库查询?无限大的存储空间?,解决之道,使用Squid反向代理使用Sphinx作为读取数据库的缓冲使用Memcache作为写入数据库的缓冲使用分布式文件系统存储数据,合并脚本和样式表,内容过期时间优化,减少DNS查询,将样式表放在顶部,将脚本放在底部,尽量使用文本,避免使用图片,Apache处理php脚本的速度比处理静态页面的速度慢2-10

12、倍,所以应尽量采取静态页面,少用脚本,将不修改的PHP页面改为HTML缓冲输出,第三方优化工具,如apache补丁,可以使Apache的速度提高4倍。,触类旁通-优化策略,终极必杀,通过以上的方法,不出意外,您的LAMP架构已经到达了一个登峰造极的境界。通过测试,我们也将会确实的看到一个惊人的改变,无论是单个连接的处理速度上,还是多个连接的压力下,您的LAMP架构都会表现出非凡的能力。原因很简单,因为我们一直给期望于,力图使用有限的资源去抵抗无限的可能。在欣喜之余,我们也会发现,我们的LAMP依然会有一个终极的极限,并且这个极限是无法超越的。我们似乎总是在和数字做着游戏,每次突破都需要一次近乎

13、翻天覆地的变化,况且数字间的距离越来越小。,解决之道,复制我们现有的LAMP(可能是一个,也有可能是多个)将访问平均分配到这两个或多个LAMP架构中?负载均衡-有多远,走多远!,何去何从,LAMP架构的由来LAMP架构各部件的逻辑关系LAMP架构的变迁LAMP架构的优化思路LAMP架构优化的具体实施细节LAMP架构负载均衡当单一的LAMP不能满足日益增长的业务需求的时候,我们的目光从开始的局部,最终聚焦到了整体,从简到繁,从易到难。但我们依然相信,大凡至简,罗马不是一日建成的,任何宏观的繁琐都能具体到微观的细节,我们介绍了LAMP架构的前世今生,我们更有理由坚信,“他”的未来就在我们手中,就将在我们手中得以延续、发扬、光大!古人说:“抛砖引玉”。希望我们今天的砖可以引出诸位明天的金玉良材!,谢谢,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 建筑/施工/环境 > 项目建议


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号