[Info-vax] Accuweather new contract

Kerry Main kerry.main at backtothefutureit.com
Sun Mar 29 11:07:30 EDT 2015


> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> johnson.eric at gmail.com
> Sent: 29-Mar-15 9:11 AM
> To: info-vax at info-vax.com
> Subject: Re: [New Info-vax] Accuweather new contract
> 
> On Saturday, March 28, 2015 at 2:45:49 PM UTC-4, David Froble wrote:
> 
> > To me a web server is just a listener socket, accepting connection
> > requests, with some capability to do something with some of the data
> > sent by a client.  Perhaps over-simplified, but, that's what it does.
> 
> That's a fair summary.
> 
> > With sufficient specifications, I cannot see why a web server could not
> > be implemented on VMS to satisfy any requirements.  Even a large
> cluster
> > running multiple copies of the web server to meet the volume of
> > connection requests.  (No, I haven't volunteered to write such.)
> 
> In my experience, that code is always just slower and less scalable than
> the same counterpart on Linux. I've participated in such an in house
> project (home grown http server on VMS) and it would always have
> higher
> latency than its counterpart on Linux.
> 
> After years of disbelief and frustration, I spent a few weeks really digging
> into it, and from what I could observe, much of the blame really sat at
> the
> hands of the TCP/IP stack. Interestingly enough, both Multinet and
> TCP/IP services came up short.
> 
> I believe its possible to fix them, but it will take time.
> 

Wrt to Multinet, I am wondering if your testing was before the most
recent version V5.4 and if it included things like fastpath in the testing:

>From Multinet V5.4 background info:

* The INET and BG drivers have been modified to use buffered I/O, 
which delivers higher throughput on multiprocessor systems. (Note 
that  users running on OpenVMS 8.x may need to increase their non-
paged  pool SYSGEN variables.)

* Support for FASTPATH to increase throughput when exchanging 
packets with the Ethernet controller(s) on OpenVMS 8.x systems.

If it was Apache on OpenVMS, then I could see how another platform 
might outperform Apache on OpenVMS. As I understand it, Apache
uses a model of a parent process controlling many child processes 
(one per request).  OpenVMS process creation is more expensive in 
Terms of resources consumed. UNIX process creation is different and
does not contain the overhead of OpenVMS process creation (apples
and oranges)

WASD uses a dedicated server process  - not unlike what a transaction 
processing system uses i.e. dedicated processes that  handle many 
incoming connections in a more efficient model 

>From a past WASD presentation from Mark Daniel:
"WASD uses a single process and ASTs to enable an event-driven 
(mainly I/O but with some timer queue) multiple request concurrency
This model could be referred to as lightweight-threading.  These are 
very lightweight in the sense they are VMS' native threading model, 
almost negligible servicing cost and certainly containing none of the 
thread-management overhead of something like POSIX Threads or 
a process context. The WASD conservative approach to resource 
consumption in this respect is often a significant factor in preference 
over other approaches."


Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com






More information about the Info-vax mailing list