运行 Drupal 基准测试的 PHP 比应有的速度慢

发布于 2024-12-27 01:13:11 字数 1978 浏览 0 评论 0原文

最初,我将其发布在 ServerFault 上...但也许这更多是一个 PHP 语言问题。

我有一台运行频率为 2.5GHz 的双至强四核 L5420 服务器。我一直在优化我的服务器,并遇到了最后的瓶颈:PHP。

我非常简单的 PHP 脚本:

./test.php

<?php print_r(posix_getpwuid(posix_getuid()));

我的不那么科学,因为他们不注意线程锁定,但科学足够给我一个-合理的多线程请求每秒结果脚本:

./benchmark-php

#!/bin/bash
if [ -z $1 ]; then
  LIMIT=10
else
  LIMIT=$1
fi

if [ -z $2 ]; then
  SCRIPT="index.php"
else
  SCRIPT=$2
fi

START=$(date +%s.%N)
COUNT=0
while (( $COUNT < $LIMIT ))
do
  php $SCRIPT > /dev/null
  COUNT=$(echo "$COUNT + 1" | bc)
done
END=$(date +%s.%N)
DIFF=$(echo "$END - $START" | bc)
REQS_PER_SEC=$(echo "scale=2; $COUNT / $DIFF" | bc)
echo $REQS_PER_SEC

./really-benchmark-php

#!/bin/bash
if [ -z $1 ]; then
  LIMIT=10
else
  LIMIT=$1
fi

if [ -z $2 ]; then
  THREADS=16
else
  THREADS=$2
fi

if [ -z $3 ]; then
  SCRIPT="index.php"
else
  SCRIPT=$3
fi

PIDS=""

echo '' > results
for thread in `seq 1 $THREADS`; do
  ./benchmark-php $LIMIT $SCRIPT >> results &
  PIDS="$PIDS $!"
done

for PID in $PIDS; do
  wait $PID
done

RESULTS=`cat results`
MATH="0"
for RESULT in $RESULTS; do
  MATH="$MATH + $RESULT"
done

echo "$MATH" | bc

运行结果 ./really-benchmark-php 100 8 test.php 每秒约 137 个请求。

在由 sqlite 或 mysql 驱动的 Drupal 实例上运行相同的脚本会返回 ~1.5 req/s。

我已经安装了 APC 和 mem_cache,并且我已经验证它们正在默认运行。 (是的,APC 的enable_cli 也打开了。)有人知道“让 PHP 执行得更快”这个神奇的开关吗?

我有一个替代配置设置(FPM/FastCGI),可以为 MySQL Drupal 安装提供约 140 个请求/秒的服务...如果 PHP 本身甚至无法从命令行提供 2 个请求/秒的服务,那怎么可能?

ab 工具的结果对我来说也一样低:

静态页面:ab -n 1000 -c 100 http://xxxx/ 每秒请求数:683.71

test php :ab -n 100 -c 5 http://xxxx/每秒请求数:41.38

drupal-mysql:ab -n 100 -c 10 http://xxxx/drupal/ 每秒请求数:0.24

drupal-sqlite:ab -n 100 -c 10 http://xxxx/drupal-test/ 每秒请求数:4.92

Originally, I posted this on ServerFault... but perhaps it is more of a PHP lingual question.

I have a server with Dual Xeon Quad Core L5420 running at 2.5GHz. I've been optimizing my server, and have come to my final bottleneck: PHP.

My very simple PHP script:

./test.php

<?php print_r(posix_getpwuid(posix_getuid()));

My not-so-scientific-because-they-don't-pay-attention-to-thread-locking-but-scientific-enough-to-give-me-a-reasonable-multithreaded-requests-per-second-result scripts:

./benchmark-php

#!/bin/bash
if [ -z $1 ]; then
  LIMIT=10
else
  LIMIT=$1
fi

if [ -z $2 ]; then
  SCRIPT="index.php"
else
  SCRIPT=$2
fi

START=$(date +%s.%N)
COUNT=0
while (( $COUNT < $LIMIT ))
do
  php $SCRIPT > /dev/null
  COUNT=$(echo "$COUNT + 1" | bc)
