Sanford, >I also understand that you were not speaking from experience.
I assume that you are speaking of experience regarding your product. My experience with relational, enterprise level database systems is quite extensive and well beyond simple integration with Imail. I have to admit; your numbers look very good on the surface, but they don�t accurately consider the implications of a registry system on a live box. To accurately test this, your test application would need to spawn multiple threads for simultaneous access to the registry and database on a live box with processor and memory utilized by other Imail services at the same time. Extensive seeks on a large binary tree can be quite processor intensive and undeniably impact any other process waiting access to the same processor pool. The simple seek comparison does not take into account the performance impact on the other services running on the same box or the impact that those services have on the seek times. Neither issue exists on an SQL server on a separate box. The registry is essentially a binary tree that the os memory-maps as needed. The memory location is a pointer to the file on the disk and the memory-mapped functions will only pull into memory what is needed. The implication here is that since the registry is a hierarchical tree, each element prior to the element being retrieved will be pulled into memory. So for every [n] user/process registry action you have [n] copies of the registry being loaded from the disk and being processed in memory. Once changes are made to the memory-mapped file, a flush has to take place before those changes are saved. That flush must also occur per each updateable user/process action taking place. This action not only occurs per Imail action, but per any registry accessing process action. The total size of the registry effect each and EVERY process that must also access the same registry. This is quite more overhead than simply being processor bound. The performance and scalability of this overhead is completely size dependant and on top of that, occurring on the mail server itself. The size of the registry is also not completely modifiable. Entries removed from the registry do not remove the space allocated by the registry. The �repacking�, if you will, can only be performed by 3rd party applications that are not a part of the os. Once space is allocated, it stays. So now the total size overhead is not only dependant on the total number of users you have, but on the total number of users you have EVER had. Considering that the registry is accessible and routinely modified by any installed application, the performance then becomes dependent on any and all other applications which access the registry. This secondary access leaves any stored data in the registry routinely available to corruption. Since any and all applications running on the server have access to the same �database� that your users are stored in, you are not only impacting performance, but also reliability and integrity. Since the registry is essentially one file, any corruption in your �database� and you lose not only your users, but also your os. I don�t disagree that the registry has its performance benefits. For 95% of Imail installations, it is the most sensible, best performing solution. It simply is not a good solution for those wishing to run high volume email servers. That is speaking from YEARS of experience running Imail using both the registry and SQL solutions. Chris ---------------------------------------------- Original Message From: "Sanford Whiteman"<[EMAIL PROTECTED]> Subject: Re[2]: [IMail Forum] Poll re: Interest in SQL/Registry hybrid solution Date: Tue, 19 Mar 2002 23:53:11 -0500 >Chris, > >First, let me thank you for your even-handed input. I appreciate the >time you took to write back and think through the possible trouble >spots for people using the suggested hybrid solution. I also >understand that you were not speaking from experience, but from a gut >feeling regarding the superiority of an enterprise SQL/RDBMS, so it's >not like I can call you on fabricating anything. :))) > >The problem is that you're wrong. The Registry lays waste to SQL at >any user level. My benchmarks from a few weeks ago were for only 1000 >cycles, it's true. I have updated them tonight to 100,000 cycles to >better reflect large Imail installations, and the results follow. > >As before, machines are two otherwise identical PII-400s, one Win2K >Pro workstation with 192 MB RAM and one WinNT Server/SQL Server 7 with >384 MB RAM. Intel Pro/100+ cards in each, with a 100Base-T full-duplex >connection. Both are fully patched with up-to-date drivers. > >For the Registry, I tested the time to read 100,000 REG_SZ password >values under 100,000 user keys (RegQueryValueEx for >HKLM_SOFTWARE\testbed\usernnnn\passwd). The test was run from the >workstation to its local Registry. > >For SQL, I tested the time to read 100,000 password fields from >100,000 user database rows (SELECT passwd FROM testbed WHERE username >= 'usernnnn') with a covered index on the username and passwd columns. >The test was run from the workstation to the server using DSN-ful >Named Pipes. > >The results over 5 tests, with the machines otherwise idle: > >Registry: avg. 374.6875 seconds > >SQL: avg. 23.8 seconds > >As Len said, it's actually a very good little ISAM! Remember that the >Registry is used for the NT SAM, which, despite its size limits, is a >*relatively* robust authentication/authorization directory managing a >lot more complex info than Imail in a true multi-user environment. > >Chris, as I said in an earlier message, I do believe that most Imail >admins don't do a DBA's job of optimizing SQL Server. In many cases, >they ignore indexing, for one thing (since it's not automatically done >by ODBCUSER.DLL, some think it might not help, I guess). Likewise, my >guess is that few try more costly technologies such as VIA. But the >Registry has a huge bang for the buck. > >Regards, > >Sandy > > >Please visit http://www.ipswitch.com/support/mailing-lists.html >to be removed from this list. > >An Archive of this list is available at: >http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > >Please visit the Knowledge Base for answers to frequently asked >questions: http://www.ipswitch.com/support/IMail/ > Please visit http://www.ipswitch.com/support/mailing-lists.html to be removed from this list. An Archive of this list is available at: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Please visit the Knowledge Base for answers to frequently asked questions: http://www.ipswitch.com/support/IMail/
