### Lighttpd优化指南 #### 概述 在IT领域,特别是Web服务器管理与优化方面,Lighttpd作为一款轻量级的Web服务器软件,在处理高并发请求时表现出了其独特的优势。本指南旨在帮助系统管理员及开发人员通过优化Lighttpd配置来提升FastCGI性能,尤其是针对PHP应用的服务能力。 #### FastCGI性能优化 当你面临“我的网站需要多少个PHP后端?”或者“为什么我的应用会偶尔返回500错误?”等问题时,本文将提供详细的解答和优化建议。 ##### 计算所需PHP进程数量 在计算所需PHP进程数量的过程中,首先要了解Lighttpd如何管理管道(pipe):一边是用户的Web浏览器,另一边是PHP后端服务。当接收到的请求超过后端能处理的数量时,Lighttpd会将额外的请求放入队列中等待处理。如果队列过载,则新来的请求会被拒绝,并在错误日志中记录类似“load=380”的消息。 假设每秒有100个PHP请求,而平均每个请求处理时间为0.1秒。在这种情况下: \[ 100 \text{ PHP请求/秒} \times 0.1 \text{ 秒/PHP请求} = 10 \text{ PHP进程} \] 由于无法控制进入的请求量,因此可以通过减少单个PHP进程中的平均请求处理时间来提高性能。 ##### 减少平均请求处理时间的方法 1. **使用字节码缓存**:例如Xcache(<http://xcache.lighttpd.net/>)或APC(<http://pecl.php.net/APC>),它们可以显著降低脚本解析时间。 2. **增加应用级别的缓存**:通过缓存常用数据,减少数据库查询次数。 3. **优化数据库查询**:审查并优化慢查询,确保索引被正确使用。 #### 测量平均请求时间 直接测量平均请求时间并非易事,但Lighttpd提供了相关统计信息作为参考指标,如“fastcgi.backend.0.load:22”,表示当前有多少个PHP进程正在被使用。 #### 监控负载情况 为了更好地监控服务器状态和FastCGI模块的性能,需要加载`mod_status`模块并启用统计功能。 ```conf server.modules = { "mod_status", } status.statistics-url = "/server-counters" ``` 通过访问`/server-counters`页面,可以获得以下信息: - FastCGI模块处理过的总请求数。 - 正在等待处理的请求总数。 - 每个后端正在等待处理的请求数量。 **注意事项**:如果有多个后端,应分别为每个后端命名。 ```conf fastcgi.server = ( ".php" => ( "backend1" => ("host" => "php-srv1"), "backend2" => ("host" => "php-srv2") ) ) ``` 示例输出: ``` fastcgi.active-requests: 22 fastcgi.waiting-requests: 5 ``` 这些统计信息有助于理解服务器当前的工作负载以及是否存在瓶颈问题。 #### 结论 通过对Lighttpd进行适当的配置调整和优化,可以显著提高FastCGI服务的性能,特别是在处理大量并发请求时。通过合理规划和实施上述策略,不仅能够改善用户体验,还能有效利用资源,减少服务器维护成本。
==============================
Optimizing FastCGI performance
==============================
.. contents::
Overview
========
If you've recently asked yourself
* "How many PHP backends do I need for my load?" or
* "Why is my application returning an error 500 from time to time?"
then you'll want to read this article very carefully.
How many PHP processes do I need?
=================================
That's the question you're looking for the answer to, and to answer it, it's probably easiest to use an example.
lighty is managing a pipe. On one side are your users with their web browsers, on the other side is PHP. If
you have more incoming requests than your backends can handle, lighty will queue them up and will push the new
requests to the backends when they are free again. If you have so many requests that the queue fills up, it will burst and the next
requests to this backend will be denied, and you'll see a message in the error log like this: ::
... load = 380 ...
To calculate the number of backends you need, consider this:
* you have 100 PHP requests per second
* the average request time on the PHP side is 0.1sec
In the average case you need: ::
100 PHP requests/sec * 0.1sec/PHP request = 10 PHP processes
Since you probably can't control the number of incoming PHP requests, the best you can do is to reduce the average
request time spent in the PHP process. Some ideas:
* Use a byte-code cache like http://xcache.lighttpd.net/ or http://pecl.php.net/APC
* Add caching to your application
* Tune your database queries
Measuring the average request time is not that easy, so output like "fastcgi.backend.0.load: 22" is an indicator
of how many PHP processes would be used right now.
Measuring the load
==================
Load the status-module and enable the statistics: ::
server.modules = {..., "mod_status", ... }
status.statistics-url = "/server-counters"
The counters page lists serveral counters of the fastcgi module:
* the total number of requests handled by the module
剩余10页未读,继续阅读
- 粉丝: 238
- 资源: 1608
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助