问题标签 [scaling]

我正在使用存储过程作为数据源在 Reporting Services 2005 中开发一个简单的条形图。该图中的值可以是正数也可以是负数，并且可以跨越一个非常大的范围，因此我无法指定任何适用于所有场景的非动态比例。

我面临的问题是自动缩放非常糟糕。我没有线显示零点在哪里，并且 y 尺度标签是从上到下的：

8818

-191181

-391181

等等等等……

所以我的问题是，使量表更适合人类阅读的最佳方法是什么？那里有指南吗？Reporting Services 2008 能更好地处理这个问题吗？

此外，离开 Reporting Services 并不是一个真正的选择。我意识到如何将值和表达式放在最大值、最小值和网格线间隔字段中，尽管这更像是一个问题，我应该在那里放置什么表达式。

Digg、Del.icio.us 和 StackOverflow 等网站如何实现标记？

我知道这个其他问题有一个与交叉引用表的多对多关系的公认答案。但是“大男孩”是怎么做到的呢？一样的方法？它是如何扩展的？

我们正在开发一个 .NET 应用程序，它必须对第 3 方 Web 服务进行多达数万次小型 Web 服务调用。我们更喜欢更“矮胖”的电话，但第 3 方不支持它。我们将客户端设计为使用可配置数量的工作线程，并通过测试获得了针对一台多核机器进行了相当优化的代码。但是，我们仍然希望提高速度，并且正在考虑将工作分散到多台机器上。我们精通典型的客户端/服务器/数据库应用程序，但对多台机器的设计却很陌生。因此，与此相关的几个问题：

• 除了多线程之外，是否还有其他客户端优化可以提高 http 请求/响应的速度？（我应该注意这是一个非标准的 web 服务，所以是使用 WebClient 实现的，而不是 WCF 或 SOAP 客户端）
• 我们目前的想法是使用 WCF 将工作块发布到 MSMQ，并在一台或多台机器上运行客户端以将工作从队列中拉出。我们有使用 WCF + MSMQ 的经验，但要确保我们不会错过更好的选择。今天还有其他更好的方法吗？
• 我见过一些 3rd 方工具，例如 DigiPede 和 Microsoft 的 HPC 产品，但这些似乎有点矫枉过正。对这些产品有任何经验或我们应该考虑使用它们而不是我们自己的产品吗？

通过上万个请求/秒，我希望看到 60,000 -> +90,000 个请求/秒。

我的设置包括以下内容：

用户 ---> Web 应用程序 --> 消息队列 --> 解析器 --> 数据库？

我应该提到，解析器目前可以使用 COPY 解析/填充大约 18750 条记录/秒，因此在我们开始添加更多解析器之前，我们在这方面受到限制——这对我来说现在不是一个大问题。

我有一个系统，需要能够尽可能快地批量上传尽可能多的记录。这个相同的系统（或者它可以根据您的处理方式而有所不同）应该能够响应分析类型的查询，例如：

.....10-15 千次（每个用户），因为它们被锁定到另一个表。不用说，我们现在将这些结果分页为 10/页。

我查看了以下内容：（假设这些都在同一台服务器上）

• mysql (reg. run of the mill rdbms)——能够进入 15-20,000 个请求/秒的范围；在当前条件下，如果我们尝试扩展它，我们每次需要扩展时都需要一个单独的主机/数据库——这是不可行的

• couchdb（面向文档的数据库）——没有打破 700 个请求/秒；我真的希望这能拯救我们的屁股——不是机会！

• vertica（面向列的数据库）——达到 60000 个请求/秒，封闭源代码，非常昂贵；这仍然是一个选择，但我个人根本不喜欢它

• tokyocabinet（基于哈希的数据库）——目前的重量为 45,000 次插入/秒和 66,000 次选择/秒；昨天当我写这篇文章时，我使用了一个基于 FFI 的适配器，它的性能大约为 5555 个请求/秒；这是迄今为止我见过的最快最棒的数据库！

• 兵马俑——（vm集群）目前正在与jmaglev一起评估它（不能等到maglev本身出来）——这是最慢的！

也许我只是错误地解决了这个问题，但我总是听说 RDBMS 非常慢 - 那么我听说过的这些超快速系统在哪里？

