问题标签 [high-load]

对于一个高流量的 Sitecore 站点，应该完成什么样的定期维护任务？

目前我们：

• 分析 Sitecore、IIS 和系统日志中的错误
• 检查 IIS 日志中的响应时间是否存在容量问题

还应定期（每月）完成哪些其他任务，以确保 Sitecore 运行良好并且没有任何问题迫在眉睫？

我有一个网站，该网站将在一个地方展示，该网站将在几周内发送大量的一次性流量。

托管该网站的服务器还托管我的客户使用的控制面板。

网站部分很简单，而且大部分是静态的。但它包括一个 wordpress 博客。

我的问题我如何以及在哪里放置或缓存网站和博客，以便它能够度过流量高峰？例如，是否可以在 Amazon s3 上托管页面，以便可以通过我的域上的常规 url 访问它们而无需通过服务器？

我有一个负载很重的 MySQL 服务器（每秒约 960 次查询），有约 400 个客户端持续对其运行查询。它在一台功能强大的机器上（8 核，至强，3.3 GHz），看起来它可以跟上负载，没问题。

偶尔（每周一次），所有客户端进程会同时出错，并显示消息“未知 MySQL 服务器 'XXX'”。然后，不用我做任何事情，它们都会在短时间内恢复生机。

我将 max_connections 设置为 500，但我认为如果我超过该数字，那么我应该得到一个“连接太多”错误，而不是我看到的那个。

谁能帮我弄清楚为什么我会收到这些错误？

谢谢，
乔纳森

您如何看待，与 nginx + C++ 模块相比，为具有内置本机代码的高负载项目编写自己的 Web 服务器是一个好主意吗？生产力的提高可能微不足道吗？

与使用解释性编程语言相比，这种方法（用于 nginx 的 С++ 模块）的安全性如何？

我有一个带有权重的元素列表：

权重是小整数（例如，小于 1000，通常小于 50）。列表中的 id 总数也小于 1000。（每个id只列出一次。）

对于每个查询，我必须从列表中返回一个“足够随机”的元素。如果我进行E查询，其中与所有权重的总和成正比，则每个元素元素必须 与其值完全成比例E的相同次数。请注意，这应该适用于较小的值（例如，最多 50 * 权重总和）。另请参阅问题末尾的注释。weightE

到目前为止一切顺利，我将通过将元素 ID 放入循环列表中来解决此任务，将它们复制权重时间，然后重新排列列表。每个查询都返回列表的头部，然后增加头部位置。

但在这种情况下，我还有一个附加条件：

我对查询有附加参数：过滤器。过滤器是 的映射id => is_enabled。如果is_enabled对于给定的 是 false id，id则应将其从结果中排除。上述E限制中的值仅针对启用的元素计算。也就是说，禁用的元素权重将从查询中排除。

过滤器对于每个查询都是“唯一的”，并且包含列表中每个查询的条目id。（请注意，这意味着 2^1000 个潜在过滤器值。）

有没有办法有效地解决这个问题？我需要算法在多服务器集群上高效。

注 1：我想强调的是，我相信，完全随机选择元素（如其中一个答案所建议的那样），而不存储任何状态，是行不通的。它只会在无限数量的查询中给出完全成比例的元素数量。随机数生成器完全有权在很长一段时间内返回不公平的值。

注 2：此任务对随机性的质量没有限制。仔细想想，在上面的简单案例解决方案中，甚至没有必要对列表进行洗牌。好的随机性更好，但根本没有必要。

注意 3：请注意，2^1000 个潜在过滤器值确实意味着我无法存储与过滤器值相关的任何内容——这将需要太多内存。我可以为最近的（或经常使用的）过滤器存储一些东西，但我不能存储项目列表偏移量之类的东西，因为我不能丢失这些数据。

注意 4：我们不能通过查询返回元信息并让客户端为我们存储状态（无论如何，这是个好主意，谢谢，Diacleticus）。我们不能，因为两个客户端可能会不小心使用相同的过滤器（某些过滤器比其他过滤器更受欢迎）。在这种情况下，我们必须对两个查询使用相同的状态。事实上，客户端执行多个查询是一种相对罕见的事件。

