5

我一直在努力了解性能和可扩展性，并想知道开发人员/系统管理员正在做什么来充实他们的系统。为了使答案标准化，如果您能尽力回答以下任何问题，这将有所帮助：

  1. 简介- 在 Joomla 上发表的杂志；CodeIgniter + OpenId + AJAX 上的工作板
    • 性能-每台服务器每秒的最大请求数？
    • 硬件——服务器、路由器、磁盘、局域网？
    • 软件- Lighttpd、Memcache、Varnish、Nginx、Squid、Pound、LVS、eAccelerator 等。
    • 服务- Amazon S3、Akamai、Google 计算等。
    • 配置- 静态散列、上游模块、Memcache 在 n 个请求后 x 分钟、禁用记录图像请求等。
    • 其他——还有别的吗？（例如，规范化的表格不适合有大量读取的网站）

编辑：请在结束这个问题之前重新考虑，因为 对于网络开发人员来说，寻找这些东西很 重要。程序员可以从他/她的代码中调整分号，但仍然会输给为 memcached 编写糟糕的编码器或设法通过 Google App Engine组合一个CDN 。

4

3 回答 3

3

没有具体的性能优化总体计划（例如首先从软件“xyz”开始）。

一般的做法：

  1. 通过改进/投入时间确定（衡量！）您最可改进的实体
  2. 优化它
  3. 重复
于 2009-01-12T14:14:01.080 回答
3

我们的系统：我不能告诉你太多，但它是一个服务于许多付费客户的大型 SaaS 应用程序。

我们所做的每一项性能/容量工作都非常仔细地完成——我们不能只是尝试看看它们是否有效。

最初会对当前的性能和容量进行一些分析，我们是否可以继续工作。

如果可能的话，我们会在非生产系统上重现性能问题，我们可以在其中分析代码并进行实验性更改。我们不能总是使用与生产完全相同的硬件（生产有大量非常高规格的服务器；开发只有少数生产规格的专用性能测试箱）。

如果在非生产环境中无法对问题进行有意义的分析，我们会在生产环境中为我们的代码提供一些检测（经过仔细测试以确保检测不会影响系统本身）。该仪器将被“关闭”并有选择地打开以收集足够的数据。

一旦我们对问题进行了准确的分析，我们就会考虑可能的解决方案，并且可能会开发原型——这些可以测试功能的正确性。

如果有几个，我们通常会选择风险最小的选择。

然后将遵循正常的发布过程——大量的测试、代码审查等。

如果相关，更改可能会附带一个“恢复开关”，如果出现问题，它可以在生产中快速关闭。

我们已经确定了许多潜在的性能改进，其中大部分在出现问题之前我们不会进一步开发（除非我们无论如何都要对该软件进行不相关的重构）。

于 2009-01-11T13:18:18.370 回答
2

我没有时间逐条回答你的问题。=) 但是我可以推荐一种分离关注点的一般策略，而不是在没有立即需要时耦合服务器资源。mod_proxy（和任何等价物）是你的朋友。它使硬件出现的性能问题变得容易。当然，您不必从一开始就完美地考虑系统因素（因为很难预测真正的瓶颈会出现在哪里）。但是当你遇到问题时。记住你的朋友。

于 2009-01-11T11:05:34.813 回答