apachebench
This article was sponsored by New Relic. Thank you for supporting the sponsors that make SitePoint possible!
本文由New Relic赞助。感谢您支持使SitePoint成为可能的赞助商！
There’s no telling when your app might attract a throng of visitors at once – maybe it’s a Hacker News post that’s submitted at a specific second on a specific time of day (as posts there tend to work), maybe it was a particularly well placed Reddit post, and maybe it’s actually good and people noticed it, spreading it virally. Regardless of the reason, massive influxes of visitors are a double-edged sword: they get you what you always wanted – a chance to prove your worth to a large chunk of the internet’s population – but also often bring with them what you always feared: absolute downtime.
没有告诉您您的应用何时可能一次吸引大量的访问者–也许这是一则Hacker News帖子，它是在一天的特定时间的特定秒提交的(因为那里的帖子可能会起作用)，也许是位置特别好的Reddit发布，也许实际上是不错的，人们注意到了它，通过病毒传播了它。 无论出于何种原因，大量的游客涌入都是一把双刃剑：他们为您提供了您一直想要的东西–有机会向很大一部分互联网人口证明您的价值–但也常常带给您您一直担心的东西：绝对停机时间。
There are several ways to try and prevent this – among the most prevalent is deploying your application on a service like Amazon, Google App Engine or Heroku which have the ability to not only scale out and in rapidly at your command, but also support automatic scaling, if you’re not afraid of DDoS attacks also scaling your bills while you’re asleep. These platforms usually offer plugins that can optimize your application while it’s up, so you can fine tune it as you go along, but why not try and predict issues while still developing locally and save yourself time, money and effort in the long run?
有几种方法可以防止这种情况发生-最普遍的方法是将应用程序部署在Amazon，Google App Engine或Heroku等服务上，它们不仅能够根据您的命令快速扩展和扩展，还支持自动扩展，如果您不担心DDoS攻击，还可以在睡眠时扩展账单。 这些平台通常提供可以在应用程序启动时对其进行优化的插件，因此您可以在进行过程中对其进行微调，但是为什么不尝试在仍在本地进行开发的同时尝试预测问题并从长远来看节省时间，金钱和精力呢？
Apache基准测试 (Apache Benchmark)
ApacheBench (also known as “ab”, the command you run it with) is a tool designed to nuke an endpoint with requests and load-test web servers. It supports a wide array of parameters and options you can tweak to simulate different loads, like number of requests, number of concurrent requests, extra headers, falsified cookies, and more.
ApacheBench(也称为“ ab”，用于运行它的命令)是一种旨在通过请求对端点进行核对并对Web服务器进行负载测试的工具。 它支持各种参数和选项，您可以调整这些参数和选项以模拟不同的负载，例如请求数，并发请求数，额外的标头，伪造的cookie等。
ab is often included with every Apache installation, but if not, you can easily install it by runningsudo apt-get install apache2-utils. The current version of Laravel Homestead doesn’t have it, so if you’re following along please install it into that VM when youvagrant upand connect through SSH.
ab通常包含在每个Apache安装中，但如果没有，则可以通过运行sudo apt-get install apache2-utils轻松安装它。 当前版本的Laravel家园没有了，所以如果你沿着以下时，请你把它安装到该虚拟机vagrant up，并通过SSH连接。
You can verify you have it installed by just runningab, which should produce a list of supported options:
您可以通过运行ab来验证是否已安装它，它会产生一个受支持的选项列表：
For our demonstration, I created a subfolder Laravel under Code in the VM, added a subfolder called “public”, and put an index.php file inside with the following content:
在我们的演示中，我在VM中的代码下创建了一个子文件夹Laravel，添加了一个名为“ public”的子文件夹，并将带有以下内容的index.php文件放入其中：
<?phpecho "Hello Test";
Inhomestead.yaml, I called this site “homestead.app”, and in myhostsfile on my host machine I added127.0.0.1 homestead.app. This allows me to run sites hosted on the Homestead VM from the host machine’s browser via http://homestead.app:8000, all standard stuff we covered before. However, this also allows you to curlhomestead.appfrom inside the VM – something we can take advantage of when bombing our app withab.
在homestead.yaml，我将此站点称为“ homestead.app”，并在hosts上的hosts文件中添加了127.0.0.1 homestead.app。 这使我可以通过http://homestead.app:8000从主机的浏览器运行Homestead VM上托管的站点，这是我们之前介绍的所有标准内容。 但是，这还允许您从VM内部卷曲homestead.app－当我们用ab轰炸我们的应用程序时，我们可以利用这一点。
测试运行 (Test run)
For starters, let’s try and nuke ourhomestead.appwith a sampleabgrenade – just runabon the URL, without any options. Note that youmustfollow the URL with a slash, otherwise you’ll get an invalid URL error from ab.
首先，让我们尝试用一个示例性的ab手榴弹对我们的homestead.app进行核对–仅在URL上运行ab，没有任何选择。 请注意，您必须在URL后面加上斜杠，否则您将从ab收到无效的URL错误。
ab homestead.app/
We can see the benchmark finishes almost instantly – the number of requests per second and concurrency load is too unreal and simple to yield useful results. In fact, running the bench multiple times will produce results from 50 to 200 possible requests per second. To provide some more tangible results, we need to up our game.
我们可以看到基准测试几乎立即完成-每秒的请求数和并发负载太虚幻且太简单，无法产生有用的结果。 实际上，多次运行工作台将每秒产生50到200个可能的请求的结果。 为了提供一些更切实的结果，我们需要改进我们的游戏。
演示应用 (Demo app)
Go outside the Laravel folder and remove it entirely withrm -rf Laravel. Next, we’ll create a default sample Laravel application with all dependencies. If you don’t have Composer installed globally yet, do it, it’s easy and fast. Then, run the following command:
移出Laravel文件夹，然后使用rm -rf Laravel完全将其删除。 接下来，我们将创建一个具有所有依赖关系的默认示例Laravel应用程序。 如果您尚未在全球范围内安装Composer， 请执行此操作 ，该操作既简单又快速。 然后，运行以下命令：
composer create-project laravel/laravel Laravel --prefer-dist
This will download the Laravel skeleton, all dependencies, and generate the autoload and lock files that are needed. You can verify it works by going to http://homestead.app:8000 on your host machine, or curlinghomestead.appinside the VM:
这将下载Laravel框架，所有依赖项，并生成所需的自动加载和锁定文件。 您可以通过在主机上访问http://homestead.app:8000或在VM内部卷曲homestead.app来验证其是否有效：
Let’s tweak the basic bench command and properly step on our app’s toes. Runab -n 500 -c 100 homestead.app/to make a more realistic test. Thenparam means “number of requests”, whilecis concurrency, as in, how many requests at a time. Thus, this command will execute 5 batches of 100 simultaneous requests.
让我们调整基本的基准命令并适当踩踏我们的应用程序的脚趾。 运行ab -n 500 -c 100 homestead.app/进行更实际的测试。n参数表示“请求数”，而c是并发，例如一次并发多少个请求。 因此，此命令将执行5个批次的100个同时请求。
The default result format you get at the end of the output will tell you how many requests (in percentage) were executed within a given timeframe, 10 by 10 per cent from 50% to 100%. In other words, if the first row is 50% 3200, that means half the total requests were executed within 3.2 seconds. For 250 requests, this isn’t bad, especially on such a weak machine.
在输出末尾获得的默认结果格式将告诉您在给定时间范围内执行了多少请求(以百分比表示)，即从50％到100％的10％到10％。 换句话说，如果第一行是3200的50％，则意味着总请求的一半是在3.2秒内执行的。 对于250个请求，这还不错，尤其是在如此弱小的计算机上。
Let’s try and slow things down on purpose. Go intoapp/controllers/HomeController.phpand change theshowWelcomefunction to this:
让我们尝试放慢速度。 进入app/controllers/HomeController.php并将showWelcome函数更改为：
public function showWelcome(){if (isset($_GET['slower']) && $_GET['slower'] == 'true') {sleep(1);} else {usleep(1);}return View::make('hello');}
If you’d like to get some more consistent results, feel free to remove the call to Google Fonts fromhello.php, as that removes the downloading lag when fetching the font and leaves everything in the hands of the VM, locally. Also, in theroutes.phpfile, replace the current closure based route with this:
如果您希望获得更一致的结果，请随时从hello.php中删除对Google字体的调用，因为这消除了获取字体时的下载延迟，并将所有内容都留在了VM的本地。 另外，在routes.php文件中，将当前基于闭包的路由替换为：
Route::get('/', 'HomeController@showWelcome');
Now try benching two different URLs:homestead.appandhomestead.app?slower=true. As expected, you’ll notice the results differ wildly. This was a completely ridiculous example, but it’s enough to demonstrate the effect a long running script can have on your visitors when they flock in en-masse. If you have long running scripts like these, it’s much better to delegate them to the background via message queues or other means, and make sure your client-facing script is as fast as you can make it.
现在，尝试使用两个不同的URL：homestead.app和homestead.app?slower=true。 不出所料，您会注意到结果大相径庭。 这是一个完全荒谬的示例，但是足以证明长时间运行的脚本可能会在访问者蜂拥而至时对访问者产生影响。 如果您有这样长时间运行的脚本，最好通过消息队列或其他方式将它们委托给后台，并确保面向客户端的脚本尽可能快。
结论 (Conclusion)
In this introduction to ApacheBench, we saw how much of an effect script efficiency had on huge traffic surges. We’ll be adding moreabtutorials further down the line, but in the meanwhile, all you should take away from this is – don’t underestimate small optimizations. There is the potential of premature optimization, but if you can detect and remove the boulders from the path sooner, the road will be smoother in the long run. Play around with ab, test it out, switch out parameters and options, add database connections to the sample Laravel app we played around with – break it, fix it, break it again. Let us know what you find – we’d love to publish your advanced use cases!
在ApacheBench的简介中，我们看到了脚本效率对大量流量激增的影响。 我们将在其后添加更多的ab教程，但是与此同时，您应该避免的是–不要小看小优化。 存在过早优化的潜力，但是如果您可以更快地从路径上检测出巨石并将其清除，则从长远来看，道路将更加平滑。 使用ab进行测试，进行测试，切换参数和选项，将数据库连接添加到我们玩过的示例Laravel应用程序中–破坏，修复，再破坏它。 让我们知道您的发现–我们很乐意发布您的高级用例！
翻译自: /stress-test-php-app-apachebench/
apachebench