我有很多（例如）贴有一个或多个标签的帖子。帖子可以创建或删除，用户也可以对一个或多个标签进行搜索请求（结合逻辑与）。我想到的第一个想法是一个简单的模型

创建和删除操作的实现是显而易见的。搜索更复杂。要搜索 N 个标签，它将执行 N 个 GQL 查询，例如“SELECT * FROM Post WHERE tags = :1”，并使用游标合并结果，它的性能很差。

第二个想法是将不同实体中的标签分开

它从 db 中按键获取标签（比 GQL 快得多）并将其合并到内存中，我认为此实现比第一个实现具有更好的性能，但非常频繁地可用标签可能超过允许单个数据存储对象的最大大小. 还有另一个问题：数据存储区只能修改一个对象约 1/秒，因此对于经常使用的标签，我们也存在修改延迟的瓶颈。

有什么建议么？

谁能告诉我，在高负载系统中使用多线程的最佳架构模式或方式是什么？我已阅读有关多路复用方法的信息，还有其他内容吗？谢谢。

我需要创建专门的 HTTP 服务器，为此我计划使用 epoll sycall，但我想利用多个处理器/内核，我无法提出架构解决方案。ATM 我的想法是：创建多个线程，使用自己的 epoll 描述符，主线程接受连接并将它们分布在线程 epoll 之间。但是有没有更好的解决方案？我可以阅读哪些关于高负载架构的书籍/文章/指南？我只看过C10K文章，但大多数示例链接都已失效 :( 并且仍然没有关于此主题的深入书籍 :(。

谢谢你的回答。

UPD：请具体一点，我需要材料和示例（nginx 不是示例，因为它太复杂并且有多个抽象层来支持多个系统）。

我的环境：Windows Server 2008、IIE 7.0、ASP.NET

我开发了一个 Silverlight 客户端。此客户端通过 WCF Web 服务从 ASP.NET 主机获取更新。

当我们的用户数量非常少（约 50 个）时，我们会获得 100% 的 CPU 使用率和连接中断。服务器显然应该能够处理更多的事情。

我在我们的 DEV 服务器上运行了一些测试，确实 100 个请求 / 秒使 CPU 最大化。奇怪的是，即使该服务被一个发送回硬编码数据的虚拟服务所取代，该服务仍然会耗尽 CPU。线程数看起来非常低，大约为 20，所以我认为某处存在一些争用。

我更改了所有可以找到的配置选项以增加工作线程（processModel和httpRuntime注册表MaxRequestsPerCPU项）。没有改变。

然后我停止了 IIS 服务器并将 Web 服务作为控制台运行（删除所有 ASP 身份验证引用）。该服务也最大限度地利用了 CPU。

然后是神奇的部分：我杀死了控制台应用程序并重新启动了 IIS，现在该服务运行 5-60% 的 CPU，每秒 100 个请求，我可以看到 50+ 个工作线程。我在我们的 preprod 机器上做了同样的事情，并产生了同样的神奇效果。重新启动机器可以保持良好的行为。

所以我的问题是：修复我的 IIS 服务器发生了什么？我真的不明白是什么解决了它。

干杯。

我正在设计一个 HTTP 服务，每天最多可处理 5 亿个请求（由多台独立机器提供服务）。

对于每个请求，我必须生成唯一 ID 并将其返回给用户。ID 必须在 10 分钟的窗口内 100% 唯一。（首选 1 天，全局唯一 ID 是理想的。）生成该 ID 不需要服务器-服务器通信。

愚蠢的伪会话示例：

在此 HTTP 服务的上一代中，我使用了 UUID。

我对 UUID 很满意，但有一个问题：它们太长了。在这个数量的请求中，这个额外的大小在日志文件的磁盘空间浪费中是显而易见的。

创建简短但唯一的标识符的最佳方法是什么？我想，为了让事情变得有价值，算法应该最多产生一半的 UUID 长度，同时全天都是唯一的（10 分钟应该更短）。

理想情况下，建议的算法将在纯 C 中具有健全、轻量级的生产质量实现。

更新：在 GET 请求中传递时，生成的 ID 不应需要 URI 编码。