[Openroad-users] OR App Server Architecture Design

Fri Sep 21 00:47:33 EST 2007

Sounds good. The cost of connection (a round trip to the nameserver before doing the real connection) when doing one connection at start of session is trivial, but as you point out, if you do a connect and a disconnect with every call it slows things down considerably. That said, hardwiring the connection details is not a good approach. How about doing one call at start of session to the method GetConnectionDetails(), and then use those details to Connect(details) a connection before each call. You avoid the round trip to the nameserver. Then on fail, go back to the nameserver.  Just a point of detail. Methods to do this are provided if you want to use them.

I'm pretty sure Kim Ginnerup does this sort of thing using code he wrote before this was available in the product (thanks for the idea Kim :) )  - ie, 'persistent-connectionless' appserver clients.

Rgds,

Neil Warnock
Luminary Solutions
Tel: +44 (0)845 371 4090
Mob: +44 (0)771 265 0291
Email: Neil.Warnock at luminary.co.uk

For more information on Luminary go to http://www.luminary.co.uk<http://www.luminary.co.uk/>
Luminary Solutions Limited Registered in England No 4854134 VAT Reg No. 829 3166 13
Registered Office: 16/17 Pavilion Business Park, Royds Hall Road, Leeds LS12 6AJ

________________________________
From: openroad-users-bounces at peerlessit.com [mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Jonathan Barton
Sent: Thursday, September 20, 2007 1:56 PM
To: International OpenROAD Users
Subject: Re: [Openroad-users] OR App Server Architecture Design

Many thanks each of you for all your help.

I have decided to keep a linear design and have a designated App Server for each web server without using the remote nameserver entries and rely on the web server for the load balancing.

We actually have separate servers for the OR App Server and the Web Services (so will be 4 servers in total).

With regards to the run-time failover to the 2nd App Server, we add the App Server connections to the web server cache so that we do not connect every time.  We have found this speeds up the total time taken for each call.  I am reticent to remove this caching to have automatic failover to the 2nd App Server.  If one App Server fails I can amend the server referenced in the config file and clear the cache by running iisreset.  Saying that automatic failover is a desirable option. I will think about it some more and carry out further testing.

Sorry if this is getting into the realms of a .net discussion! :-)

Thanks again.

JONATHAN

________________________________
From: openroad-users-bounces at peerlessit.com [mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Fabian Anderson
Sent: 19 September 2007 22:55
To: International OpenROAD Users
Subject: Re: [Openroad-users] (no subject)

Hi Jonathan,
            I think there is some benefit in only using local nameserver entries on the App Server.  If you consider each web server as a node, then having the Web Server only use the local app server will still achieve the load balancing and redundancy required.  If any part of the request fails, the Web Server will "fail-over" to another Web Server (and its local App Server).  By allowing remote nameserver entries, you have to secure an extra layer of your application for network access and you may also have extra network traffic.
            If the only Client of the App Server is a local process (i.e. A Web Service on the same machine), then having Remote App Server nodes just introduces extra complexity without much (if any) benefit.  If you are considering the performance aspect, I think it would be considerably reduced under high load as all threads on all nodes will be busy and introducing extra IO and network protocols is only going to reduce the available resources.
            Another point is that if the App Server returns large amounts of data to the Web Services, then all of that IO will happen over the network with remote nameserver entries instead of in memory (which is also much faster).  You need to consider the cost of introducing redundancy/load-balancing at every layer.  For example, for Web Servers, where most of the source files are read-only anyway, is there any benefit in introducing a distributed file system?  If it is a benefit and the option is taken, it will reduce the overall available resources.

Cheers,
Fabian Anderson
Systems Analyst / Programmer
Fintechnix Pty Ltd

________________________________
From: openroad-users-bounces at peerlessit.com [mailto:openroad-users-bounces at peerlessit.com] On Behalf Of Jonathan Barton
Sent: Wednesday, 19 September 2007 18:50
To: International OpenROAD Users
Subject: [Openroad-users] (no subject)

Hi all

I am looking for a bit of advice OR App Server architecture deisgn.

We have two web servers (resiliance/load balancing with .net Web Services) both of which communicate with an OpenROAD Application Server, and all is well.

I have been testing the use of an additional OR App Server using remote nameserver entries on the primary OR App Server for resiliance purposes and I am ready to deploy the new server to the live environment.  But I am concerned about practicalities of effective resiliance and software releases requiring down-time.

Is there any benefit of not using the remote nameserver entries on the Primary OR App Server, but rather have a designated App Server for each web server?  This would enable us to deploy new software without taking the system off-line by simply draining a web server from our nlb (Windows 2003 Network Load Balancing).  Although this would not be true load balancing as far as the App Server is concerned.

Any experience shared would be greatly appreciated.

Many thanks.

JONATHAN
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"University of the West of England"
* Work Email:         jonathan.barton at uwe.ac.uk<mailto:Jonathan.barton at uwe.ac.uk>
* Work No:             0117 3281075

P Please consider the environment before printing.

________________________________
This email was independently scanned for viruses by McAfee anti-virus software and none were found

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Specialist providers of back and front office systems for the financial services industry.
Featuring: Fintechnix(r)
Disclaimer:
Notice: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it.
Any views expressed in this message are those of the individual sender,except where the sender specifically states them to be the views of Fintechnix Pty Ltd.

________________________________
This incoming email to UWE has been independently scanned for viruses by McAfee anti-virus software and none were detected

________________________________
This email was independently scanned for viruses by McAfee anti-virus software and none were found
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.peerlessit.com/pipermail/openroad-users/attachments/20070920/3928fdf3/attachment.html 