PHP解决网站大流量与高并发

1:硬件方面

普通的一个p4的服务器每天最多能支持大约10万左右的IP,如果访问量超过10W那么需要专用的服务器才能解决,如果硬件不给力 软件怎么优化都是于事无补的。主要影响服务器的速度

有:网络-硬盘读写速度-内存大小-cpu处理速度。

2:软件方面

第一个要说的就是数据库,首先要有一个很好的架构,查询尽量不用* 避免相关子查询 给经常查询的添加索引 用排序来取代非顺序存取,如果条件允许 ,一般MySQL服务器最好安装

在Linux操作系统中 。关于apache和nginx在高并发的情况下推荐使用nginx,ginx是Apache服务器不错的替代品。nginx内存消耗少 官方测试能够支撑5万并发连接,在实际生产环境中跑

到2~3万并发连接数。php方面不需要的模块尽量关闭,使用memcached,Memcached 是一个高性能的分布式内存对象缓存系统,不使用数据库直接从内存当中调数据,这样大大提升了速

度,iiS或Apache启用GZIP压缩优化网站,压缩网站内容大大节省网站流量。

第二,禁止外部的盗链。

外部网站的图片或者文件盗链往往会带来大量的负载压力,因此应该严格限制外部对
于自身的图片或者文件盗链,好在目前可以简单地通过refer来控制盗链,Apache自
己就可以通过配置来禁止盗链,IIS也有一些第三方的ISAPI可以实现同样的功能。当
然,伪造refer也可以通过代码来实现盗链,不过目前蓄意伪造refer盗链的还不多,
可以先不去考虑,或者使用非技术手段来解决,比如在图片上增加水印。

第三,控制大文件的下载。

大文件的下载会占用很大的流量,并且对于非SCSI硬盘来说,大量文件下载会消耗
CPU,使得网站响应能力下降。因此,尽量不要提供超过2M的大文件下载,如果需要
提供,建议将大文件放在另外一台服务器上。

第四,使用不同主机分流主要流量

将文件放在不同的主机上,提供不同的镜像供用户下载。比如如果觉得RSS文件占用
流量大,那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主机上,这
样别人访问的流量压力就大多集中在FeedBurner的主机上,RSS就不占用太多资源了

第五,使用不同主机分流主要流量
将文件放在不同的主机上,提供不同的镜像供用户下载。比如如果觉得RSS文件占用流量大,那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主机上,这样别人访问的流量压力就大多集中在FeedBurner的主机上,RSS就不占用太多资源了。

第六,使用流量分析统计软件。
在网站上安装一个流量分析统计软件,可以即时知道哪些地方耗费了大量流量,哪些页面需要再进行优化,因此,解决流量问题还需要进行精确的统计分析才可以。比如:Google Analytics(Google分析)。

高并发和高负载的约束条件:硬件、部署、操作系统、Web 服务器、PHP、MySQL、测试

部署:服务器分离、数据库集群和库表散列、镜像、负载均衡

负载均衡分类: 1)、DNS轮循 2)代理服务器负载均衡 3)地址转换网关负载均衡 4)NAT负载均衡 5)反向代理负载均衡 6)混合型负载均衡

部署方案1:

适用范围:静态内容为主体的网站和应用系统;对系统安全要求较高的网站和应用系统。

Main Server:主服务器

承载程序的主体运行压力,处理网站或应用系统中的动态请求;

将静态页面推送至多个发布服务器;

将附件文件推送至文件服务器;

安全要求较高,以静态为主的网站,可将服务器置于内网屏蔽外网的访问。

DB Server:数据库服务器

承载数据库读写压力;

只与主服务器进行数据量交换,屏蔽外网访问。

File/Video Server:文件/视频服务器

承载系统中占用系统资源和带宽资源较大的数据流;

作为大附件的存储和读写仓库;

作为视频服务器将具备视频自动处理能力。

发布服务器组:

只负责静态页面的发布,承载绝大多数的Web请求;

通过Nginx进行负载均衡部署。

部署方案2:

适用范围:以动态交互内容为主体的网站或应用系统;负载压力较大,且预算比较充足的网站或应用系统;

Web服务器组:

Web服务无主从关系,属平行冗余设计;

通过前端负载均衡设备或Nginx反向代理实现负载均衡;

划分专用文件服务器/视频服务器有效分离轻/重总线;

每台Web服务器可通过DEC可实现连接所有数据库,同时划分主从。

数据库服务器组:

相对均衡的承载数据库读写压力;

通过数据库物理文件的映射实现多数据库的数据同步。

共享磁盘/磁盘阵列

将用于数据物理文件的统一读写

用于大型附件的存储仓库

通过自身物理磁盘的均衡和冗余,确保整体系统的IO效率和数据安全;

方案特性:

通过前端负载均衡,合理分配Web压力;

通过文件/视频服务器与常规Web服务器的分离,合理分配轻重数据流;

通过数据库服务器组,合理分配数据库IO压力;

