5

我是美国一所主要大学的网站管理员。我们的网站上有很多请求，我在过去 7 年左右的时间里建立并负责了这些请求。我一直在我们的网站中构建越来越复杂的功能，我的习惯是尽可能多地将编程负担放在我们的多处理器 Microsoft SQL 服务器上——使用存储过程、视图等，并填充——在 IIS Web 服务器中使用 PHP、ASP 或 Perl 无法完成的工作。两台服务器都是非常强大和有能力的机器。由于我一直在独自做这件事，没有其他人可以集思广益，我很好奇我的方法是否适合我们将来遇到的更高负载情况。

我的问题是：使用嵌套的 SELECT 语句、视图、存储过程和聚合函数将更多的负载负担放在 SQL 服务器上是更好的做法，还是我应该使用服务器端编译来提取多个更简单的查询并通过它们进行处理- PHP 之类的时间脚本？继续坚持还是想出更好的方法？

在进行了一些负载跟踪并了解了我在 SQL 服务器的肩上付出了多少之后，我最近对性能更加感兴趣。Web 服务器和 SQL 服务器全天都快速且响应迅速，几乎不考虑我在它们上面放了多少，但我想做好准备并通过以下方式训练自己并升级我现有的代码优化最佳实践它变得重要的时间。

感谢您的建议和意见。

4

4 回答 4

9

您将每一层放入堆栈中以在最适合的域中使用。

如果 WHERE 子句或 GROUP 子句就足够了，让您的数据库服务器发送 1000 行并使用 PHP 过滤它们是没有用的。调用数据库添加两个整数并不是最佳选择（SELECT 5+9工作正常，但 php 可以自己完成，并且您保存往返）。

您可能想要研究可伸缩性：您的应用程序的哪些部分可以划分为多个进程？如果您仍然只使用 2 层（脚本和数据库），那么那里有很大的扩展空间。但总是先从瓶颈开始。

一些示例：在 CDN 上托管静态内容，为页面使用缓存，阅读有关 nginx 和 memcached 的信息，使用 nosql (mongoDB)，考虑分片，考虑复制。

于 2011-03-05T13:58:54.403 回答
4

我的观点是，通常（大多数情况下）最好让 Web 服务器进行处理。两点：

首先是可扩展性。一旦您的应用程序获得足够的使用量，您就需要开始担心负载平衡。与设置分布式数据库集群相比，添加几个额外的指向公共数据库的 Web 服务器要容易得多。因此，最好尽可能多地从数据库中消除压力，并尽可能长时间地将其保存在一台机器上。

我想说的第二点是关于优化查询。这在很大程度上取决于您使用的查询和数据库后端。当我第一次开始使用数据库时，我陷入了使用多个 JOIN 进行复杂的 SQL 查询的陷阱，这些查询准确地获取了我想要的数据，即使它来自四个或五个不同的表。我的理由是“这就是数据库的用途 - 让它来做艰苦的工作”

我很快发现这些查询的执行时间太长了，而且经常会阻止数据库接收其他请求。虽然将查询拆分为多个请求（例如在 for 循环中）可能效率低下，但您经常会发现执行多个具有快速索引的小查询将使您的应用程序运行起来比尝试传递所有艰苦的工作要顺畅得多到数据库

于 2011-03-05T14:13:00.063 回答
0

首先，您可能想检查是否有任何负载可以通过客户端缓存（.js、.css、静态 HTML 和图像）完全删除，并使用 AJAX 等技术对屏幕进行部分更新 - 这将删除 web 和 sql 服务器上的负载。

其次，看看是否有 sql 负载可以通过 Web 服务器缓存来减少 - 例如静态或低刷新数据 - 如果您的系统上有很多“内容”页面，请查看常见的 CMS 缓存技术，这些技术将扩展到允许更多用户查看相同的数据，而无需重建页面或访问数据库。

于 2011-03-05T14:28:36.290 回答
0

我倾向于在数据库之外做尽可能多的事情，将数据库调用视为昂贵/耗时的。

例如，当对包含字段 name_given 和 name_family 的用户表执行选择时，我可以使查询变胖以返回一个名为 full_name 的列，该列由连接构建。但是这种事情可以在您的服务器端脚本语言（PHP、Ruby 等）的模型中轻松完成。

当然，在某些情况下，数据库是执行操作的更“自然”的地方。但是，总的来说，我更倾向于将负载放在 Web 服务器上，并使用其他答案中提到的许多技术进行优化。

于 2011-03-05T14:35:48.797 回答