[Info-vax] Accuweather new contract

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Kerry Main
> Sent: 29-Mar-15 11:08 AM
> To: comp.os.vms to email gateway
> Subject: Re: [New Info-vax] Accuweather new contract
> 
> > -----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."
> 

More background on WASD web serving from the HP site:

http://h71000.www7.hp.com/openvms/journal/v7/wasd.html 

Also talks about the issues associated with Web Apps using a process
per connection model on OpenVMS (Apache)

In a nutshell - instead of trying to trying to solve a problem by copying
a UNIX model on OpenVMS (e.g. Apache), WASD uses OpenVMS 
mechanisms to solve the problem more efficiently.

Regards,

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

Kerry dot main at backtothefutureit dot com