Lotus Sametime 3.x for iseries. Performance and Scaling

Size: px

Start display at page:

Download "Lotus Sametime 3.x for iseries. Performance and Scaling"

Anastasia Clarke
5 years ago
Views:

1 Lotus Sametime 3.x for iseries Performance and Scaling

2 Contents Introduction... 1 Sametime Workloads... 2 Instant messaging and awareness.. 3 emeeting (Data only)... 4 emeeting (Data plus A/V)... 8 Sametime Attachment Conversion Services... Server Startup... Workload Estimator... Conclusion

3 Introduction This paper addresses a variety of topics related to Sametime 3.0 performance and scaling characteristics on an IBM eserver iseries system. The goals of this paper are to set general performance expectations, describe the critical workload components that limit scalability, and provide tips and techniques on how you can get the most out of your iseries system and the Sametime server, or servers. However, first you might ask why you should consider iseries as a platform for running Sametime, which is also supported on Windows NT, Windows 2000, and AIX. Because of its scaling capability, along with its easy-to-manage infrastructure and low total cost of ownership, iseries is the ideal platform for Sametime. It shields the typical business user from worries about technical issues. The uniquely integrated architecture of iseries delivers proven reliability, high availability and powerful single-footprint scalability to mid-market companies, so you can focus on your business rather than technology. Like Domino for iseries, Sametime provides the same reliability that you expect from your mission critical systems. A key differentiator is the iseries subsystem architecture which brings three benefits to you: 1. Since Sametime runs on top of a Domino server, you can quickly create additional Domino partitions (up to 99) dedicated solely to Sametime. If you are already using Domino, there is minimal training required to manage Sametime. 2. iseries isolates Sametime from other applications. If a problem occurs, the Sametime server is safely ended and quickly restarted without affecting other work on the server and with minimal downtime. Even more importantly, if a different application encounters a problem, it has no effect on the Sametime server. This allows you to safely run Sametime on the same iseries system as your other mission critical applications. 3. On a single iseries, you can create a community of Sametime servers, add a Sametime server to an existing Domino domain or add Sametime to an existing Domino server. No matter how you configure the server, Sametime runs in the same physical server footprint as your existing Domino server, simplifying server management, simplifying code update and fix management, and eliminating the need for additional hardware. Lotus Sametime 3.x for iseries: Performance and Scaling 1

4 Sametime Workloads Three workloads were developed to test Sametime performance and scaling, each intended to simulate a typical use of the product. These workloads were tested on various configurations of iseries systems to establish scaling limits and uncover performance bottlenecks. We then attempted to devise strategies to extend those limits, either by enhancing the Sametime product to more tightly integrate it with native iseries interfaces or by using some feature unique to iseries. The three workloads, described in more detail later, are: 1. Instant Messaging and Awareness 2. emeeting (Data only) 3. emeeting (Data plus Audio/Video) In each workload there are 2 primary measurements that dictate the iseries model required to support it. 1. Rate of user activations For the Instant Messaging and Awareness workload, this is the rate at which users log in to the Sametime server (i.e., logins per minute). For the other two workloads, this is the rate at which users join active meetings (i.e., joins per minute) 2. Number of concurrent active users For the Instant Messaging and Awareness workload, this is simply the total number chat users logged in to the Sametime server. For the other two workloads, this is the total number of users participating in active meetings. In all three workloads, scaling is limited mainly by the system CPU and/or internal software contention. Since we ran the tests on a dedicated 100Mbs ethernet and a server with 40 disk arms, we did not encounter problems with network traffic or disk utilization. The one exception was with the emeeting (Data plus A/V) workload where the network traffic was a potential problem. All of tests were run using the default configuration settings at both the system level and the application level. No special tuning was done to improve the performance. Unless otherwise stated, all of the results described here pertain to tests run on an iseries with 4 processors. To study the impact of multiple processors, we simply disabled a subset of the processors on that same system. 2 Lotus Sametime 3.x for iseries: Performance and Scaling

5 Instant messaging and awareness In this workload, each user performs the following activities over a period of 8 hours. Logs off and back on one time Maintains a buddy list which contains 50 users Changes status 5 times (e.g., active to inactive) Starts 10 chat sessions Sends 15 messages in each chat session (each message contains 80 characters) The chart below illustrates the utilization of system resources while running this workload in steady state with 60,000 users on a single Sametime server. You can see that even when supporting this large number of Sametime users, the resource utilization is low. CPU utilization has improved significantly from Sametime 2.5, where it was over 30%. 15 %Utilization 10 5 CPU Disk Ethernet Comm IOP 0 Time The user activation rate (logins per minute) is limited mainly by CPU processing in a single job, called STUSERS, which is responsible for generating security keys used in user authentication and data encryption. Our Sametime server was able to process about 1000 logins per minute. Since the STUSERS job is single threaded, this number does not increase as you add processors to the system, although it does vary with processor speed. If you expect that your login arrival rate will exceed this level, and your system has additional processors, consider configuring additional Sametime servers on the same system. This will improve the maximum login rate by spreading the workload across multiple servers. A good rule of thumb is to configure one additional Sametime server for every two additional processors. Our tests on a 4-way system verified that the login throughput rate nearly doubled, and the average login response time decreased after adding a second Sametime server. See Technote # for more information about setting up multiple Sametime servers on the same iseries system. Lotus Sametime 3.x for iseries: Performance and Scaling 3

