[Info-vax] New OpenSSL update from HP

[Jan-Erik Soderholm]

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.

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?