[Info-vax] New OpenSSL update from HP

[David Froble]

Stephen Hoffman wrote:
> On 2015-06-14 22:43:29 +0000, Jan-Erik Soderholm said:
> 
>> One of the reasons CSWS performes less good on VMS is becuse of the 
>> high use of forked subprocesses. *That* is inefficient on VMS.

Well, the way I understand FORK, anything on VMS outside of threads is 
going to perhaps have more overhead.  If the worker process has to 
duplicate anything the web server already has, that's a bit more work.

However, if you pre-allocate say 25 or 50 processes, (which I would not 
do), then all you have is a queue of available processes to maintain, 
and process to process communication.  If pressed, I could get damn fast 
with the communications.  Though just mailboxes would be adequate in my 
opinion.

But think about it.  You claim WASD is faster.  It has the same issues. 
  So, it isn't the common issues.  There has got to be other stuff in 
Apache that makes it a dog.  Woof!

> There is a pool of worker processes yes, but that'll exist in any web 
> server configuration short of running it all in one process with threading.

Or, creating the sub-process or detached process as needed ....

Ok, I've never written a web server, yet.  If I was to do so, I'd 
seriously look at detached processes rather than sub-processes.  Why? 
Because once you assign the worker process a task, perhaps you'd want it 
to complete, regardless of whatever the web server does.

> Yes, process creation was glacial in years past and best avoided,

Perhaps on an 11/780 ....

> but 
> the servers have also gotten much faster.

If anyone doesn't buy this, perhaps I'll write a small program to create 
a number of processes and see the timing.  Maybe.  I hate work ....

>  While CPU is still a factor 
> for some cases, there can be other issues beyond the process creation.  
> There's that OpenVMS network I/O tends to be slower than Unix in various 
> tests, that the file I/O also tends to be slower in various tests, that 
> the interprocess communications have been slow, etc.  There are many 
> potential contributing factors to slowness in any complex design.

But, he's claiming that WASD is faster.  On the same HW.  So no, it's 
not what you list.

> It may well be the process creation for the worker processes is the 
> limiting factor, but I'd want to see some data before drilling in on 
> that...

I truly doubt it.

My opinion, it's the bloated protocols in use.  SOAP.  XML.  Stuff like 
that.

> Another factor here is whether the users will accept the new user 
> interface and the new environment, or if you end up maintaining multiple 
> different environments for any of various reasons.  I'm more than 
> willing to change UIs, but I'd rather get a net benefit out of that 
> effort on engineering and on the end-users, and would also obviously 
> prefer to avoid maintaining two or more parallel environments.
> 
>> Now, I do not think than SSL has much of that.
> 
> Beyond my own activities, I've encountered no process creations in any 
> of my uses of SSL.  There may well be some (somewhere), but it's not 
> something I've encountered.  (It'd be feasible to grep the source code 
> for fork or system calls, but then I don't have a copy of OpenSSL handy.)
> 
>> A Specification for what? SSL/TSL? This page has a lot of RFC references:
>> https://en.wikipedia.org/wiki/Transport_Layer_Security
>>
>> The latest TLS 1.2: https://tools.ietf.org/html/rfc5246
> 
> That's just one part, of course.  RFC 6176, too.  There are other RFCs 
> involved.   SSL is a negotiation framework, with the key exchange, with 
> the various ciphers, certificate processing and validation, random 
> number generation — there are more than a few folks that will state that 
> cryptographic random number generation is untenable in user space, but I 
> digress — and the associated negotiation mechanisms.  There are a number 
> of RFCs just for the TLS host name validation, too; per one report, that 
> list includes 2459, 2595, 2818, 2830, 3207, 3490, 3546, 3920, 4513, 
> 4642, 4954, 5425, 5539, 5922, 5953, and 6125.  (This is part of why I'm 
> skeptical around VSI rolling their own crypto at least initially — sure, 
> it's possible, but it's no small investment.)
> 
> 

I've got to wonder.  Is there any real use for so many different ciphers 
and such?  I'll admit that I know nothing of SSL.  Or is it all the 
backward compatibility?