每台Web服务器通常只连接一台数据库服务器,通过DEC的心跳检测,可在极短时间内自动切换至冗余数据库服务器;

磁盘阵列的引入,大幅提升系统IO效率的同时,极大增强了数据安全性。

Web服务器:

Web服务器很大一部分资源占用来自于处理Web请求,通常情况下这也就是Apache产生的压力,在高并发连接的情况下,Nginx是Apache服务器不错的替代品。Nginx (“engine x”) 是俄罗斯人编写的一款高性能的 HTTP 和反向代理服务器。在国内,已经有新浪、搜狐通行证、网易新闻、网易博客、金山逍遥网、金山爱词霸、校内网、YUPOO相册、豆瓣、迅雷看看等多家网站、 频道使用 Nginx 服务器。

Nginx的优势:

高并发连接:官方测试能够支撑5万并发连接,在实际生产环境中跑到2~3万并发连接数。

内存消耗少:在3万并发连接下,开启的10个Nginx 进程才消耗150M内存(15M*10=150M)。

内置的健康检查功能:如果 Nginx Proxy 后端的某台 Web 服务器宕机了,不会影响前端访问。

策略:相对于老牌的Apache,我们选择Lighttpd和Nginx这些具有更小的资源占用率和更高的负载能力的web服务器。

Mysql:

MySQL本身具备了很强的负载能力,MySQL优化是一项很复杂的工作,因为这最终需要对系统优化的很好理解。大家都知道数据库工作就是大量的、 短时的查询和读写,除了程序开发时需要注意建立索引、提高查询效率等软件开发技巧之外,从硬件设施的角度影响MySQL执行效率最主要来自于磁盘搜索、磁盘IO水平、CPU周期、内存带宽。

  根据服务器上的硬件和软件条件进行MySQl优化。MySQL优化的核心在于系统资源的分配,这不等于无限制的给MySQL分配更多的资源。在MySQL配置文件中我们介绍几个最值得关注的参数:

改变索引缓冲区长度(key_buffer)

改变表长(read_buffer_size)

设定打开表的数目的最大值(table_cache)

对缓长查询设定一个时间限制(long_query_time)

如果条件允许 ,一般MySQL服务器最好安装在Linux操作系统中,而不是安装在FreeBSD中。
策略: MySQL优化需要根据业务系统的数据库读写特性和服务器硬件配置,制定不同的优化方案,并且可以根据需要部署MySQL的主从结构。

PHP:

1、加载尽可能少的模块;

2、如果是在windows平台下,尽可能使用IIS或者Nginx来替代我们平常用的Apache;

3、安装加速器(都是通过缓存php代码预编译的结果和数据库结果来提高php代码的执行速度)
eAccelerator,eAccelerator是一个自由开放源码php加速器,优化和动态内容缓存,提高了性能php脚本的缓存性能,使得PHP脚本在编译的状态下,对服务器的开销几乎完全消除。

Apc:Alternative PHP Cache(APC)是 PHP 的一个免费公开的优化代码缓存。它用来提供免费,公开并且强健的架构来缓存和优化 PHP 的中间代码。

memcache:memcache是由Danga Interactive开发的,高性能的,分布式的内存对象缓存系统,用于在动态应用中减少数据库负载,提升访问速度。主要机制是通过在内存里维护一个统 一的巨大的hash表,Memcache能够用来存储各种格式的数据,包括图像、视频、文件以及数据库检索的结果等

Xcache:国人开发的缓存器,

策略: 为PHP安装加速器。

代理服务器(缓存服务器):

Squid Cache(简称为Squid)是一个流行的自由软件(GNU通用公共许可证)的代理服务器和Web缓存服务器。Squid有广泛的用途,从作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度,到为一组人共享网络资源而缓存万维网,域名系统和其他网络搜索,到通过过滤流量帮助网络安全,到局域网通过代理网。Squid主要设计用于在Unix一类系统运行。

策略:安装Squid 反向代理服务器,能够大幅度提高服务器效率。

压力测试:压力测试是一种基本的质量保证行为,它是每个重要软件测试工作的一部分。压力测试的基本思路很简单:不是在常规条件下运行手动或自动测试,而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。
压力测试工具:webbench,ApacheBench等

漏洞测试:在我们的系统中漏洞主要包括:sql注入漏洞,xss跨站脚本攻击等。安全方面还包括系统软件,如操作系统漏洞,mysql、apache等的漏洞,一般可以通过升级来解决。

漏洞测试工具:Acunetix Web Vulnerability Scanner

No related content found.

时间: 2024-11-11 12:00:23

PHP解决网站大流量与高并发的相关文章

PHP如何解决网站大流量与高并发

首先,确认服务器硬件是否足够支持当前的流量.普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大, 那么必须首先配置一台更高性能的专用服务器才能解决问题 ,否则怎么优化都不可能彻底解决性能问题. 其次,优化数据库访问. 前台实现完全的静态化当然最好,可以完全不用访问数据库,不过对于频繁更新的网站, 静态化往往不能满足某些功能.缓存技术就是另一个解决方案,就是将动态数据存储到缓存文件中,动态网页直接调用这些文件,而不必再访问数据库,WordPress和Z-Blog都大量使用这种