测试条件::

只是让人们知道我在我的开发盒上的规格是：

Mysql mysql.cnf 编辑为：

更新::

事实证明，terracotta 可能在我们的应用程序结构中占有一席之地，但它不会很快替换我们的数据库，因为它的速度很糟糕，而且它的堆利用率很糟糕。

另一方面，我很高兴看到 tokyocabinet 的 NON-FFI ruby​​ 库（意思是 tyrant/cabinet）超级快，现在它是第一名。

<< 1 2 3 4 ... 15 16 17 ... 47 48 49 50 >>

<< 1 2 3 4 5 6 7 ... 47 48 49 50 >>

<< 1 2 3 4 ... 44 45 46 47 48 49 50 >>

（粗体为选中页面）

是否有任何切割器逻辑可以创建这样的缩放分页？我之前已经创建了其中一个，但它最终变成了一团糟的逻辑语句。

我现在使用的语言是 PHP，但如果您有任何语言的示例或提示，将不胜感激。

通过缩放我的意思是当只有几页时。分页显示了这一点。

<< 1 2 3 4 5 6 7 >>

随着页数增长到某个点，分页将停止显示所有数字并开始将它们拆分。

<< 1 2 3 4 ... 47 48 49 50 >>

<< 1 2 3 4 5 6 ... 47 48 49 50 >>

<< 1 2 3 4 5 6 7 8 ... 47 48 49 50 >>

<< 1 2 3 4 .. 7 8 9 ... 47 48 49 50 >>

<< 1 2 3 4 .. 15 16 17 ... 47 48 49 50 >>

<< 1 2 3 4 ... 44 45 46 47 48 49 50 >>

<< 1 2 3 4 ... 47 48 49 50 >>

（注意，实际数字及其前后显示的数量不相关）

我正在整理一个 REST API，由于我不确定它将如何扩展或对它的需求是什么，我希望能够对它的使用进行速率限制以及能够在何时临时拒绝请求盒子容量已满，或者是否存在某种斜线点场景。

当/如果我需要通过添加更多容量来扩展服务时，我还希望能够暂时关闭服务（同时为客户端提供表明主要服务暂时离线的结果）。

这种事情有什么最佳实践吗？实现是带有mysql的Rails。

我希望通过将读取查询与写入查询分离到两个单独的复制 MySQL 服务器来扩展现有的 phpBB 安装。任何人都成功地做到了这一点，特别是 phpBB？

到目前为止，我最大的担忧是查询似乎散布在整个代码中。我很想听听其他人是否这样做，如果是这样，它是如何进行的/过程是什么。

我目前正面临一个性能问题（它可能会导致稍后出现扩展问题）问题。我正在处理的应用程序非常复杂，它在 SQL Server 2005 上运行。我需要加入 6 - 7 个表来获取所需的数据。到目前为止，每个表都包含超过 100,000 行数据。无法更改数据库架构（必须保持原样）。所以我只能尽量优化。我想到了两件事：

• 尽量不要加入数据库，让应用服务器使用LINQ进行过滤：

  • 优点：将能够通过添加更多应用服务器轻松扩展。
  • 缺点：更努力；我不确定响应能力是否会降低。

• 应用服务器保持原样并尽可能优化 SQL 查询（更多索引、频繁重建索引等）：

  • 优点：最小的努力
  • 缺点：当表记录变大时，问题会再次出现

基本上缓存目前不是我的解决方案（硬件问题，托管问题等），这就是我最初没有提出它的原因。但我确实知道缓存会给我带来什么好处，并且已经使用过很多次了。

我使用 glScalef() 来放大我的程序，现在当我使用代码将其恢复为原始大小时：

它在高变焦时效果不佳......（可能是因为丢失了小数点？）

我如何在没有像上面这样的任何计算的情况下将它完美地恢复到原始大小？

每当有人谈论基于服务的架构时，他们经常会提到可扩展性，而且往往是同时提到的。但是，似乎使用服务会增加而不是减少开销，因为现在涉及到一个协议，如 SOAP 或 REST。那么，当 Web 应用程序的用户数量增加一个数量级时，基于 Web 服务的架构真的会增加性能优势吗？还是只是将可扩展性需求转移到服务上，而不是核心应用程序上？