[Info-vax] New OpenSSL update from HP

[Stephen Hoffman]

On 2015-06-15 14:07:29 +0000, Jan-Erik Soderholm said:

> Stephen Hoffman skrev den 2015-06-15 15:42:
>> On 2015-06-15 03:25:41 +0000, David Froble said:
>> 
>> 
>> A pool of those whose worker processes are how Apache works on most
>> platforms.   Including OpenVMS.
> 
> Yes, for everything. And the point is that WASD does it all in the main 
> process, apart from specific perl/Python or other scripts.
> 
> So for simple fixed web pages there are no "worker process" at all.

Which means the single process is running with multiple different 
access levels and security contexts, which is something I generally 
prefer to avoid.

Both approaches can and do work.

Where the overhead here might lurk is not at all clear, either.

Process creation is simply not going to have a negligible effect here, 
either.  Not until the web server is operaring at a fairly large load.

But it's that WASD is different that is a problem.  Sure, that it's 
OpenVMS integrated and OpenVMS friendly and all the rest is nice for 
the existing OpenVMS sites, and particularly for the sites that are 
using WASD and/or not using Apache.  For those that know or expect 
Apache or nginx and aren't as OpenVMS-familiar, not so much.   What's 
an advantage to parts of the installed base is not necessarily an 
advantage to other folks.

>>> 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!
> 
> Apache and WASD are build in very different ways.

Yes, Apache and WASD are completely different, from different sources, 
different approaches and generally different.   Is that now in question?

>> Can't say I've noticed Apache being slow on OpenVMS...
> 
> Totalt useless information.

For you, certainly.  For the folks I'm dealing with, they've been 
reasonably satisfied with Apache performance, and they're running some 
large sites.  It's the status of the Apache port and some of the 
associated down-revision or missing features that's bugging some of 
them.

> My Fiat Pinto isn't "slow" (it easily leaves any bike behind). But it 
> is not a Ferrari either.
> 
> In tests WASD is 2-10 times faster in most scenarios.

But it isn't Apache.   Which means that we all get to learn new 
management and administration, which is a problem for some folks.   
(We're likely going to get a whole new IP stack to deal with here, 
which is going to be interesting.  But I digress.)

>> But if Apache is slow, it's time to collect some data.
> 
> Have you at least read *any* of the links provided?
> What "data" is you asking for?

It's figuring out why Apache is slow, and resolving that.   Getting 
what is a standard tool working effectively.  If Apache performance 
stinks or if Apache is poorly integrated, why would folks port other 
stuff to OpenVMS?   If the web server is WASD, you've increased the 
cost of the ports, and you've decreased the interest that many folks 
will have.

The better OpenVMS integration of WASD is not a selling point for me, 
nor is it likely a selling point for existing OpenVMS customers that'll 
have to migrate away from their existing Apache environments, or that 
have paused but are still looking at or are working on migrations away 
from OpenVMS.

Then there's that there'll need to be two environments maintained (by 
somebody), as there'll be folks that still want the existing Apache 
environment.

>> You're right (and again going wider...): the OpenVMS process management 
>> and control model is extremely limited...
> 
> Now, if I'm not totaly wrong, it is the best "process management and 
> control model" currently available on OpenVMS, isn't it?
> So what that other OS'es does some things different?

Um, it's that OpenVMS can get better here.  That Apache can get better 
here.  That the standard tools can be competitive, and that those areas 
where OpenVMS diverges and can provide a significant advantage that can 
be articulated, highlighted and extended.

Being unique and different from the norms means that your product — 
OpenVMS, in this case — needs to be substantially better than the 
alternatives; enough to overcome the hassles involved with porting.   
The number of folks that know OpenVMS and its command syntax and norms 
is a whole lot smaller than those that know more typical means and more 
typical Apache or nginx or such — some focus on the installed base is 
absolutely necessary, but catering to the installed base alone is not 
going to be successful.   The applications and the teams are all aging 
out.

Moving further away from standard tooling is not something that I'd 
generally recommend to folks.  Particularly those running critical 
applications and operations on niche operating systems from small 
vendors; the folks that might end up needing to port away from the 
platform.

I'd be looking to incrementally move the applications and the 
environments closer to standard tooling and interfaces for all but the 
most performance- or reliability-critical and specific cases, too.  I'd 
look to avoid adding cases that would increase the porting effort.  
Differentiation that's not a substantial benefit just isn't 
interesting.   Yes, maybe that cited 2x to 10x factor might be enough 
to encourage that web server migration, if there's not something stupid 
in the Apache port or in the underpinnings of IP or C on OpenVMS that 
can be resolved, and if it's really the web server that's the 
bottleneck in the application environment.   But if Apache is 
substantially slower on OpenVMS on x86 hardware than Apache on Unix or 
Linux on similar x86 hardware, there'll be questions about the 
operating system.

Upgrading OpenVMS features and making it as or potentially more 
interesting than a Unix or Linux box — and without having to overhaul 
applications and port applications, now that's interesting.



-- 
Pure Personal Opinion | HoffmanLabs LLC