如何最大限度地提高服务器性能？
我一直在努力了解性能和可扩展性，并想知道开发人员/系统管理员正在做什么来提高他们的系统的效率。 为了标准化答案，如果您能尽力回答以下任何一项，将会有所帮助：
- 个人资料 - Joomla 上的杂志出版物； CodeIgniter + OpenId + AJAX 上的招聘板
- 性能 - 每台服务器每秒的最大请求数？
- 硬件 - 服务器、路由器、磁盘、LAN？
- 软件 - Lighttpd、Memcache、Varnish、Nginx、Squid、Pound、LVS、eAccelerator 等
- 服务 - Amazon S3、Akamai、Google 计算等
- 配置 - 静态哈希、上游模块、n 个请求后 x 分钟的 Memcache、禁用记录图像请求等。
- 其他 - 还有其他吗？ （例如，规范化表不适合读取次数较多的网站）
编辑：在关闭此问题之前请重新考虑 as 它 是 对于 Web 开发人员来说寻找这些东西很重要。 程序员可以从他/她的代码中调整分号，但仍然会输给为 memcached 编写的糟糕编码器或设法将 CDN 通过 Google App Engine。
I have been trying to get my head around to understanding performance and scalability and would like to know what developers/sysadmins are doing to juice their systems. To standardize the answers, it would help if you could take your best shot at responding to any of the following:
- Profile - Magazine publication on Joomla; Jobs board on CodeIgniter + OpenId + AJAX
- Performance - Maximum requests per second per server?
- Hardware - Server, router, disk, LAN?
- Software - Lighttpd, Memcache, Varnish, Nginx, Squid, Pound, LVS, eAccelerator, etc.
- Services - Amazon S3, Akamai, Google compute, etc.
- Configuration - Static hashing, Upstream module, Memcache for x minutes after n requests, Disable logging image requests, etc.
- Other - Anything else? (example, normalized tables bad for sites with lots of reads)
Edit: Please re-consider before closing this question as it is important to web developers to seek out this stuff. A programmer could tweak the semicolons out of his/her code but still lose out to a bad coder writing for memcached or managing to put together a CDN via Google App Engine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们的系统：我不能告诉你太多，但它是一个大型 SaaS 应用程序，为许多付费客户提供服务。
我们所做的每一项性能/容量工作都非常仔细 - 我们不能只是尝试看看它们是否有效。
最初会对当前的表现和能力进行一些分析，看看我们是否还能继续工作。
如果可能的话，我们会在非生产系统上重现性能问题，在该系统上我们可以分析代码并进行实验性更改。 我们不能总是使用与生产完全相同的硬件（生产有大量非常高规格的服务器；开发只有几个生产规格的专用性能测试盒）。
如果在非生产环境中无法对问题进行有意义的分析，我们将在生产中的代码中添加一些工具（经过仔细测试以确保工具不会影响系统本身）。 该仪器将在运输时“关闭”并有选择地打开以收集足够的数据。
一旦我们对问题进行了准确的分析，我们就会研究可能的解决方案，也许还会开发原型——可以测试这些原型的功能正确性。
如果有多个选项，我们通常会选择风险最小的选项。
然后将遵循正常的发布过程 - 大量测试、代码审查等。
如果相关，更改可能会附带“恢复开关”，以便在出现问题时可以在生产中快速关闭。
我们已经发现了许多潜在的性能改进，其中大多数在问题发生之前我们不会进一步开发（除非我们无论如何都对该软件进行不相关的重构）。
Our system: I can't tell you much about it, but it's a large SaaS application serving many paying customers.
Every piece of performance / capacity work we do is done very carefully - we can't just try things to see if they work.
Initially there would be some analysis of the current performance and capacity, whether we could continue to work anyway.
If possible, we'd reproduce the performance problems on a non-production system where we could profile the code and make experimental changes. We can't always use the exact same hardware as production (production has a large number of very high spec servers; dev has only a few production-spec dedicated performance test boxes).
If the problem can't be analysed meaningfully in a non-production environment, we'd ship some instrumentation on to our code in production (after careful testing to ensure the instrumentation doesn't impact the system itself). This instrumentation would be shipped "off" and turned on selectively to gather enough data.
Once we'd got an accurate analysis of a problem, we'd look at possible solutions, and maybe develop prototypes - these could be tested for functional correctness.
We normally go for the least risky option if there are several.
The normal release process would then be followed - lots of testing, code reviews etc.
If relevant, the change might be shipped with a "revert switch" which allowed it to be turned off in production quickly if there was a problem.
There are many potential performance improvements we've identified, most of which we will not develop further until a problem occurs (unless we're doing an unrelated refactoring of that piece of software anyway).
没有具体的性能优化总体规划（例如首先从软件“xyz”开始）。
一般方法：
There is no concrete master-plan for performance optimisation (like start at software "xyz" first).
General approach:
我没有时间逐条回答你的问题。 =) 但我可以推荐一种通用策略，即在不需要立即需要时分离关注点，而不是耦合服务器资源。 mod_proxy（以及任何等效项）是您的朋友。 它可以很容易地用硬件来解决出现的性能问题。 当然，您不必从一开始就完美地考虑系统（因为很难预测真正的瓶颈会出现在哪里）。 但当你确实遇到问题的时候。 记住你的朋友。
I don't have the time to answer you question bullet by bullet. =) But I can recommend a general strategy of separating concerns and not couple server resources when there's no immediate need for it. mod_proxy (and any equivalents) is your friend. It makes it easy to throw hardware at performance problems that shows up. Of course, you don't have to factor the system perfectly from the start (since it's really hard to anticipate where the real bottlenecks will show up). But when you do encounter problems. Remember your friend.