RE: Witango-Talk: database on another server

[Garth Penglase]

Title: RE: Witango-Talk: database on another server

So that's what you get for asking a simple question Alan - a bucket load of info about all sorts of stuff - isn't this list great?

:-)

So the answer is: yes it'll work, and work pretty well; and as long as you keep the same database names and dsn name (though you can have different development and deployment dsn setups in Witango) you won't have to change a thing in your tafs. Not bad hey?

However, in response to questions Steve was raising, I have used a distributed setup, and while it means that you can tune each box for a particular task which enhances performance and can reduce server problems, there is always the fact that the connection between the two boxes must remain active  - easy enough within your own network, but if it's spanning networks there is your weakest link in your web app. Also you have twice the chance of hardware failure affecting the availability of the web site now. So there needs to be a significant performance or business reason, I believe, for this approach to be worthwhile - and if you don't have control over the either network that your boxes reside on you can bet that someone will do something to screw it up for you somewhere along the line (thanks for that change in the routing table that you just forgot to mention guys!)

hope it goes well for you

Garth

Hi Steve,

 

The short answer to your main question is YES. In effect it in many cases probably something like doubles them or even more if the server is heavily utilising the virtual memory.

 

The somewhat more detailed answer:

 

- You typically really have THREE application servers residing on your one_and_the_same server box:

    1. the web server (Apache, IIS...)

    2. the WiTango server

    3. the db server

 

- As they all are "application servers/services" they have typically more common resource need patterns than very different. They all rely heavily on:

    - CPU

    - physical memory (RAM)

    - system & memory bus utilisation

    - typically less so file access (HD), but in some cases this too, especially if there isn't enough RAM memory then the file I/O might become the real bottleneck when the virtual memory swapping starts (slowing things down drastically).

 

- If you run out of a one server configuration this is because each of these services just get their share of the scare resources of the server. Splitting them on two different servers will double their available HW resourses.

 

- I suppose the web server is today the least critical component in this chain and therefore it can as well reside on the same server as WiTango, but I have some distant memory fragments about it being even possible to separate that on a distinct server. But probably the trade off isn't that big in most cases making it worth the effort, so let's forget that and keep the web server on the same machine as the WiTango server.

 

- The ODBC is rather just an API in both ends between the Witango and db services handling the communication between these and abstracting the physical connection between the services. Neither the WiTango nor the db needs to know where

the other one resides physically (can be as well on the same machine or on the other side of the world connected over internet, the services don't care). So the ODBC API on the db end is in most cases just a part of the db engine, and definitely not the other way round.

 

- In most cases there are no trade offs having them separated, on the contrary. Ok, you need to buy yourself a new server, install it and manage it but it's probably a LOT cheaper than upgrading both hw and sw licenses to a multiprocessor system (and in worst case still having the services fight over the same cpu resource if they are not correctly configured). You get the possibility to more effectively manage load balancing and fault tolerance by in the future adding new servers in parallell based on their service specific needs for each of the services separately as the need grows. If your result sets returned by the db server are really big/huge (for example images) you probably would want to connect the servers over a dedicated GB segment/link to isolate/handle the task. But between just two servers this can be as easily handled as by just getting two GB NIC:s and a crossower cable...

 

- The final answer in a specific situation is to be had by monitoring the usage pattern of the separate services of those scare resources. If you are out of RAM (or having excess file I/O:s) then you might start adding more RAM. This will also free up some other resources. But if the CPU or more than just one of these resources utilisation is the bottleneck then start by splitting them on different servers.

 

 

Jan

 

 

 

-----Original Message-----
From: Fogelson, Steve [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 02:44
To: '[EMAIL PROTECTED]'

Subject: RE: Witango-Talk: database on another server

Hi,

 

Does splitting the db to another server save resources on the Witango server?

 

I would assume it saves disk reads, but would it save cpu usage? For example , if the search action has "ordered by" columns or a join?

 

I don't know anything about ODBC. Not sure if the DB engine is part of OBDC.

 

Is there a way to locate the DB Engine on the second server to move that processing to the 2nd server?

 

What is the tradeoff of having to transmit the results back to the web and Witango server assuming over the network?

 

Sorry for the questions, but I have always wondered what are the benefits and drawbacks of moving the db to another server and is there a better way to do it.

 

Thanks

 

Steve Fogelson

Internet Commerce Solutions

 

 

 -----Original Message-----
From: Jan Magnusson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 5:07 PM
To: [EMAIL PROTECTED]
Subject: RE: Witango-Talk: database on another server

Hi Alan,

 

Maybe I misunderstood the question, but if you are going to have WiTango on one server and the db on another then just (re)configure the ODBC System DSN drivers on the WiTango server to point to the distant db server.

 

The Witango service doesn't know where the database physically resides, just which ODBC connection to use.

 

And if you use the exact same name, uid and pwd for the new odbc connection you should not even have to touch the Witango server, service or taf files. Things get a lot more complicated if you don't use the same name, then all the tafs need to be edited/updated.

 

I don't know if there are some r:tango specific additional complicating matters, but this should work if it's now configured on an ODBC connection.

 

Jan

-----Original Message-----
From: Alan Wolfe [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 00:32
To: [EMAIL PROTECTED]
Subject: Witango-Talk: database on another server

how would you go about setting up a datasource that was on another server from where the datasource was being used by a .taf?

 

i have no idea where to even begin looking for information on this one! (:

 

we're using r:tango 5 on windows 2003 and the database is going to be on an NT 4 machine which has r:tango 2000 on it (so both sides have oterro if that matters).

 

We're trying to set up an experiment to see how realistic it would be to have a database on another computer across the internet (im guessing not very realistic but maybe for limited usage it would work?)

 

Thanks!

Alan

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf

-- 

Garth Penglase
Broadband Media
http://bbmedia.com.au
ph: 0500 527 000

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf