[Info-vax] New OpenSSL update from HP

[David Froble]

Jan-Erik Soderholm wrote:
> David Froble skrev den 2015-06-15 05:25:
>> 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.
> 
> Apache does concurency through multiple processes, one per request.
> Note, even for very simple GET's of static HTML files/pages.
> 
> WASD does concurency of these requests within a single process.
> See p.36 here: http://wasd.vsm.com.au/other/decus_bs-v10-u.pdf
> 
> 
>>
>> My opinion, it's the bloated protocols in use.  SOAP.  XML.  Stuff 
>> like that.
> 
> Are you realy saying that the runs done with Apache and WASD used
> highly different protocolls? Of course not. Doing the same "job"
> WASD is between 2 and 10 times faster depending on the test.

Ok, got to be a bit honest.  That is some prejudice showing against the 
stuff I don't like.  I really don't have any factual evidence to present.

> http://wasd.vsm.com.au/other/D215_WASD_Apache_notes.pdf
> 
> And besides, WASD is way faster then Apache serving SOAP calls:
> http://wasd.vsm.com.au/SRC/GSOAP/readmore.html
> 
> 
>>
>>> 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?
>