Tuesday January 10, 2006

Sun T2000 vs Dell 6850 Revisited

• When we installed Solaris on the Dell system, we chose to use Nevada build 28 (which is available through Solaris Express) rather than Solaris 10. The primary reason for this was that we wanted to use ZFS to provide RAID capabilities for the internal disks. For the Windows testing, an on-board Adaptec hardware RAID controller was used for this, but when we installed Solaris 10 on this system we saw the individual disks rather than the hardware RAID. As this was a borrowed system and time to investigate this issue was limited, we chose the software RAID approach using ZFS. Other testing has not shown a significant performance difference for Directory Server between Solaris 10 and Nevada builds, and disk I/O was kept to a minimum with caching during these authentication performance tests so the underlying storage is largely irrelevant.
  
  
• These tests were run with the SLAMD 1.8.2 LDAP Weighted AuthRate job, using an 80/20 weighting (80% of the authentications were targeted at a subset of 20% of the users, and the remaining 20% of the authentications targeted the remaining 80% of the users). This is the same workload used in the graphical demo. This was run as an optimizing job in order to find the best performance with each configuration, and the numbers reported here were taken from a re-run of the best iteration from the optimizing job.
  
  
• Each authentication consisted of an anonymous search to find a user account based on a login ID, followed by a bind as that user to verify the password. In the graphical demo that we provided, searches to find the user account were performed as the root DN rather than anonymously in order to provide better performance by avoiding access control evaluation. This does not impact the fairness of the comparison in either case, since all servers involved in the comparisons were subject to the same workload.
  
  
• For each of these tests, client load was generated using four V60x systems, each of which had two 2.8 GHz Xeon processors, running Solaris 10. In the graphical demo, we used a single V20z as the client for each system. In both cases, we were able to ensure that the client was not a performance bottleneck for the testing.
  
  
• In the graphical demo, the entries loaded into each Directory Server instance were created using the example.template file provided with the MakeLDIF LDIF generator (which comes in the tools/MakeLDIF directory in the SLAMD server installation). Entries for the formal test were also generated using MakeLDIF, but with a different template that uses slightly larger entries and includes additional attributes and objectclasses that would normally be found in the user's entry in a Messaging Server installation.
  
  
• The Directory Server instances in the graphical demo were each configured with access logging disabled for a slight performance increase, and also to avoid disk write operations because both systems were using internal storage during that demo. In the formal performance tests, access logging was enabled and written to RAID-based storage. Due to caching, no disk reads were required in any of the tests.
  
  
• On the T2000 system, the 64-bit version of the Directory Server was used. On the Dell system, both the Solaris and Windows testing made use of the 32-bit version, since no 64-bit version is currently available for x64 systems. On Windows, this 32-bit means that the Directory Server was only able to directly access a maximum of 2GB of memory; on Solaris, the maximum was 4GB of memory. These constraints were sufficient for fully-caching the data for the tests with 250,000 users, but were not sufficient for the larger data sets. On Windows, we were unable to achieve acceptable results for larger data sets because of the caching constraints. On Solaris, the filesystem cache was used to help avoid disk reads when testing with the larger data sets.