![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
您的车正缓慢地行驶在路上，风透过打开的窗户刮了进来，您用脚踩了油门。您认为在这个速度上，其他汽车的表现都比不上您的汽车 —— 但是突然，您遇到了一个急转弯！您的心提到了嗓子眼里并且立即松开油门，同时尽可能快地转方向盘。您成功了！您的汽车表现得非常专业。
您的 Domino 服务器就好比您的汽车。您可以根据一些基本准则来判断它的性能。您可以将速度、容量或性价比作为单独的标准进行衡量，或者可以查看整体的性能。您真正想要从 Domino 服务器中获得的（就好比对汽车的要求）就是处理所有 Dominous 服务器管理（道路）问题的能力。
本文将针对不同的系统配置以及在不同的工作负载下查看 Domino 的性能。为此，我们将检验 6 种不同评估场景下的性能结果，并了解在特定工作负载下如何衡量每种配置。这些评估场景帮助我们得出以下方面的性能结论：
- 服务器使用的处理器资源的数量
- 服务器使用的内存的数量
- 探针（probe）响应时间（和用户响应时间）
- 磁盘输入和输出（I/O）的总体性能
- 每秒内存分页
- Notesmark（Domino 事务）性能
通过评估每个评估场景提供的 “曲线” 图，可以从总体上把握 Domino 的性能。您或您的供应商可以评估某种系统配置在给定工作负载下的执行情况，并确定在这种工作负载下占用的容量。
有关如何针对 Lotus/Iris 实施性能分析的更多信息，或者有关所使用的工具的简介，请阅读 “优化服务器性能：端口加密和缓冲区设置” 或 “优化服务器性能：CPU 可伸缩性”。要阅读改善服务器性能的更多建议，请参考 “提升服务器性能的十大方法”。
本节介绍了我们在所有测试场景中使用的总体测试方法。它包括针对每个系统的系统配置、有关工作负载的详细信息以及有关主要容量规划工具 Server.Planner 的信息。
系统配置是根据价格和性能之间的权衡进行选择的。同样，系统代表了各种类型的典型客户生产环境。样例选择是通过调整内存、处理器速度、处理器数量等配置选项产生的。并且，它还在测试中展示了最新发布的系统，从而引起人们对这些新系统的关注。执行这些测试的人员应当遵循 NotesBench Consortium 内部确立的协议。此外，还制定了另外一套协议，描述应该在 Domino Server.Planner 数据集中应包含哪些数据集，从而给出最终用户在其环境中的实际使用建议。
为了运行全部 4 个测试，我们设置了 5 个系统 —— 每个系统使用了一个稍微不同的配置，如下所示：
系统 1
- 系统：IBM 704
- CPU：一个 200MHz Pentium Pro
- 硬盘驱动器：10 Spindles（4GB 磁盘）
- Raid 级别：RAID5
- 网络：TCP/IP
- 内存：512MB
- OS：Windows NT 4.0
- Domino：Release 4.6x
系统 2
- 系统：IBM Netfinity 3500
- CPU：1 个 233MHz Pentium II
- 硬盘驱动器：2 Spindles（4.51GB 磁盘）
- Raid 级别：RAID5
- 网络：TCP/IP
- 内存：320MB
- OS：Windows NT 4.0
- Domino：Release 4.6x
系统 3
- 系统：IBM 325
- CPU：1 个 233MHz Pentium II
- 硬盘驱动器：9 Spindles（4.51GB 磁盘）
- 网络：TCP/IP
- 内存：384MB
- OS：Windows NT 4.0
- Domino：Release 4.6x
系统 4
- 系统：IBM 330
- CPU：1 个 300MHz Pentium II
- 硬盘驱动器：10 Spindles（4.51GB 磁盘）
- Raid 级别：RAID5
- 网络：TCP/IP
- 内存：512MB
- OS：Windows NT 4.0
- Domino：Release 4.6
系统 5
- 系统：IBM Netfinity 7000
- CPU：2 个 200MHz Pentium Pro
- 硬盘驱动器：10 Spindles（4.5GB 磁盘）
- Raid 级别：RAID5
- 网络：TCP/IP
- 内存：1280MB
- OS：Windows NT 4.0
- Domino：Release 4.6
工作负载来自 NotesBench 基准测试环境，由 NotesBench Consortium 定义。NotesBench Consortium 是一个独立的非盈利性组织，专门致力于为客户提供 Domino 和 Notes 性能信息。当用户数量和工作负载类型发生变化时，所执行的工作负载都可以有效地保持恒定。使用这些工作负载可以帮助我们捕捉并分析运行不同 NotesBench 工作负载时的幕后性能特征。
下面列出了每个工作负载及其特征：
- 邮件：这种工作负载在只依赖邮件通信的站点为 Notes 邮件用户建模服务器。
- 邮件和共享数据库（有时称为 MailDB）：这种工作负载为那些只执行邮件和简单共享数据库操作的活动用户建模服务器。
- 共享数据库（有时称为 DiscDB）：这种工作负载为那些只执行大量共享数据库操作的活动用户建模服务器。
- 群件（Groupware）：这种工作负载是针对处理大量信息的 Notes 用户的容量测试。这种工作负载对使用最消耗资源的 Notes 特性的站点进行建模。它可以用于确定在最坏情况下服务器可以支持的最大用户数量的下界。Groupware 测试包括邮件、共享数据库活动加邮件（消息量为 532KB）以及重复用于测试中的系统的用户。
测试这组工作负载非常有趣，因为它展示了在服务器上运行不同工作负载时，不同用户的行为以及对资源产生的影响。
Domino Server.Planner 是一个容量规划工具，它可以针对基准数据衡量用户需求，从而给出服务器配置建议。要了解有关 Domino Server.Planner 的更多信息，请阅读 Notes.net 文章 “使用 Domino.Server.Planner 模拟您的工作负载环境”。一般情况下，我们在测试中使用的数据都遵循提交 Server.Planner 数据测试结果的指导原则。NotesBench Consortium 制定了提交供应商数据集的指导原则：
NotesBench Consortium 最初确定的指导原则专门针对 IBM 数据集的提交，内容如下：
- 所提交的结果应当使用 50% 到 70% 的 CPU
- Server.Planner 探针响应时间不应超过 5 秒（这是最终用户的响应时间）
- 配置的最大容量已经由独立的 NotesBench 工作负载评估工作确定
- 熟悉 NotesBench 工具和 Consortium 协议的审计人员（比如 KMDS 技术助理）必须复核测试结果
供应商使用 NotesBench 工具在特定工作负载下运行测试，然后将测试结果存储到 Server.Planner 中。即使测试尚在进行中，运行在 Windows NT 上的性能测试工具 NT Performance Monitor (PerfMon) 也可以监视 Domino 服务器。随后，他们从 Server.Planner 中取出测试结果，并从 Perfmon 获得监视结果，并确保符合 Server.Planner 容量规划验收标准。通过查看本文提供的图形，我们进一步分析了性能和容量结果。
通常来讲，通过依次查看 CPU 使用量、内存使用率、磁盘行为（如果可以的话），我们可以对测试数据进行分析。在分析系统性能时，我们使用的工作负载中存在一些变化因素。我们对每一个工作负载至少运行两个配置。我们收集有限的 Perfmon 统计数据，并且所收集的对象出现了一些微小的变化。随着测试的深入，我们将重新评估收集的性能指标。
通过对测试进行分析，我们发现，在图表中清晰地界定所收集数据的平均值和数据结果的近似上限非常重要。所谓上限，我们指的是您可以使用并且目前为止实际用于系统的内存的最大值或最高使用量。确定系统性能与上限之间的关系也非常重要，因为这可以帮助我们判断系统的增长潜力，并且可以确定出最终用户的响应时间。此外，当我们在测试场景中确定了上限之后，我们发现，频繁地接近或超出建议的最大值对于整个系统来说确实是一个问题。这意味着在作出任何建议或确定真正的瓶颈之前，需要测试和评估性能的其他方面。这一点对于本文稍后即将讨论的每秒内存分页指标来说尤为明显。
在这第一个评估场景中，我们将查看系统在每种工作负载下的 CPU 使用量。我们使用 Windows NT Perfmon 实用工具捕捉信息。当配置多个 CPU 时，我们使用 System Object 指标，也被称为 % Total Processor Time（用来度量结合多个处理器之后的处理器利用情况）。NT PerfMon 实用工具对这一指标的定义如下：“% Total Processor Time 指系统上所有处理器执行非空闲线程的平均时间百分比。在一个多处理器系统上，如果所有线程始终处于繁忙状态，那么 % Total Processor Time 达到了 100%。如果所有处理器的繁忙百分比为 50%，那么 % Total Processor Time 为50%。那么，如果四分之一的处理器的繁忙百分比为 100%，那么 % Total Processor Time 为 25%。它可以被看作是用来执行有用工作的时间片段”。
您可以通过相关文章 CPU 使用量测试结果 了解这个测试的结果。
根据图表显示的信息和其他测试数据，我们可以观察到以下信息：
- 生产环境的处理器的最大使用量在 75% 左右。这与 NotesBench Consortium 推荐的 70% 的最大值相符。
- 跨越所有工作负载的处理器平均使用量基本相同，在 30% 左右。这一数字会产生误导，因为对于不同工作负载，获得的最大用户数的范围会发生变化，但是所包含的数据仍然符合指导原则中指定的 75% 的最大值。当我们获得最大曾达到 75% 的数据并将其平均到多个数据点时，图表平均值为 30%。这表示，根据可以在相应响应时间内执行工作负载的用户数量，单个工作负载的用户配置将会影响处理器的使用量。总的工作负载耗尽了相同数量的 CPU（通过测试定义），但是由于单个用户行为的特殊性，用户数量是不同的。您在评估用户行为时应当考虑到这一点。
可以使用多种不同方法分析和比较测试数据，下面是其中一些：
- 可以根据一个给定的用户数量值比较测试结果。例如，可以看到在 1200 名邮件用户的情况下，系统 7000 的 CPU 使用量为 40%（严格来讲，为 20% 乘以 2 个处理器）。而系统 325 要实现相同的用户数，需要使用 65% 的 CPU。在对系统 7000 和系统 325 进行比较时，处理器使用量（40% 和 65%）表示处理器需求增加了超过 50%。
- 您可以根据系统的 CPU 使用量比较测试结果。对于 Groupware 工作负载，运行在系统 7000 上的 375 个用户使用了 45% 的 CPU。再看看系统 704，45% 的 CPU 使用量只能够处理 250 名用户。要理解容量方面的增长：（375-250）/250 表示系统 7000 的容量要比系统 704 的容量多出 50%。系统 7000 中的额外处理器为性能作出了额外的贡献。
如果从 CPU 使用量的角度查看结果的话，会发现系统 7000 是一个功能更加强大的配置。与其他系统配置相反，系统 7000 的 CPU 使用量出现了下降。同样，对于 Groupware 工作负载，超过 150 名用户后，系统 7000 的性能要明显更好一些。相同的优势也出现在其他工作负载中：500 至 600 名用户情况下的邮件工作负载，以及 600 名用户情况下的邮件和共享数据库工作负载。对于系统 7000，惟一一个没有表现出更好性能的工作负载是共享数据库工作负载。
类似地，图表中的结果还指出系统的可用内存量对 Notes 有巨大的影响。额外的内存和处理器对 Groupware、邮件、邮件和共享数据库的性能会产生积极的影响。这一点对于共享数据库（DiscDB）工作负载并不总是正确的。在这种工作负载下，磁盘 I/O 是系统性能的决定因素（因为系统 330 和系统 7000 之间不存在主要的性能差异）。在查看共享讨论数据库（Shared Discussion Database）工作负载的结果时，磁盘 I/O 或网络接口似乎都是性能瓶颈，因为内存量或处理器数量的变化对这些机器的性能并没有产生重大影响。
在对系统 7000 增加更多的内存和处理器后，通常可以观察到以下这些处理器改善：
- Groupware 工作负载：CPU 减少 20%
- 邮件工作负载：CPU 减少 15% 到 20%
- 共享邮件和数据库工作负载：CPU 减少 15% 到 30%
- 数据库工作负载：CPU 减少 0% 到 10%
这些统计数据表明，平均情况下，对于 Groupware 工作负载，系统 7000 的性能要比进行评估的其他系统高出 20%。我们将这个性能改进归功于额外的处理器和内存。
在第二个评估场景中，我们将查看系统在每个工作负载下的内存使用量。我们使用 Windows NT Perfmon 实用工具来捕获信息。
要计算使用的内存，我们从内存对象 Available Bytes Counter 中减去系统中可用的总内存量。NT 的 PerfMon Utility 将 Available Bytes Counter 定义为 “Zeroed、Free 和 Standby 列表中当前列出的虚拟内存的大小。Zeroed 和 Free 内存可以随时使用，并且 Zeroed 内存被清零。Standby 内存指被从进程的 Working Set 中移除但仍然可用的内存”。因此，Memory Used 指标表示 Domino Server 以及底层平台操作系统所需的空间。
您可以从相关文章 “CPU 使用量测试结果” 中了解本次测试的结果。
根据图表显示的信息和其他测试数据，我们可以观察到以下信息：
- 一般情况下，在任何系统上都应该为 Domino 服务器预留不少于 4MB 的空闲内存。
- 对于邮件工作负载、邮件和共享数据库工作负载，平均内存使用量更高，但要注意，这两种工作负载拥有的用户数也是最多的（达到 1800 名用户，因此将打开更多的数据库和文件锁）。
- 一般而言，系统 7000 对相同的工作负载使用更多的内存。似乎可用内存越多，内部计算逻辑就可以进一步利用额外的空间。
- 我们在一些配置中接近了最大内存使用量（这些配置的内存量较低）。如果在这个用户数量外还存在额外的数据点，那么就没有额外的内存用于处理额外的用户。
根据图表中的信息，现在可以将一些指标组合起来，形成有关系统需求的指导原则。
在第三个评估场景中，我们将评估不同工作负载下的探针响应时间。要实现这个测试目的，我们使用了 Server.Planner 进程，在这个进程中，一个 “探针” 任务将每分钟执行一次，打开并关闭共享的讨论数据库。这一指标模拟了最终用户的响应时间，并且是反映最终用户响应时间的最佳指标。探针结果代表了 Groupware、共享邮件和数据库、共享数据库工作负载的 “最坏情况” 分析，因为工作负载与之进行交互的共享数据库也是由探针任务打开的。邮件工作负载的探针任务没有报告相同程度的共享数据库争用，因为数据库并没有被作为工作负载的一部分使用。然而，探针任务仍然可以作为 Domino 服务器整体性能的一个指标。
您可以在相关文章 “探针响应时间测试结果” 中查看本次测试的结果。
根据图表显示的信息和其他测试数据，我们可以将探针响应时间值划分为不同的等级。我们使用 Server.Planner 中的分类并且认为：
- 1 秒的响应时间属于快速响应时间
- 1 到 3 秒的响应时间属于中等速度的响应时间
- 3 到 5 秒的响应时间为慢速响应时间
最终用户会发现探针响应时间测试非常有趣，并且可以从这些信息中获得最大受益。这是因为这些信息显示出用户在使用系统时的需求。
查看图表中显示的平均探针时间，我们注意到，Groupware 工作负载的平均探针响应时间在所有工作负载中是最高的。这就解释了为什么 Groupware 工作负载被认为是最繁重的工作负载。通过比较系统 7000 和系统 704 的结果来评估 Groupware 工作负载的探针结果，这样做非常有意义。当用户数量在 325 左右（比如，介于 300 和 350 之间）或以下时，系统 704 拥有最佳的系统性能。这使我们可以得出一个结论：除非用户数超过 325，否则系统 700 中的额外处理器和内存的开销将对性能产生影响。然而，即使存在这种影响，响应时间仍然是可接受的。这种性能行为并不会出现在任何其他工作负载或任何其他系统中。
值得注意的是，系统 704 出现了比较小的变化倾斜。这发生在（比方说）250 到 300 名用户之间，与之形成对比的是，在 300 到 350 名用户之间出现了非常陡的变化倾斜。在进行归纳总结或预测系统性能时，一定要考虑到这种类型的行为。这种类型的行为可以确保我们了解基准工作负载的上限和下限，并将预测的值限制在这些已知的范围之内。
在查看邮件、邮件和共享数据库工作负载的测试结果时，我们发现在不同的用户数数据点出现了一致的次秒级探针响应范围。这表明出现了一个较低的变化率。这些工作负载还表明，即使用户数达到最大值，系统在最终用户响应时间方面并不会感到吃力。
对探针响应进行分析可以很好地在不同工作负载之间建立合理的关系，并且有利于理解各种类型用户的执行情况。Server.Planner 的内部决策制定逻辑遵循这一前提。因此，您应当在进行评估和比较时使用探针响应时间，而不是 Notesmark (TPM) 率。
在第四个评估场景中，我们分析了不同工作负载下的磁盘 I/O。我们使用 Windows NT Perfmon 实用工具执行测试。我们分析了逻辑磁盘目标、平均磁盘队列长度以及磁盘时间百分比。平均磁盘队列长度由 NT 的 PerfMon Utility 定义：“Avg. Disk Queue Length 是指在取样间隔期间，针对所选磁盘排队的读、写请求的平均数量”。Percent Disk Time 同样由 NT 的 PerfMon Utility 定义：“Disk Time 指所选磁盘用于响应读、写请求的时间的百分比”。
您可以在相关文章 “磁盘 I/O 测试结果” 中查看本次测试的结果。
根据图表显示的信息和其他测试数据，我们可以观察到以下信息：
- 信息在每个工作负载中都保持高度一致，即使每个图表中的 Y 轴都不相同。
- 由于没有达到比较危险的磁盘 I/O 队列级别（大于 2），因此这个配置 不属于 I/O 密集型，这意味着服务器和磁盘 I/O 系统能够处理队列中的数据量。不幸的是，没有针对早期的工作负载收集这一指标以进行分析。它只存在于系统 7000。
我们将查看的第五个指标是不同工作负载下的每秒内存分页。我们使用 Windows NT Perfmon 实用工具执行测试。我们使用内存对象 Pages per Second Counter 来衡量性能。我们还通过找出与分页争用内存的应用程序和进程的数量来确定每秒内存分页。页面文件的大小受到总体可用内存量以及应用程序和进程所需内存量的制约。NT 的 PerfMon Utility 将每秒内存分页指标定义为：“每秒内存分页是指，为了解析对页面的内存引用（这些页面在引用时不在内存中）而从磁盘读取或写入磁盘的页面的数量”。它是每秒页面输入和每秒页面输出的总和。这个数字包括了系统缓存为访问应用程序文件数据而发生的页面通信量。该值还包括往返于非缓存、映射后的内存文件的页面。如果您比较关心巨大的内存压力（即系统失效）和由此产生的大量内存分页，那么需要将每秒内存分页作为一个主要的观察指标。
您可以在相关文章 “每秒内存分页测试结果” 中查看本次测试的结果。
在本文的开始部分，我们计划深入评估 4 种指标。我们选择了这个指标以及后面即将介绍的指标，来展示我们收集并分析的具体信息的示例，这些例子非常有启发性。这些指标在评估中并不具备最高的优先级，但是在研究服务器性能时应当加以考虑。
要获得令人满意的性能，一条基本原则就是每秒内存分页不应超过 15 到 20 个。图表显示，对于邮件密集型工作负载（邮件和共享数据库），每秒内存分页已经违背了这条基本原则。然而，如果查看探针响应时间和处理器使用量，（本文没有包含有关邮件和共享数据库工作负载的这些信息）可以看到这些系统都处于可接受的范围内。我们在评估邮件工作负载时观察到类似的结果。
本次测试清楚地表明，如果仅关注某个方面的测试结果，那么无法清晰地说明系统的整体性能。在查看每秒内存分页时，还需要了解可用内存量以及内存是否随时间增加或减少。在本例中，由于内存量并没有减少，Domino 服务器很可能执行了大量磁盘 I/O。对此问题进行深入分析后，我们发现这属于数据密集型行为，由于数据不在缓存内，因此造成较高的内存分页率。
在最后一个评估场景中，我们将查看每种工作负载下的 Notesmark。Notesmark 指 Domino 服务器执行的事务的数量。
您可以通过相关文章 “Notesmark 测试结果” 查看本次测试的结果。
注意，在查看 Notesmark 值时所有 Domino 服务器事务都不是相等的。因此，您不应该 跨多个工作负载比较平均 Notesmark 结果。对于这些测试，有趣的是事务率在不同工作负载之间都高度一致。这意味着相同的服务器执行结果是一致的。每种配置在各自的负载级别执行相同的工作量。Domino 服务器本身并没有制造瓶颈。对于所有工作负载、所有系统配置以及所有用户范围，都会出现这种行为。
注意，在下图中，当处理器使用量随着不断增长的用户负载增长时，它将影响响应时间。响应时间是 Server.Planner 探针响应时间。
图 1. 处理器利用率/响应时间
上图表明，对于系统 7000，结合了处理器使用量评估和探针响应时间评估。
在查看所有机器配置、性能和已用容量时，我们发现，为机器提供额外的可用资源（特别是内存）可以带来额外的益处。我们已经可以更加专业地分析处理器使用量和内存使用量，现在我们更多地关注磁盘 I/O 使用量（性能和配置）。我们还发现，在给出通用的方法来分析平台特定统计数据、Domino 统计数据以及 NotesBench 和 Server.Planner 指标时，我们能够更好地理解不同工作负载之间的资源需求的相同和差异之处，以及不同负载下相关的系统性能和容量需求。
测试结果使我们可以得出更具体的结论。我们希望了解系统 7000 在具有比其他系统更充足的内存和处理器资源时产生的性能影响。我们希望理解这种影响。这与我们的观察一致：“负载均衡” 的系统包含更多（但更慢）的处理器，但是结合了更大的二级缓存（系统 7000 对 384MB 内存使用 1MB 缓存）。额外的 CPU、二级缓存量和内存，在特定用户负载下可提供更好的容量和响应时间。
我们还查看了服务器执行 Notesmarks（Domino 服务器事务）的速率。我们发现，随着用户数量的增长，每种配置在各自的负载级别下在服务器事务方面执行相同的工作量。这清楚地表明，在特定工作负载下，可以比较 Notesmarks 来确保每名用户执行了相同数量的工作。当我们观察到每名用户每分钟的平均事务量 TPM 降低，我们就知道我们已经超出了特定配置的实际用户负载范围（一般来讲，此时的响应时间将发生巨大的变化）。
此外，测试结果还表明，我们需要确定每个工作负载的上限，这样才能提出处理上限阈值的对策。可供选择的方法包括解决瓶颈（并采取纠正措施）、为生产环境定义有效的操作特征，以及继续测试其他工作负载以进一步找出是否还有需要解决的问题。即使不同的工作负载具有不同的执行配置，分析这些内容可以帮助您判断出最佳性能平台（本文没有涉及这种分析）。您还可以了解到系统配置中的变动如何影响最终用户的响应时间。
通过这些基准测试统计数据，您可以理解特定工作负载下的优势和权衡。例如，在比较包含一个 CPU 和 384MB 到 512 MB 内存的配置和包含 2 个 CPU 和 1380MB 内存的配置时，通过观察下面的数据，您就可以理解 CPU 使用量方面的改进：
- Groupware 工作负载：20%
- 邮件工作负载：15% 到 20%
- 共享邮件和数据库工作负载：15% 到 30%
- 数据库工作负载：0% 到 10%
从这些测试中我们了解到，针对通用系统配置和应用程序制定的标准性能指导原则并不适合更加健壮的应用程序，比如 Domino。这一点在每秒内存分页指标方面表现得尤为突出。每秒内存分页的行业标准指导原则为 15 到 20 这一范围。在达到了这一范围后，必须进一步深入挖掘，分析其他指标以确定是否存在问题。例如，每秒内存分页值可能只是一个警告。每秒内存分页评估显示，与邮件相关的工作负载的每秒内存分页值要高于该指标的平均值。这是因为系统在完成任务的过程中执行了大量或少量的写操作。通过查看处理器使用量和探针（最终用户）响应时间，可以确定没有出现性能问题。在查看某个生产邮件服务器的性能特征时，一定要注意这一点。
您可以使用多种方法解释测试中的数据。例如，当我们查看 CPU 使用量随用户数增长的变化率时，我们发现当用户数达到 200 时，将 CPU 使用量平均到每用户的值为 .025，这一值在用户数为 500 时为 .05。当我们将用户数从 200 增加到 500 时，容量需求增加了 50%。您可以对任何其他数据点和图表应用这类分析和计算。
本文中的测试表明，您不能仅根据有限的测试来判断 Domino 的性能。您需要查看涵盖了不同工作负载、不同用户数和系统配置的所有测试场景。然后，您还需要使用不同的方法分析和解释测试数据。通过遵循这种方法，或者要求您的供应商这样做，在完成本文提供的示例后，您将能从整体上把握 Domino 的性能。
内容
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。