6 The recommended maximum number of concurrent active users (logged in users) for a single Sametime server is 20,000. In our tests we were able to exceed 100,000 concurrent active users on a single Sametime server, but we experienced occasional stability problems. Also, if you have an extremely large number of users on a single server, your users will likely experience unacceptable login delays whenever you need to restart the server. Therefore, the recommended maximum is 20,000. This number is somewhat dependent on the average size of your users buddy lists. In our workload, each user has a buddy list with 50 entries. With smaller buddy lists, a single Sametime server can support more concurrent users. The maximum number of users is independent of the number of processors and the processor speeds. To support more than 20,000 users on a single iseries system, you can simply configure additional Sametime servers on the same system and spread the workload. So if you have a sufficiently low login arrival rate, you could configure multiple Sametime servers (even on a single processor model) and extend the 20,000 user limit. In the extreme case of a high-end 32-way system, you could theoretically configure hundreds of Sametime servers on a single iseries system. Since each Sametime server runs on a separate Domino server, Sametime is subject to the Domino limitation of 99 Domino servers per OS/400 instance. Once again, the unique iseries capabilities allow you to extend even beyond this. Using the LPAR (logical partitioning) feature you can configure multiple instances of OS/400, therefore allowing potentially hundreds of Sametime servers on the same iseries system. It also allows for running different versions of Sametime and/or OS/400 on the same system. More information on using LPAR can be found in the redbook Multiple Domino Versions Coexistence on iseries with LPAR and at the LPAR web site. emeeting (Data only) This workload follows a script that schedules a predetermined number of collaborative meetings to start in two stages - one hour apart. Each meeting that is started has 5 participants. One of the participants is the "lead" user, who changes the whiteboard presentation page every 60 seconds. The chart below illustrates the CPU, disk, and network utilizations through the various phases of the workload that consists of 180 meetings and 900 users. The first hump occurs when all 180 meetings are scheduled; the first trough is idle time while waiting for the meetings to become active. The second hump occurs when the first 90 meetings become active and 5 users join each meeting. During the second trough, the first 90 meetings are active and the presentation pages are changed every 60 seconds. The third hump occurs when the remaining 90 meetings and 450 users become active, while the first 90 meetings are still in progress. During the final, 4 Lotus Sametime 3.x for iseries: Performance and Scaling

7 third trough, all 180 meetings are active with a total of 900 users. 100 %Utilization CPU DISK ETHERNET 0 Time For simplicity we consider that user activation occurs when a user joins an active meeting. However, there are two other activities that are significant and should be accounted for, especially if the average number of users per meeting is small (less than 10). The first is the act of scheduling a meeting. This costs roughly the same as a user joining the meeting. The second activity is the background processing required to change a meeting state from scheduled to active. This requires roughly twice the CPU resources as a user joining a meeting. Once again, if you tend to have many meetings with a small number of participants, you should account for meeting scheduling and meeting activation when estimating your rate of user activations. During user activation, the HTTP job consumes the majority of the server CPU. This job is fully multithreaded so it doesn't suffer the same scaling limitations as the STUSERS job in the Instant Messaging and Awareness workload. However, there are internal Domino server contention points that result in diminishing returns for more than two processors. Our Sametime server was able to process about 25 user activations per minute when utilizing all 4 processors. When limited to 1 processor, the number was 8. When using 2 processors, the user activations per minute was 16. As you can see, the increase in throughput begins to taper off after 2 processors. Therefore, to achieve optimal user join throughput, you should configure one Sametime server for every two to three processors. The main limiting factor for the maximum number of concurrent users per Sametime server is internal software contention in the STT120MCU job. The level of contention is proportional to the rate of whiteboard attachment page changes. The maximum number of concurrent meeting participants that you should allow per server is about 500. Beyond this number, you will see an increase in system CPU utilization with little corresponding increase in throughput. Eventually, the rate at which participants see changed pages will slow to an unacceptable level. Lotus Sametime 3.x for iseries: Performance and Scaling 5