done
END=$(date +%s.%N)
DIFF=$(echo "$END - $START" | bc)
REQS_PER_SEC=$(echo "scale=2; $COUNT / $DIFF" | bc)
echo $REQS_PER_SEC

./really-benchmark-php

#!/bin/bash
if [ -z $1 ]; then
  LIMIT=10
else
  LIMIT=$1
fi

if [ -z $2 ]; then
  THREADS=16
else
  THREADS=$2
fi

if [ -z $3 ]; then
  SCRIPT="index.php"
else
  SCRIPT=$3
fi

PIDS=""

echo '' > results
for thread in `seq 1 $THREADS`; do
  ./benchmark-php $LIMIT $SCRIPT >> results &
  PIDS="$PIDS $!"
done

for PID in $PIDS; do
  wait $PID
done

RESULTS=`cat results`
MATH="0"
for RESULT in $RESULTS; do
  MATH="$MATH + $RESULT"
done

echo "$MATH" | bc

The result of running ./really-benchmark-php 100 8 test.php is ~137 requests per second.

Running the same script on a sqlite or mysql powered instance of Drupal returns ~1.5 req/s.

I have APC and mem_cache both installed, and I have verified that they're running on defaults. (Yes, APC's enable_cli is on, also.) Does someone know the magic "make PHP execute faster" switch?

I have an alternative configuration setup (FPM/FastCGI) that serves ~140 req/s of the MySQL Drupal install... how could that be possible if PHP itself can't even serve 2 req/s from the command line?

The result of the ab tool feel just as low to me:

static page: ab -n 1000 -c 100 http://x.x.x.x/ Requests per second: 683.71

test php: ab -n 100 -c 5 http://x.x.x.x/ Requests per second: 41.38

drupal-mysql: ab -n 100 -c 10 http://x.x.x.x/drupal/ Requests per second: 0.24

drupal-sqlite: ab -n 100 -c 10 http://x.x.x.x/drupal-test/ Requests per second: 4.92

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

美羊羊 2025-01-03 01:13:11

Drupal Core(未优化、未缓存、没有 APC 对于性能/每秒页面浏览量来说非常糟糕)。

长话短说。使用 Varnish 或其他一些反向代理缓存。

总体而言,非常令人印象深刻。我每秒可以处理的页面请求量增加了 167407.84%。

Start: 0.51
End : 854.29

这是性能上的差异,

这是我帖子中的一些相关片段,显示了不同的数字。

测试 1(获取起始基准)

运行 apache 基准

ab -k -n 100 -c 100 -g step1.txt http://example.com/how-it-works

好的,所以这个请求完全杀死了我的服务器。
参见下图。

在此处输入图像描述

因此,我决定减少请求,以便找出每秒的沼泽标准请求。我处理了 100 个请求,并发级别为 2。

结果是这样的:

