> But I must say that I believe that no-one has ever used OpenSSL > with 10'000 concurrent SSL objects.
Umm, what?! We've last tested to almost 16,384. Our first test to 10,000 was many years ago, on servers with Pentium processors and 128MB of RAM. We've tested on operating systems from Windows NT server to Linux. This is one of the required tests before we certify any platform for use with our software. We've been offering web server and chat server software rated for 10,000 concurrent secure connections (using OpenSSL) since the year 2000. > So I'm not going to take the chance > that there will be any performance degradation. > I'd rather have the GUARANTEE that there is no lock > contention AT ALL. This makes no sense. Suppose you do everything you do but compile OpenSSL normally, with locks. If there is any lock contention, you might hypothetically get some performance degradation. If you compile OpenSSL without locks, and you encounter a situation that would normally cause lock contention, you *blow* *up*. So how does converting contention from a performance loss to a disaster help? Removing lock *CONTENTION* is not the same thing as removing locks. In any event, what you are doing makes no sense for at least one more reason. When I explained that locks without contention were darned near free, you seemed surprised. This means you never measured the cost of these locks. But then when I explained that this assumption was likely an example of premature optimization, you agreed with me. What you are doing is a painful and complex optimization with several significant risks if it's not done correctly. Since you have no demonstrated need for this optimization, why are you doing it? Assuming this is a real-world application rather than a theoretical exercise, it makes no sense. I think you are making two fundamental mistakes. First, you are assuming the cost of lock contention is high without any evidence. Second, you are confusing the cost of an uncontended lock with the cost of contention. Try it the way everyone else is doing it first. They may know something. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