8 An important aspect of scalability is the effect of increased workload on observed response times. We collected data on 3 key primitive transactions during the user join portion of the workload. The chart below shows that the response time for the "ViewMeetings" transaction increases in a roughly linear fashion as the workload increases. This transaction occurs when the user views the list of active meetings in order to select one. We noted that the response time for the "OpenMeeting" and "Connect" transactions stayed relatively flat for up to 900 users. We also collected data for the "PageTurn" transaction for up to 750 users. This transaction reflects the average time it took to change the page in the whiteboard presentation. Response Time (seconds) Users ViewMtgs OpenMtg Connect PageTurn An analysis of the internal Domino contention that limits this workload's rate of user activations showed that a significant improvement should be realized once Sametime is supported on Domino 6. Tests run with early versions of this code validated the analysis. This is attributed to the overhaul of the Domino 6 formula (compute) engine which resulted in computation performance up to two times faster than previous Domino releases. This overhaul brings performance benefits in many areas that are heavily used in this workload, such as view refreshes, agents, and form rendering. The chart below illustrates the improvement in the CPU utilization in the HTTP job when running the emeeting (Data only) workload on Domino 6. As a result of the reduction in CPU utilization, user join throughput increased by about 35% when Domino 6 was used for this workload. iseries support for running on Domino 6 is available with Sametime 3.0a for iseries which can run on 6 Lotus Sametime 3.x for iseries: Performance and Scaling

9 Domino or later 6.0.x releases, in addition to Domino and later R5 releases %Utilization Sametime 3.0a on Domino Sametime 3.0a on Domino 6 0 Time When scheduling a meeting, there are 3 meeting types you can select from: 1. Collaborative 2. Moderated 3. Broadcast Collaborative meetings are typically smaller and more interactive than broadcast and moderated meetings. In each type of meeting, the presenter can transmit information using either application sharing or the whiteboard. The whiteboard is essentially static, where application sharing allows the presentation to be more dynamic. From a performance perspective, the user activation phases are similar, but the steady state meeting phases (i.e., presentation updates only) do have different performance characteristics. The chart below shows an example of the relative system resource costs. The meetings in the emeeting (Data only) workload fall into the "Collaborative/Whiteboard" category. These results are from a workload designed to highlight the differences by updating the presentations very rapidly. We did not measure moderated meetings with this workload, but you can assume that the performance characteristics for moderated meetings are roughly equivalent to broadcast meetings. Utilization CPU Ethernet Comm IOP Collaborative / Whiteboard Collaborative / App Share Broadcast / Whiteboard Broadcast / App Share Lotus Sametime 3.x for iseries: Performance and Scaling 7

10 emeeting (Data plus A/V) This workload is the same as the emeeting (Data only) workload, but with Audio/Video active. This workload has similar characteristics for the user activation rate, but the maximum number of concurrent active users decreases dramatically. With A/V active, the workload is much more CPU intensive throughout the entire meeting. Our Sametime server was able to handle approximately 100 concurrent users in A/V meetings. Keep in mind that this includes only the portion of the workload where the meetings are in progress and in a steady state. It does not include the meeting scheduling, starting, or the user joins. To extend this limit you should consider multiple processors and additional Sametime servers. Another concern that appears with this workload is the network utilization and the load on the iseries I/O Processors (IOPs). Managing the network utilization is outside the scope of this paper, but there is a technique unique to iseries, called Virtual IP, that you can use to manage IOP and network adapter over-utilization. Basically it entails spreading the outbound data from the iseries server over multiple IOPs and network adapters. This is a perfect match for applications that generate large amounts of outbound network traffic such as Sametime A/V. More details can be found in Technote # Sametime Attachment Conversion Services Sametime for iseries 3.0 includes an enhancement to support attachment conversion services for emeetings. This is a much anticipated ease-of-use and productivity improvement for users who set up meetings. In Sametime 2.5 for iseries, all whiteboard attachments had to be manually converted to.fst files using the Sametime Print Capture Utility before scheduling a meeting. With Sametime 3.0, customers have an alternative which provides automatic conversion of whiteboard attachments at the time the meeting becomes active. The customer can install and configure Sametime Attachment Conversion Services on a system running Windows 2000 (Professional or Server) or Windows XP (Professional). When a meeting becomes active, the Sametime server on iseries uses TCP/IP to send the attachment to the Windows system where the actual conversion takes place and the converted document is sent back to the server. The addition of this automated conversion step does not significantly impact the iseries CPU requirements. However, you should be aware of the additional network traffic generated by the one-time movement of the whiteboard attachments to the Windows system and back to the iseries system. Sametime 3.0a for iseries provides bitmap compression support to reduce the network traffic associated with document conversion. Our tests showed that the additional network traffic decreased by about 50% when running with compression enabled, plus there was a slight improvement in the conversion server throughput. 8 Lotus Sametime 3.x for iseries: Performance and Scaling

