如何提高 PHP 相对于 HTML 的速度？
我有一个 PHP 文件，它从 Memcached 获取 HTML 并将其提供给用户。当我这样测试时：
ab -n 1000 -c 100 http://website.com/test.php< /p>
它执行 22 个请求每秒。
但是当我将相同的 HTML 放入 HTML 文件并进行此测试时：
ab -n 1000 -c 100 http://website.com/test.html< /p>
我得到大约 4500每秒请求数。
我需要坚持使用 PHP，因为第一次我需要生成 HTML，而下一次我只需从 Memcached 获取生成的 HTML。此外，我显示的 HTML 对于其他每个用户都是不同的（根据 $_GET ['user_id'] 值识别）。有什么办法可以让RPS更高吗？更接近于提供纯 HTML？
我使用 lighttpd 作为网络服务器。
I have a PHP file that gets HTML from Memcached and serves it to the user. When I test it like this:
ab -n 1000 -c 100 http://website.com/test.php
It does 22 requests per second.
But when I put the same HTML to an HTML file and do this test:
ab -n 1000 -c 100 http://website.com/test.html
I get like 4500 requests per second.
I need to stick to PHP because the first time I need to generate HTML, and the next times I just get the generated one from Memcached. And moreover the HTML I display is different for every other user (recognized based on $_GET ['user_id'] value). Is there any way to make RPS higher? Closer to serving plain HTML?
I use lighttpd as the web server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
思绪链（未完待续……）：
首先，我将测试问题是否是由并发触发或显着恶化。通过
-n 1000 -c 100测试，您的比率为 22/4500。-n 1000 -c 10或-n 1000 -c 1怎么样？然后我会再次尝试相同的操作 + 跟踪内存消耗、磁盘 I/O 和 CPU 使用情况。这些是否是明显的限制因素？
然后我会测试简单的 PHP 脚本：
test.html的内容复制到test.phpecho $mc->get(string $key)这些与测试.html？
编辑：
让我们来看看 Web 服务器性能比较：LiteSpeed 2.0 VS 作为比较点。该基准测试是针对另一个“竞争的”网络服务器产品进行的，但目前我们假设他们并没有（太）有偏见；-）
他们有一个
lighthttpd 每秒提供 15475 个文件（100 字节），脚本
helloworld.php1593 次每秒 399 次，phpinfo.php 每秒 399 次（均为 FastCGI）。这个比例约为 1:10 (hello world) 或 1:40 (phpinfo)。 “你”的比例是22:4500~1:200。更奇怪的是，当脚本改变时它并没有改变。您的“真实”脚本或空 PHP 脚本，无论始终为 1:22。这大大提高了“奇怪因素”（即使测试并不相同）。首先，我会仔细检查 PHP 是否是使用 FastCGI 支持编译的，请参阅 http:// /www.fastcgi.com/docs/faq.html#PHP。
然后我会使用测试中提到的一个简单的 C/C++ FastCGI 程序来测试“我的”lighthttpd，一个真正简单的“hello world”。 http://www.fastcgi 中有一个示例。 com/devkit/doc/fastcgi-prog-guide/ch2c.htm#4263。如果这个扩展“很好”，即明显优于您的 PHP FastCGI，我会尝试使用“几乎运行”的 PHP 版本，即使用
--disable-all编译，并且仅使用那些模块（重新)actived 和built-in 是启动PHP 并让它打印“hello world”所必需的。还可以使用默认的php.ini。这会改变任何吗？Chain of thoughts (to be continued....):
First I would test if the problem is triggered by or significantly worsened by concurrency. With your
-n 1000 -c 100test you had a ratio of 22/4500. What about-n 1000 -c 10or-n 1000 -c 1?Then I would try the same again + keeping track of memory consumption, disk I/O and CPU usage. Is any of this clearly the limiting factor?
Then I'd test simple PHP scripts:
test.htmlcopied over totest.phpecho $mc->get(string $key)How do those compare to test.html?
Edit:
Let's take Web Server Performance Comparison: LiteSpeed 2.0 VS as a comparison point. The benchmark was performed "for" another "rivaling" webserver product but for the moment let's assume they weren't (too) biased ;-)
They had a
The lighthttpd served 15475 files per second of 100 bytes, scripts
helloworld.php1593 times per second and phpinfo.php 399 times per second (both FastCGI). That's a ratio of ~ 1:10 (hello world) or 1:40 (phpinfo). "Your" ratio is 22:4500 ~ 1:200. And even stranger it doesn't change when the script changes. Your "real" script or an empty PHP script, no matter always 1:22. That raises the "strangeness factor" quite a bit (even though the tests are not identical).First of all I would double-check if PHP was compiled with FastCGI support, see http://www.fastcgi.com/docs/faq.html#PHP.
Then I'd test "my" lighthttpd with a simple C/C++ FastCGI program as mentioned in the test, a real simple "hello world". There's an example at http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch2c.htm#4263. If this scales "well", i.e. significantly better than your PHP FastCGI, I'd try it with a "barely running" PHP version, i.e. compiled with
--disable-alland only those modules (re)actived and built-in that are necessary to start PHP and let it print "hello world". Also use the defaultphp.ini. Does this change anything?比脚本更快？
尝试编写纯 HTML 文件并提供这些文件。并制作一个“更新程序”脚本来不时更新您的 HTML 文件，或者如果您确实需要这样的速度，则在某个事件上更新。
尝试在某些地方使用 SSI 并查看效果如何 (http://httpd.apache.org/docs/1.3/howto/ssi.html）。
尝试使用 Eaccelerator (http://eaccelerator.net/ ) 或 APC (http://www.php.net/apc/) 来加速脚本解析器，但它不会在 PHP5 上产生奇迹。 ..
确保物理服务器有足够的可用资源（快速硬盘、大量 RAM、多处理器）。
您的脚本比 HTML 页面慢是很正常的:) 提供 HTML 页面意味着简单的在线文件复制。 PHP脚本意味着初始化脚本引擎、缓存、解析类、函数、内存分配、会话锁定/解锁和保存、从Memcached服务器读取、读取配置文件。对于每个请求。
Going faster than script?
Try writing plain HTML files and serving those. And make an "updater" script that updates your HTML files from time to time, or on a certain event if you really need speed like that.
Try using SSI in some places and see how that works out (http://httpd.apache.org/docs/1.3/howto/ssi.html).
Try using Eaccelerator (http://eaccelerator.net/ ) or APC (http://www.php.net/apc/) to speed up the script parser, but it won't do wonders on PHP5...
Make sure the physical server has enough free resources (FAST hard drive, lots of RAM, multiple-processors).
It's pretty normal that your script is slower than the HTML page:) Serving up the HTML page means a simple copy-of-the-file-over-the-wire. The PHP script means initializing the script engine, caching, parsing classes, functions, memory allocations, session locking/unlocking and saving, reading from the Memcached server, reading configuration files. For each of the requests.
您可能还需要考虑在 PHP 服务器前面放置一个 HTTP 缓存。这将减少您的网络服务器上的负载，并为您处理先前渲染的页面的重新发送。
例如，请参阅 Varnish。另一个选择是 Squid
显然，如果您使用共享主机，则这些不是选项 - 在这种情况下渲染到.html 文件是一个很好的解决方案。
You might also want to consider putting a HTTP cache in front of your PHP server. This will reduce the load on your web server and will handle the re-sending of previously rendered pages for you.
See Varnish for example. Another option is Squid
Obviously these are not options if you are on shared hosting - in that case rendering to .html files is a great solution.
您可以尝试（伪代码）：
文件系统提供了一个非常好的缓存，并且 lightpd 将完成提供页面的实际工作。
You could try (psuedo code):
The file system makes is a pretty good cache and lightpd will do the actual work of serving up the page.