Apache的并发数量优化设置教程

7 篇文章 1 订阅
4 篇文章 0 订阅

怎么设置apache的并发数量呢?今天我们就从多方面来给各位介绍我们在windows 服务器中apache的并发数量的一个合理的参数配置与优化方法,希望文章对大家有用。

1、在httpd.conf文件中修改

  #Server-pool management (MPM specific)
  #Include conf/extra/httpd-mpm.conf

将上面一句的#注释去掉

2、确定当前的apache是什么MPM模式(winnt模式,perfork模式,worker模式)

1.对于perfork.c模块

其特点是每个子进程只有一个线程。每个进程在某个确定的时间只能维持一个连接。在大多数平台上,Prefork MPM在效率上要比Worker MPM要高,但是内存使用大得多。prefork的无线程设计在某些情况下将比worker更有优势:它可以使用那些没有处理好线程安全的第三方模块。

既然是一个进程一个线程,所以在prefork.c下,这两个值是相等的。注:ServerLimit最大值为2000.

2.对于work.c模块来说

是多线程的,默认是一个进程有25个线程,因此如果设置ServerLimit为100,那么MaxClients最大可以设置为2500。

这里说说我们可怜的vps,为了省钱一般只有512m-1g的内存,而prefork.c一个进程占用30-45m左右的内存(这个值跟php-fpm下php-cgi内存占用相当),所以如果有512m的内存话,系统+mysql(最小节约配置)吃掉250m左右,剩下的内存也就是跑10个进程,所以这个值真的是很可怜,不过对于流量小的站点,这个并发也够用了,一般跑个上千的流量不是问题。所以做web服务,有钱还是多弄点内存的好,或者跑lnmp是比较合适的选择。

进入到apache/bin目录

cmd命令:httpd.exe -1

说明:看mpm_xxx.c 如果xxx是winnt 说明是winnt,另外还可能是perfork或者worker

3、修改httpd-mpm.conf文件

  # WinNT MPM
  # ThreadsPerChild: constant number of worker threads in the server process
  # MaxRequestsPerChild: maximum  number of requests a server process serves
  ThreadsPerChild      150  //修改这个值即可
  MaxRequestsPerChild    0

4、重启apache,测试看看

在Linux下,一般采用的MPM是perfork模式

  StartServers          5        //预先起5个进程
  MinSpareServers       5       //最小空闲进程
  MaxSpareServers      10      //最大空闲进程
  MaxClients          150      //并发连接数
  MaxRequestsPerChild   0      //指一个进程里可以起多少个线程,对worker更好,0为不限制

给大家一个合理的建议配置,对在部分网站,中型网站,配置:

  StartServers          5        //预先起5个进程
  MinSpareServers       5       //最小空闲进程
  MaxSpareServers      10      //最大空闲进程
  ServerLimit          1500     // 用于修改apache编程参数
  MaxClients          1000      //并发连接数
  MaxRequestsPerChild   0      //指一个进程里可以起多少个线程,对worker更好,0为不限制

如果你的网站pv值百万,可以这样设置:

  ServerLimit          2500     // 用于修改apache编程参数
  MaxClients          2000      //并发连接数

/*******注释********/

StartServers

指定服务器启动时建立的子进程数量,prefork默认为5。

MinSpareServers

指定空闲子进程的最小数量,默认为5。如果当前空闲子进程数少于MinSpareServers ,

那么Apache将以最大每秒一个的速度产生新的子进程。此参数不要设的太大。

MaxSpareServers

设置空闲子进程的最大数量,默认为10。如果当前有超过MaxSpareServers数量的空闲子进程,那么父进程将杀死多余的子进程。

此参数不要设的 太大。如果你将该指令的值设置为比MinSpareServers小,Apache将会自动将其修改成”MinSpareServers+1″。

MaxClients

限定同一时间客户端最大接入请求的数量(单个进程并发线程数),默认为256。任何超过MaxClients限制的请求都将进入等候队列,一旦一个链接被释放,

队列中的请求将得到服务。要增大这个值,你必须同时增大ServerLimit。

MaxRequestsPerChild

每个子进程在其生存期内允许伺服的最大请求数量,默认为10000.到达MaxRequestsPerChild的限制后,子进程将会结束。

如果 MaxRequestsPerChild为”0″,子进程将永远不会结束。将MaxRequestsPerChild设置成非零值有两个好处:

1.可以防止(偶然的)内存泄漏无限进行,从而耗尽内存。

2.给进程一个有限寿命,从而有助于当服务器负载减轻的时候减少活动进程的数量。

补充:Apache压力测试 ab工具的使用方法

打开运行输入cmd进入到DOS命令行界面,cd 进入到Apache/bin 目录,输入命令:

ab.exe –n 10000 –c 100 localhost/index.php

上面一行命令的意思是访问index.php这个页面10000次,每次的并发访问为100。执行命令之后耐心等待一段时间后就会出来类似下面的结果,图片面都有详细说明测试返回来的结果是什么意思

参数 –c concurrency 表示执行的总次数,如 –c 10000表示总共执行10000次,

参数 –n requests 表示同时连接数

 

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
整理的高性能高并发服务器架构文章,内容预览:  初创网站与开源软件 6  谈谈大型高负载网站服务器优化心得! 8  Lighttpd+Squid+Apache搭建高效率Web服务器 9  浏览量比较大的网站应该从哪几个方面入手? 17  用负载均衡技术建设高负载站点 20  大型网站的架构设计问题 25  开源平台的高并发集群思考 26  大型、高负载网站架构和应用初探 时间:30-45分钟 27  说说大型高并发高负载网站的系统架构 28  mixi技术架构 51 mixi.jp:使用开源软件搭建的可扩展SNS网站 51 总概关键点: 51 1,Mysql 切分,采用Innodb运行 52 2,动态Cache 服务器 -- 52 美国Facebok.com,中国Yeejee.com,日本mixi.jp均采用开源分布式缓存服务器Memcache 52 3,图片缓存和加 52  memcached+squid+apache deflate解决网站大访问量问题 52  FeedBurner:基于MySQL和JAVA的可扩展Web应用 53  YouTube 的架构扩展 55  了解一下 Technorati 的后台据库架构 57  Myspace架构历程 58  eBay 的据量 64  eBay 的应用服务器规模 67  eBay 的据库分布扩展架构 68  从LiveJournal后台发展看大规模网站性能优化方法 70 一、LiveJournal发展历程 70 二、LiveJournal架构现状概况 70 三、从LiveJournal发展中学习 71 1、一台服务器 71 2、两台服务器 72 3、四台服务器 73 4、五台服务器 73 5、更多服务器 74 6、现在我们在哪里: 75 7、现在我们在哪里 78 8、现在我们在哪里 79 9、缓存 80 10、Web访问负载均衡 80 11、MogileFS 81  Craigslist 的据库架构 81  Second Life 的据拾零 82  eBay架构的思想金矿 84  一天十亿次的访问-eBay架构(一) 85  七种缓存使用武器 为网站应用和访问加速发布时间: 92  可缓存的CMS系统设计 93  开发大型高负载类网站应用的几个要点 105  Memcached和Lucene笔记 110  使用开源软件,设计高性能可扩展网站 110  面向高负载的架构Lighttpd+PHP(FastCGI)+Memcached+Squid 113  思考高并发高负载网站的系统架构 113  "我在SOHU这几年做的一些门户级别的程序系统(C/C++开发)" 115  中国顶级门户网站架构分析1 116  中国顶级门户网站架构分析 2 118  服务器的大用户量的承载方案 120  YouTube Scalability Talk 121  High Performance Web Sites by Nate Koechley 123 One dozen rules for faster pages 123 Why talk about performance? 123 Case Studies 124 Conclusion 124  Rules for High Performance Web Sites 124  对于应用高并发,DB千万级数量该如何设计系统哪? 125  高性能服务器设计 130  优势与应用:再谈CDN镜像加速技术 131  除了程序设计优化,zend+ eacc(memcached)外,有什么办法能提高服务器的负载能力呢? 135  如何规划您的大型JAVA多并发服务器程序 139  如何架构一个“Just so so”的网站? 148  最便宜的高负载网站架构 152  负载均衡技术全攻略 154  海量据处理分析 164  一个很有意义的SQL的优化过程(一个电子化支局中的大据量的统计SQL) 166  如何优化据量模糊查询(架构,据库设置,SQL..) 168  求助:海量据处理方法 169 # re: 求助:海量据处理方法 回复 更多评论 169  海量据库查询方略 169  SQL Server 2005对海量据处理 170  分表处理设计思想和实现 174  Linux系统高负载 MySQL据库彻底优化(1) 179  大型据库的设计与编程技巧 本人最近开发一个访问统计系统,日志非常的大,都保存在据库里面。 我现在按照常规的设计方法对表进行设计,已经出现了查询非常缓慢地情形。 大家对于这种情况如何来设计据库呢?把一个表分成多个表么?那么查询和插入据库又有什么技巧呢? 谢谢,村里面的兄弟们! 183  方案探讨,关于工程中据库的问题. 184  web软件设计时考虑你的性能解决方案 190  大型Java Web系统服务器选型问题探讨 193  高并发高流量网站架构 210 1.1 互联网的发展 210 1.2 互联网网站建设的新趋势 210 1.3 新浪播客的简介 211 2.1 镜像网站技术 211 2.2 CDN内容分发网络 213 2.3 应用层分布式设计 214 2.4 网络层架构小结 214 3.1 第四层交换简介 214 3.2 硬件实现 215 3.3 软件实现 215  网站架构的高性能和可扩展性 233  资料收集:高并发 高性能 高扩展性 Web 2.0 站点架构设计及优化策略 243  CommunityServer性能问题浅析 250 鸡肋式的多站点支持 250 内容据的集中式存储 250 过于依赖缓存 250 CCS的雪上加霜 250 如何解决? 251  Digg PHP's Scalability and Performance 251  YouTube Architecture 253 Information Sources 254 Platform 254 What's Inside? 254 The Stats 254 Recipe for handling rapid growth 255 Web Servers 255 Video Serving 256 Serving Video Key Points 257 Serving Thumbnails 257 Databases 258 Data Center Strategy 259 Lessons Learned 260 1. Jesse • Comments (78) • April 10th 261 Library 266 Friendster Architecture 273 Information Sources 274 Platform 274 What's Inside? 274 Lessons Learned 274  Feedblendr Architecture - Using EC2 to Scale 275 The Platform 276 The Stats 276 The Architecture 276 Lesson Learned 277 Related Articles 278 Comments 279 Re: Feedblendr Architecture - Using EC2 to Scale 279 Re: Feedblendr Architecture - Using EC2 to Scale 279 Re: Feedblendr Architecture - Using EC2 to Scale 280  PlentyOfFish Architecture 281 Information Sources 282 The Platform 282 The Stats 282 What's Inside 283 Lessons Learned 286  Wikimedia architecture 288 Information Sources 288 Platform 288 The Stats 289 The Architecture 289 Lessons Learned 291  Scaling Early Stage Startups 292 Information Sources 293 The Platform 293 The Architecture 293 Lessons Learned 294  Database parallelism choices greatly impact scalability 295  Introduction to Distributed System Design 297 Table of Contents 297 Audience and Pre-Requisites 298 The Basics 298 So How Is It Done? 301 Remote Procedure Calls 305 Some Distributed Design Principles 307 Exercises 308 References 309  Flickr Architecture 309 Information Sources 309 Platform 310 The Stats 310 The Architecture 311 Lessons Learned 316 Comments 318 How to store images? 318 RE: How to store images? 318  Amazon Architecture 319 Information Sources 319 Platform 320 The Stats 320 The Architecture 320 Lessons Learned 324 Comments 329 Jeff.. Bazos? 329 Werner Vogels, the CTO of 329 Re: Amazon Architecture 330 Re: Amazon Architecture 330 Re: Amazon Architecture 330 It's WSDL 330 Re: It's WSDL 331 Re: Amazon Architecture 331  Scaling Twitter: Making Twitter 10000 Percent Faster 331 Information Sources 332 The Platform 332 The Stats 333 The Architecture 333 L

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值