Chris, > I assume that you are speaking of experience regarding your product.
No, I was referring to your experience with stress-testing the Registry...this still seems to be none. > My experience with relational, enterprise level database systems is > quite extensive and well beyond simple integration with Imail. I really don't question that at all; that's why you have a grudge against the Registry. > 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. I don't think there's anything drastically wrong with my benchmark for showing the overall performance differences, but just to get closer to your specifications, I reran the benchmarks with different levels of concurrent load. First, I used a CPU stress tool to spin the CPU to approximately 25% before I ran the benchmarks: Registry: avg. 27.33594 seconds, 98% CPU SQL: avg. 482.0542 seconds, 85% CPU Then with approximately 50% utilization to start: Registry: avg. 46.56641 seconds, 100% CPU SQL: avg. 937.9063 seconds, 90% CPU Then I brought in some real load. I ran five concurrent threads of each, all fetching 100,000 random records: Registry: avg. 176.2305 seconds, 100% CPU, total 179.3086 seconds SQL: avg. 1465.547 seconds, 100% CPU, total 1469.227 seconds The only notable difference from my previous results is that ODBC is a bit more conservative with CPU. But so what? Neither the SQL nor the Registry threads were non-preemptible; basically, the Registry is smarter with CPU utilization as well! > 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. That would be great. Anytime you want to take the time to actually generate some metrics with this much methodological control, please do. I think I've done all that I should have to. > 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. As do ODBC and MDAC calls. You're failing to realize that ODBC is not a server-side mechanism. What matters is the toll placed on the client. > Neither issue exists on an SQL server on a separate box. That's right, the SQL Server box was perfectly comfortable with the load and its CPU utilization was quite low. But the Imail server is a CLIENT. And it clearly cannot handle the concurrent calls to the ODBC and MDAC layers with any sort of efficiency. > The registry is essentially a binary tree that the os memory-maps as > needed. No, it's not. It's memory-mapped at startup. > 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. See above. > 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. I'm sorry, but wishing won't change the way the Registry is architected. You don't know enough about its internals. > 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. This is flatly untrue. > 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. Wrong again. RegFlushKey() is actually a separate, optional Registry API call. Have you ever actually programmed the Registry? > 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. No, no, no, and no. > 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. This is mostly true, except for the "3rd party applications" part. Using an Emergency Recovery Disk will defragment the Registry. And think about SQL Server fragmentation, y'know, DBCC SHOW CONTIG? > 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. So...any shared access leads to corruption? Whoa, better rip out those MBX files that are opened SHARED READ WRITE. This sounds like the "the only way to be secure is to unplug your network/modem connection" kind of paranoia. > 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. So what you're saying is: the database is multiuser but not apparently client/server, thus it is unreliable. Well, then you've got bigger fish to fry than just Imail. > Since the registry is essentially one file, any corruption in your > �database� and you lose not only your users, but also your os. Only if you're talking about file system corruption, not internal index/data corruption. And if you have file system corruption to your SQL MDF/NDF files, you're not in much better shape--probably involves replacing hardware in both cases. > I don�t disagree that the registry has its performance benefits. For 95% > of Imail installations, it is the most sensible, best performing solution. I'll stick with 100%. > That is speaking from YEARS of experience running Imail using both > the registry and SQL solutions. Please pull out some of those old performance benchmarks or run some new ones before your next attack, okay? 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/