PHP如何解决网站大流量与高并发的问题

首先,确认服务器硬件是否足够支持当前的流量. 普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大, 那么必须首先配置一台更高性能的专用服务器才能解决问题 ,否则怎么优化都不可能彻底解决性能问题. 其次,优化数据库访问. 前台实现完全的静态化当然最好,可以完全不用访问数据库,不过对于频繁更新的网站, 静态化往往不能满足某些功能. 缓存技术就是另一个解决方案,就是将动态数据存储到缓存文件中,动态网页直接调用 这些文件,而不必再访问数据库,WordPress和Z-Blog都大量使

PHP解决网站大数据大流量与高并发

1:硬件方面 普通的一个p4的服务器每天最多能支持大约10万左右的IP,如果访问量超过10W那么需要专用的服务器才能解决,如果硬件不给力 软件怎么优化都是于事无补的.主要影响服务器的速度 有:网络-硬盘读写速度-内存大小-cpu处理速度. 2:软件方面 第一个要说的就是数据库,首先要有一个很好的架构,查询尽量不用* 避免相关子查询 给经常查询的添加索引 用排序来取代非顺序存取,如果条件允许 ,一般MySQL服务器最好安装 在Linux操作系统中 .关于apache和nginx在高并发的情况下推荐

网站大流量,高并发处理

第一,确认服务器硬件是否足够支持当前的流量. 普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大,那么必须首先配置一台更高性能的专用服务器才能解决问题,否则怎么优化都不可能彻底解决性能问题. 第二,优化数据库访问. 服务器的负载过大,一个重要的原因是CPU负荷过大,降低服务器CPU的负荷,才能够有效打破瓶颈.而使用静态页面可以使得CPU的负荷最小化.前台实现完全的静态化当然最好,可以完全不用访问数据库,不过对于频繁更新的网站,静态化往往不能满足某些功能. 缓存技术 就是另一

大型技术网站的技术( 高并发、大数据、高可用、分布式....)(一)

面对高并发.大流量.高可用.海量数据.用户分布广泛.网络情况复杂这类网站系统我们如何应对??? 第一阶段   一台服务器不行就上多台服务器    1.应用程序与数据服务分离        将应用程序.数据库.文件等资源放在一台服务器上,面对海量用户的访问只可能是崩崩崩的挂掉. so? 我们知道的是应用服务器.数据库服务器.文件服务器这三块对服务器的要求是不同的,应用服务器就需要大大的CPU来处理复杂的业务逻辑,数据库服务器需要快速磁盘检索      和 数据缓存也就是要大内存,而文件服务器要求的

大数据和高并发的解决方案汇总

大数据和高并发的解决方案汇总 1.3海量数据解决方案 1.使用缓存: 使用方式:1,使用程序直接保存到内存中.主要使用Map,尤其ConcurrentHashMap. 2,使用缓存框架.常用的框架:Ehcache,Memcache,Redis等. 最关键的问题是:什么时候创建缓存,以及其失效机制. 对于空数据的缓冲:最好用一个特定的类型值来保存,以区别空数据和未缓存的两种状态. 2.数据库优化: 1,表结构优化. 2,SQL语句优化,语法优化和处理逻辑优化.可记录各语句执行时间,有针对性的分析.

大数据和高并发的解决方案总结

现在,软件架构变得越来越复杂了,好多技术层出不穷,令人眼花缭乱,解决这个问题呢,就是要把复杂问题简单化,核心就是要把握本质. 软件刚开始的时候是为了实现功能,随着信息量和用户的增多,大数据和高并发成了软件设计必须考虑的问题,那么大数据和高并发本质是什么呢? 本质很简单,一个是慢,一个是等.两者是相互关联的,因为慢,所以要等,因为等,所以慢,解决了慢,也就解决了等,解决了等,也就解决了慢. 关键是如何解决慢和等,核心一个是短,一个是少,一个是分流. 短是指路径要短.典型的mvc结构是请求->con

(转)大数据量高并发的数据库优化与sql优化

大数据量高并发的数据库优化 一.数据库结构的设计 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而整个系统也不可避免的形成了一个打补丁工程. 所以在考虑整

大数据量高并发的数据库优化详解(MSSQL)

转载自:http://www.jb51.net/article/71041.htm 如果不能设计一个合理的数据库模型,不仅会增加客户端和服务器段程序的编程和维护的难度,而且将会影响系统实际运行的性能.所以,在一个系统开始实施之前,完备的数据库模型的设计是必须的. 一.数据库结构的设计 在一个系统分析.设计阶段,因为数据量较小,负荷较低.我们往往只注意到功能的实现,而很难注意到性能的薄弱之处,等到系统投入实际运行一段时间后,才发现系统的性能在降低,这时再来考虑提高系统性能则要花费更多的人力物力,而