Domino Http 活动线程数的推荐设置.doc

Domino Http 活动线程数的推荐设置环境:(产品,平台,机型,软件版本,等)产品: Lotus Domino版本：8.0, 7.0, 6.5, 6.0问题描述:Lotus Domino server的Http 活动线程数最大推荐值是多少？这个设置位于服务器文档-Internet 协议-HTTP-活动的线程数解答:考虑到内存的限制和线程切换所需的开销，建议对于单处理器的服务器，此值不要设置超过64；对于多处理器的服务器，此值不要设置超过80。如果超过了建议的设置值，很可能会降低服务器性能，甚至导致宕机。即使对于某些操作系统，比如i5/OS (iSeries)，可以设置较高的活动线程值（可达到512），分配较多的活动线程也不意味着一定会有更好的性能。Domino 6 及以后的版本已经允许更少的线程执行更多的工作。所以，超过80个活动线程会由于线程的切换反而对性能产生负面影响。因此，上面给出的活动线程数已经是最大的建议设定值。您需要决定的是具体设定为什么值会最适合您的生产环境。这里建议您从默认的40个线程数开始，逐渐地增长，可以一次增长10个线程数，来决定设置为何值时可将性能调整为最优。对于Domino6、7、8 服务器来说，您可以通过定时输入“show stat”命令来收集统计信息，以调整HTTP的线程数：Domino.Threads.Active.Peak (R5 及以上版本) 当执行特定的NSF请求时，并发的HTTP线程峰值HTTP.CurrentConnections (Domino 6及以上版本) 当前HTTP服务器的连接数，不论是何种请求类型HTTP.PeakConnections (Domino 6.0.5/6.5.4及以上版本) 从HTTP服务器启动开始的连接峰值，不论是何种请求类型这三个统计值可以看出服务器的负载情况，但是不能说明一定要增加HTTP工作的线程数才能具有好的性能。在决定是否增加HTTP工作的线程数之前，您需要关注的是如何提高服务器的处理能力，而不是一味关注服务器的负载。举例来说，在Threads.Active.Peak 统计值是75时设置80个活动线程，这种情况不意味着就会比40个活动线程，峰值40性能更好。当然，这取决于请求的类型，以及运行于Domino服务器上的应用。说到服务器的处理能力，您可以通过处理单个请求所花费的时间来判断，也就是以下这两个统计信息相除的结果：HTTP.Worker.Total.RequestsProcessed (Domino 6.5.4 及以上版本) HTTP工作线程所处理的请求总数HTTP.Worker.Total.TotalRequestTime (Domino 6.5.4 及以上版本) - HTTP工作线程所处理的请求所花费的总时间用TotalRequestTime 除以 RequestsProcessed， 就会得到服务器处理能力的统计数值。另外，完成一个请求所需的时间也可以被记录，只是这种方法需要用户做一些额外的操作，如定制脚本，或手工地把这些数据分析出来。为更好地设置活动线程数，建议您在观察服务器处理能力的同时，也同样观察服务器在处理一些简单请求所花费的平均时间，比如OPTIONS * 或 GET /test.html（这里，test.html可以是一个简单的html页面或是其他小资源）。如果这些简单请求的响应时间已经达到了不能接受的范围，那么您可以考虑增加HTTP工作线程数。然后继续观察服务器处理情况以及简单请求的响应时间，以检测是否提高了服务器的性能。另外，您还可以通过压力测试来模拟对于您的应用预期的负载量，同样运用上边提到的建议值以及统计数据。一些测试数据记录在developerWorks的相关文档中，您可以通过这篇文章最后列出连接访问这些文档。注意：Domino.Threads.Active.Peak 只记录了并发的NSF请求数， 非NSF请求不包括在内。因此，如要收集同时包括NSF以及非NSF的信息，您可以定期输出show stat http ，并观察HTTP.Worker.TotalRequestsProcessed 和 HTTP.Worker.Total.TotalRequestTime 这两个统计值。 对于更多的关于HTTP线程数的讨论，请参考developerWorks: Lotus Web site中的这篇文章：Optimizing server performance: HTTP Threads settings/developerworks/lotus/library/ls-HTTP_Threads_settings/So, youve got your Domino server all set up to work the Web, but want to make sure that you get the most out of the system? You may not realize that you can adjust the number of HTTP threads running on your server, and improve both the servers response time and resource utilization.In this article, well take an in-depth look at a performance analysis of Domino Web server resource utilization on Windows NT. The test shows the impact of changing the HTTP threads setting on server performance. Well start by defining what HTTP threads are, then describe the test methodology and test data, and finally summarize what the results mean to you. This can help you decide how you want to set up your environment in the future.For background information on how we conduct performance analyses here at Lotus/Iris, or an introduction to the tools we use, see Optimizing server performance: Port encryption & Buffer Pool settings. To read more recommendations for improving server performance, see the Top 10 ways you can improve server performance.What are HTTP threads?HTTP threads are threads of execution for handling incoming HTTP requests. To specify the number of threads that you want active on your Domino server, use the Number of active threads field in the HTTP section of the Server document in the Public Address Book. The default setting is 40. When the HTTP server task initializes on the Domino server, the defined threads are created and occupy approximately 20-40Kb of memory each. These threads are fixed in number until you change the value in the Server document, and then restart the HTTP task.Our expectation for this performance analysis of a Domino server functioning as an HTTP-based messaging server was that the HTTP active threads setting should be equal to the number of Web users on a particular Domino server. For example, if you are anticipating 200 Web users to use a Domino server, you might assume that you should set the HTTP active threads to 200. However, as you will see from our test results, this is not the case.To run the test scenarios, we set up one client that could simulate Web browser users running the new NotesBench WebMail workload with the following configuration: CPUs: One Pentium II processor Memory: 256MB RAM OS: Windows NT 4.0 Workstation Notes: Release 5 (based on Beta 1) NotesBench WebMail workload (available with Release 5 of NotesBench)We set up a Domino server with the following configuration: CPUs: Two Intel Pentium II/300MHz with 512K Level 2 Cache Memory: 512MB RAM Single SCSI controller Three hardware arrays created across six disk drives Hard Drives: -Logical C: One RAID0 7200rpm drive for OS-Logical D: One RAID0 7200rpm drive for page file and Domino executables-Logical F: One RAID5 7200rpm with four drives for user mail files, logs, and mail.box (total 36GB storage for data directory) OS: Windows NT Server 4.0, Service Pack 3 Domino: Release 4.62 for Windows NTIn particular, we wanted to test the relative impact (the number of users, the response time, and the resource utilization) when varying the following HTTP threads settings: 10, 25, 50, 100, and 200. We applied each setting to a NotesBench WebMail multirun test with 25, 50, 100, and 200 users. This test scenario compared average user response times, probe response time, system CPU utilization, memory used, and disk utilization at various loads. We ran each test for approximately 60 minutes in a steady state, with a ramp-up period of 5 minutes.The workload we used for all the tests is the new NotesBench WebMail workload, which will be available when R5 ships. This workload enables each simulated user to access their respective mail file, built using the R4.6 Mail - Combined template (mailc46.ntf), via the HTTP protocol. Each user iteratively executes a 15-minute script that consists of: 1. Preparing and sending a 10K message to three recipients dynamically selected from the servers directory every 15 minutes. 2. Reading the Inbox and the first five Inbox documents, and deleting the first message.All messages are sent to and received by other simulated WebMail users on the same Domino server. In addition, the WebMail workload requires the following NOTES.INI settings on the client: ThreadStagger = 5 (seconds) NormalMessageSize=10000 NumMessageRecipients=3The ThreadStagger setting specifies when each user logon begins, so in this case, each user logon begins at five seconds apart. This setting helps the server ramp up smoothly, without having connection timeouts during the ramp-up phase. The NormalMessageSize and NumMessageRecipients settings specify the size of the message (10K) and the number of recipients (three) that are used in the 15-minute WebMail script.To see the results of these tests, see the sidebar HTTP Threads Settings Test Results. For our conclusions, see the following section, What did we find out?Back to topWhat did we find out?Our basic discovery was that more HTTP threads is NOT necessarily better. In fact, as indicated by the data and graphs, there is a degradation in performance and an increase in memory consumption, if there are more HTTP threads defined than are needed. Therefore, you should only define the minimum number of HTTP threads necessary for your servers load.The best way to determine the optimal HTTP threads setting for a given user load is to first run with the HTTP threads setting approximately equal to the user load. Then, at the server console, check the peak number of HTTP threads used by typing the following:show statistic domino.threads.active.peakSince this value indicates the maximum number of HTTP threads in use, it is much more appropriate to use this value for the HTTP threads setting in the Server document.If youve just installed a Domino server and you have a general idea of how many Web mail users it will be supporting, then a good starting value for the number of HTTP threads setting is 10% of the number of Web users. For example, if you anticipate 200 Web mail users, a suitable init