11 The chart below illustrates the increase in network traffic when using Attachment Conversion Services to automatically convert whiteboard attachments as opposed to using the Sametime Print Capture Utility to manually convert whiteboard attachments before the meeting is scheduled. This chart represents the results of the emeeting (Data only) workload with 180 meetings and 900 users, and it has the same profile as we have seen in previous charts. 100MBps Ethernet Utilization Time Conversion Services (uncompressed) Sametime Print Capture Utility Conversion Services (compressed) Assuming a sufficient network capacity, this feature is well worth implementing on your Sametime server. More details about Sametime Attachment Conversion Services are available in Technote # Server Startup Starting the Sametime server can stress your system if it has limited memory or a small number of disk drives (even if you have plenty of disk space). The paging rate increases dramatically during this period, which can temporarily impact other applications running in the same memory pool. In extreme cases the Sametime server may fail to start due to internal timeouts. If this happens, you can extend the internal wait times by increasing the following values in the meetingserver.ini file, located in the Sametime server data directory. [SOFTWARE\Lotus\Sametime\MeetingServer] ConfigWaitTime=60000 [SOFTWARE\Lotus\Sametime\MeetingServer\Services] StartWaitTime= The "ConfigWaitTime" setting is available only in Sametime 3.0a for iseries and later releases. The values for both settings are in milliseconds. Lotus Sametime 3.x for iseries: Performance and Scaling 9

12 Another option which will improve server startup performance is to increase the number of disk drives or the amount of available memory. At a minimum your system should have 4 disk drives and 512 megabytes of memory. Workload Estimator This document can provide guidelines that will help you understand limits to scalability and potential techniques for increasing those limits. When you are ready to determine which iseries model is best suited to run your specific workload you should consult the IBM eserver Workload Estimator (WLE). It is a web-based tool that provides sizing recommendations for an iseries running one or more workloads associated with e-business and/or collaboration, such as Domino, Java(tm), or WebSphere. You can use WLE to size a brand new iseries with all new workloads, or to size the upgrade of an existing system (with the original workload set or any additions) to a new system. WLE recommends the model, processor, interactive feature, memory, and DASD necessary for a mixed set of workloads. To use WLE, you select one or more workloads and answer a few questions about each workload. Based on your answers, WLE generates a recommendation and shows the predicted CPU utilization of the recommended system in graphical format. It is important to keep in mind that the WLE recommendations are based on steady-state workloads. As we have seen with the three Sametime workloads described here, there are significant CPU spikes during the user activation phases, which are not accounted for in the WLE recommendations. Hopefully the guidelines in this paper will assist you in quantifying the additional system resources required to handle the user activations. Conclusion The iseries is an excellent Sametime server that is very reliable and scalable. By implementing the tips offered in this article you can ensure that you are getting the most out of your Sametime for iseries server. This article has focussed specifically on the performance and scaling of Sametime 3.0 on the iseries system. Additional information on general Sametime tuning, including network planning considerations, is available at the Lotus Developer Domain web site. The table below summarizes some of the "rules of thumb" described in this paper and the techniques you can consider to go beyond those limitations with your iseries system. 10 Lotus Sametime 3.x for iseries: Performance and Scaling

13 Workload Instant Messaging and Awareness emeeting (Data only) emeeting (Data plus A/V) Maximum Maximum user concurrent activations users per per minute per Sametime Sametime server server 1 1,000 20, , Techniques to increase maximum LPAR Domino 6 Additional Sametime Servers Virtual IP The recommendations provided in this paper are a result of running a specific set of workloads on a small number of different models of the iseries system. Keep in mind that there are many variables that may affect how Sametime performs on your system, such as: iseries processor speed Utilization of key iseries resources (CPU, IOP, memory, disk) Object contention (e.g. mutex waits, lock waits) Speed of the communications links Congestion of network resources Processing speed of the client system Always validate these recommendations with the IBM Workload Estimator. Also, in many situations you will find that the primary performance limitation is the network capacity, which is not addressed in this paper because it is platform independent. 1 This assumes an iseries with 4 processors. To determine limits for specific models, please consult the workload estimator. Lotus Sametime 3.x for iseries: Performance and Scaling 11

IBM iseries Domino Solution Sales v5r3. Download Full Version :

IBM iseries Domino Solution Sales v5r3. Download Full Version : IBM 000-850 iseries Domino Solution Sales v5r3 Download Full Version : http://killexams.com/pass4sure/exam-detail/000-850 Which of the following is a key benefit of using the IBM Lotus Domino for iseries