Concurrency Level:      2
Time taken for tests:   197.855 seconds
Complete requests:      100
Requests per second: 0.51 [#/sec] (mean)
Time per request: 3957.105 [ms] (mean)

Test 2 APC Enabled

然后我重复了测试,但启用了 APC。

Concurrency Level:      2
Time taken for tests:   87.270 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      2138900 bytes
HTML transferred:       2096300 bytes
Requests per second:    1.15 [#/sec] (mean)
Time per request:       1745.396 [ms] (mean)
Time per request:       872.698 [ms] (mean, across all concurrent requests)

正如您所看到的,这显然更好。但仍然糟糕。每秒 1 个请求!?哈哈。那太可怕了。

测试 3 - 启用 Drupal 核心缓存

然后我启用了 Drupal 核心缓存...并重复了 apache 基准测试

ab -k -n 100 -c 5 -g test2-c5-k.txt http://example.com/工作原理

Concurrency Level:      2
Time taken for tests:   23.229 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      1923002 bytes
HTML transferred:       1880900 bytes
Requests per second:    4.30 [#/sec] (mean)
Time per request:       464.580 [ms] (mean)
Time per request:       232.290 [ms] (mean, across all concurrent requests)
Transfer rate:          80.84 [Kbytes/sec] received

所以现在我每秒收到 4 个请求。这明显更好,但总体来说还是很糟糕。

最后一步,添加反向代理缓存应用程序。我想看到什么?实际上我不在乎,任何必须优于每秒 4 个请求。如果我能达到每秒 300 个左右的请求,那么我会很高兴。任何接近 1000 个请求的请求我都会欣喜若狂。

这就是我最终得到的结果:

Concurrency Level:      300
Time taken for tests:   11.706 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    10000
Total transferred:      190260000 bytes
HTML transferred:       185140000 bytes
Requests per second:    854.29 [#/sec] (mean)
Time per request:       351.168 [ms] (mean)

总体而言,令人印象深刻。我每秒可以处理的页面请求量增加了 167407.84% 百分比。

Start: 0.51
End : 854.29

另外,我将每个请求的页面加载时间从 1978 毫秒减少到 1.17 毫秒(同时),总体速度提升了……很多。速度下降99.94%。哎哟。

在此处输入图像描述

在此输入图像描述

Drupal Core (unoptimized, uncached, without APC is terrible for performance/page views per second).

Long story short. Use Varnish or some other reverse proxy cache.

Overall, pretty impressive. I managed a percentage increase of 167407.84% in the amount of page requests I could handle per second.

Start: 0.51
End : 854.29

Here is the difference in performance and

Here is some relevant snippets from my post that shows the different numbers.

Test 1 (Get the Starting Benchmark)

Run an apache benchmark

ab -k -n 100 -c 100 -g step1.txt http://example.com/how-it-works

Okay, so this request totally killed my server.
See the graph below.

enter image description here

So then I decided to reduce the Requests in order to just figure out the bog standard requests per second. I went with 100 requests, with a level of 2 concurrency.

And came out with this:

Concurrency Level:      2
Time taken for tests:   197.855 seconds
Complete requests:      100
Requests per second: 0.51 [#/sec] (mean)
Time per request: 3957.105 [ms] (mean)

Test 2 APC Enabled

I then repeated the test but with APC enabled.

Concurrency Level:      2
Time taken for tests:   87.270 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      2138900 bytes
HTML transferred:       2096300 bytes
Requests per second:    1.15 [#/sec] (mean)
Time per request:       1745.396 [ms] (mean)
Time per request:       872.698 [ms] (mean, across all concurrent requests)

As you can see, this is visibly better. But still awful. 1 request per second!? lol. That is horrendous.

Test 3 - Enable Drupal Core Caching

I then enabled Drupal Core Caching... and repeated the apache benchmark

ab -k -n 100 -c 5 -g test2-c5-k.txt http://example.com/how-it-works

Concurrency Level:      2
Time taken for tests:   23.229 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      1923002 bytes
HTML transferred:       1880900 bytes
Requests per second:    4.30 [#/sec] (mean)
Time per request:       464.580 [ms] (mean)
Time per request:       232.290 [ms] (mean, across all concurrent requests)
Transfer rate:          80.84 [Kbytes/sec] received

So now I ended up with 4 requests per second. Which is significantly better but still generally sucks.

The final step, add a reverse proxy cache application into the mix. What do I want to see?.. I actually don’t care, anything must be better than 4 requests per second. If I can get it to around 300 requests per second, then I will be pleased. Anything close to 1000 requests I’ll be ecstatic.

This is what I ended up with:

Concurrency Level:      300
Time taken for tests:   11.706 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    10000
Total transferred:      190260000 bytes
HTML transferred:       185140000 bytes
Requests per second:    854.29 [#/sec] (mean)
Time per request:       351.168 [ms] (mean)

Overall, pretty impressive. I managed a percentage increase of 167407.84% in the amount of page requests I could handle per second.

Start: 0.51
End : 854.29

And additional I reduced the page loading time per request from 1978ms to 1.17ms (concurrently) which is a overall speed gain of … a lot. A speed decrease of 99.94%. Ouch.

enter image description here

enter image description here

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文