您可以在测试之前评估应用程序的性能吗？
这是前几天我被问到的一个棘手的问题...我们正在开发一个相当复杂的电话 (SIP) 应用程序，其中包含混合的 C++ 和 PHP 代码以及 MySQL 数据库和几个开源组件。
一位电信工程师要求我们评估应用程序的性能（尚未准备好）。 他说：“好吧，你知道每秒有多少数据包可以通过 Linux 内核，另外你可能知道你的应用程序有多快，所以告诉我每秒有多少个调用会通过你的东西”。
对我来说这似乎是无稽之谈，因为可能会发生一百万种情况（好吧，字面意义上的......）
但是......有没有一种方法可以估计应用程序性能（知道它将运行的硬件，能够在其上运行标准基准测试）它等）在实际测试之前？
It's a tricky question I was asked the other day... We're working on a pretty complex telephony (SIP) application with mixed C++ and PHP code with MySQL databases and several open source components.
A telecom engineer asked us to estimate the performance of the application (which is not ready yet). He went like 'well, you know how many packets can pass through the Linux kernel per second, plus you might know how quick your app is, so tell me how many calls will pass through your stuff per second'.
Seems nonsense to me, as there are a million scenarios that might happen (well, literally...)
However... is there a way to estimate application performance (knowing the hardware it will run on, being able to run standard benchmarks on it, etc) before actual testing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您当然可以将问题限制在上限（最大吞吐量）范围内。 这并没有什么废话。 事实上，不了解这些内容表明解决问题的方法相当随意——尤其是在电话领域。
您可以自己解决这个问题 - 对于一笔交易或应用程序中的任何任务单元，您必须完成的最小“工作”是多少？
例如，一些消息传入和传出、一些处理和数据库命中？ 获取各个部件的信息将使您了解最快的吞吐量。 如果您加载系统并发现性能显着降低，那么您可以花时间找出可能因低效算法等而导致吞吐量损失的地方。
编辑
要进行此练习，您需要了解所有步骤您的应用程序针对每个用例执行的操作。 然后您可以确定每个用例的最大吞吐量。 在发布和上线之前，您绝对应该了解这些内容。
我忽略了最坏情况的分析，因为正如你所指出的那样，这要困难得多。
You certainly can bound the problem with upper (max throughput) limits. There is nothing nonsense about that. In fact, not knowing that stuff indicates a pretty haphazard approach to a problem - especially in the telephony world.
You can work through the problem yourself - what is the minimum "work" you have to accomplish for a transaction or whatever unit of task you have in your app?
Some messages to and from, some processing and a database hit for example? Getting information on the individual pieces will give you an idea of the fastest possible throughput. If you load up the system and see significantly lower performance then you can take time to figure out where you are possibly losing throughput with inefficient algorithms, etc.
EDIT
To do this exercise you need to know all the steps your app does for each use case. Then you can identify the max throughput for each use case. You should definitely know this stuff prior to release and going live.
I'm ignoring the worst case analysis as that - as you point out - is quite a bit harder.
请参阅Web 性能容量规划：指标、模型和方法。 还有一些工具可以进行此类离散事件模拟：
这东西并不容易，商业工具会花费你。 《容量规划》一书附带一张 CD，其中包含大量 Excel 工作簿模板和模型示例，可以帮助您快速入门。
祝你好运 ：）
See Capacity Planning for Web Performance: Metrics, Models, and Methods. There are also some tools that can do this sort of discrete event simulation:
This stuff ain't easy, and the commercial tools will cost ya. The Capacity Planning book comes with a CD with lots of Excel workbook templates and examples of models that can jump start you.
Good luck :)
如果你真的必须回答这个问题，你可以这样说：
“我完全不知道。我愿意为你估计一下，但这需要时间。显然，我答案的准确性取决于如何回答。”我投入了多少精力（即时间）来计算我的估算。我应该投入多少时间来计算我的估算？”
把重担重新加到他们身上。 如果他们真的想要一个准确的答案，他们将不得不让您至少构建一些可以模拟实际环境的测试应用程序。
If you really have to answer this you could say something like this:
"I don't know off the top of my head. I am will to estimate this for you but it will take time. Obviously the accuracy of my answer depends upon how much effort (I.E. time) I put into calculating my estimate. How much time should I put into calculating my estimate?"
Put the burden back on them. If they really want an accurate answer, they're going to have to let you build at least some test applications that can simulate the actual environment.
您可以通过峰值来衡量性能。 您的整个系统可能尚未运行，但您知道各个部件是如何组装在一起的。 您可以在几个小时内制作出与最终应用程序在所有层上执行相同类型的工作，并使用它来衡量设计的性能。
记住：原型很宽，尖峰很深。
You can spike to measure performance. Your whole system may not be working yet, but you know how the parts are intended to fit together. You can whip something up in a few hours that does the same kind of work as the final app will, across all the layers, and use it to measure performance of your design.
Remember: prototypes are broad, spikes are deep.
你应该做一下估计。 估计不会给你正确的答案。 但它会让你思考这个问题。 现在听起来就像你在编码并希望一切都会好起来。 或者您处于恐慌状态，感觉没有时间进行估计。
花一些时间思考一下。 分析重要的用例。 考虑一下您可能需要的内存； 考虑数据库访问； 考虑网络访问（本地和远程）。 这些都会影响系统的性能。 让整个团队一起来做这件事。
在这些重要用例的开发过程中定期测量系统的性能。 如果需要的话，模拟组件/其他系统。 分析结果。 这些与您的估计相比如何？ 也许组件是内存/数据库/网络绑定的。 也许你需要更多的内存； 更少的数据库访问； 更简单的查询； 缓存。 您不必立即进行这些更改。 但是您确实知道系统如何运行以及您需要做什么。
结果： 系统测试中出现的令人讨厌的意外情况更少。 随着发布日期的临近，恐慌会减少。
You should do the estimate. An estimate won't give you the right answer. It will however make you to think about the problem. Right now it sounds like your coding and hoping that everything will be OK. Or you are in panic mode and feel you don't have time for estimates.
Spend some time thinking about it. Analyse the important use cases. Think about the memory you may need; think about database access; think about network access (local and remote). These will effect the performance of your system. Get the whole team together to do this.
Regularly measure your system's performance during development for these important use cases. Mock up components/other systems if you have to. Analyse the results. How do these compare to your estimate. Maybe components are memory/database/network bound. Maybe you need more memory; less database access; simpler queries; caching. You don't have to make these changes straight away. However you do know how your system operates and what you need to do.
Result: Fewer nasty surprises at system test. Less panic as the release date looms.
您绝对可以提前进行容量规划，但估计的质量将取决于可用数据的质量。
最好的估计是构建测试系统，运行模拟工作负载，然后根据性能要求和工作负载预测容量。 这 3 个形成了一个预测空间 - 给定 3 个中的 2 个，您可以预测第三个：
给定性能要求和容量（即硬件），您可以计算可以处理的工作负载。
给定性能要求和工作负载，您可以计算您需要的容量（即硬件）。
给定工作负载和容量，您可以预测您的预期性能。
You can definitely do capacity planning in advance, but the quality of the estimate will depend on the quality of the data available.
The best estimate is to build the system in test, run simulated workloads, then predict capacity as a function of performance requirements and workload. These 3 form a prediction space - given 2 of the 3, you can predict the third:
Given performance requirements and capacity (i.e. hardware) you can calculate the workload you can handle.
Given performance requirements and workload, you can calculate the capacity (i.e. hardware) that you need.
Given Workload and capacity, you can predict your expected performance.
在某些领域确实如此，但除非您是该领域的专家，否则您对此一无所知。 例如，我编写代码来控制工业机器人。 速度受到机器人运动的限制，而不是代码执行速度的限制。 知道机器人的速度有多快以及它需要走多远，我们就可以对“速度”做出相当好的估计。 我不知道如何估计您的申请时间。
This is true in some domains, but unless you are an expert in that domain then you don't have any idea. For example I write code to controlling industrial robots. The speed is limited by the robot motion, not by the execution speed of the code. Knowing how fast the robot is and how far it has to go, we can make fairly good estimates of "speed". I'd have no idea how to estimate time for your application.