Recently, we responded to an RFP which called for an enterprise application with a Web interface, RDBMS, the usual stuff. Since we needed to compete on costs also and the necessary server hardware, OS, appserver and DBMS licences were to be included in the bid, I suggested that we keep the hardware costs low by colocating the application server and the DBMS on the same machine.
- Posted by: Ugo Cei
- Posted on: March 17 2005 02:12 EST
I explained that this configuration was actually better, in terms of performance, than having app server and DBMS phisycally separated. Turns out that we won the bid, but now the customer is complaining that this cannot possibly be true, and that we should be using two servers instead of one. I suspect they want us to provide them both without changing the price.
Anyway, since it was me that suggested that configuration, I am being asked (by tomorrow morning!) to provide documented justification for the claim that colocating application and database server is better for performance. I will have to dig a quote from Ted Neward's blog, since I got the idea from there. I think I can find something relevant from Martin Fowler too.
Can you help me please?
- Colocating application and database servers by adrian osullivan on March 17 2005 05:23 EST
- Colocating application and database servers by Slava Imeshev on March 25 2005 15:59 EST
- Colocating application and database servers by Jose Ramon Huerga Ayuso on April 06 2005 15:20 EDT
I can't think of a reference off the top of my head but the justification for your decision is quite logical - do your bosses accept logical arguments?
We have exactly the same situation on one of our projects here. DB and appserver are colocated.
The main reason for destributing app and DB on different servers is to distribute CPU usage. The cost of doing this is the time taken to send the DB queries across a network connection. I would recommend you do diagnostics on the amount of CPU being consumed on your server when both the appserver and DB are running on it. If it has some spare capacity, there is little reason to distribute.
A second factor is disk space. Are you also storing your DB data files on the same server? This may actually have elevated to cost of the server, as there is really no argument to have high-performance CPU servers require large amounts of disk space. We store data on a file server, and run Oracle on a separate 4-CPU, 16GB RAM server. This allows Oracale to cache most of the data and minimise disk reads from the file server.
The cost of doing this is the time taken to send the DB queries across a network connection.
This is often negligible when the appserver and db server are running on low latency pci-x or onboard gigabit cards connected to the same switch.
>. I would recommend you do diagnostics on the amount of CPU being consumed on your server when both the appserver and DB are running on it. If it has some spare capacity, there is little reason to distribute.
It is not that easy to simply say spare capacity means you are running at peak efficiency. Its far better to have correctly tuned machines for each task at hand, whether it be web serving, application logic or database. Having massive context switching between an application and the database that the application is using, introduces the kind of contention that the tried and proven arrangement of separate machines for each tier solves.
Of course, this all depends on the kind of scale that your system is. If you're talking about some small system with a couple of hundred users doing lightweight access, then sure, co-locate. If you need high scaleability and different levels of node balancing between tiers, then splitting the tiers into correctly assessed hardware is a sound path.
Jason, your reply makes very interesting reading. Can you recommend any further resources to find out more about this whole area - books or websites.
I think you make good points, but this is really one of those "religious" issues where different combinations lead to different performance, maintenance, and architectural trade offs.
I strongly agree with you that co-locating poses some scalability issues. It’s actually not applicable when you have a server cluster!
Co-locating is an excellent choice in small to medium size where clustering is not required.
Computer systems are like natural systems, they tend to grow, evolve, and expand, hence co-location could be a very sexy choice if you’re starting small and growing, after which you can easily separate the forces without affecting the application at all since you will be using JDBC connection pools and Datasources; the database location should be immaterial !
My 0.2c ! :-)
Turns out that we won the bid, but now the customer is complaining that this cannot possibly be true, and that we should be using two servers instead of one. I suspect they want us to provide them both without changing the price.Anyway, since it was me that suggested that configuration, I am being asked (by tomorrow morning!) to provide documented justification for the claim that colocating application and database server is better for performance.
Your customer is asking for this because they know you cannot justify this decision. Co-location degrades performance because both the app and the db server will compete for the limited computational and IO resources under load.
That's true that many use co-location, but it is done for cost reasons while accepting negative performance impact as a tradeoff. Co-location is a poor man's solution, not a highly scalable/performing one's.
Co-location is a poor man's solution, not a highly scalable/performing one's.
Yes. The 2 tier client server architecture in 90s (thin client; business and persistence logic running in DB on same machine; eg Informix4GL) usually did not scale more then 200-300 concurrent users. The reason was the co-location.
This is a motivation for the app servers. They run on different machines and they should take as much work (presentation, business and persistence logic) as possible from DB machine. The app servers can horizontally scale almost linearly (load balancing without session fail over).
It also possible to horizontally scale the DB, but it is very application specific ...
On other site if you have only 1-2 users, who will read huge amount of data from DB and almost no business logic, then you maybe should go for co-locating architecture ...
If you have a site with small traffic it does not matter ....
My suggestion is to open the application in a production environment where the app server and the database are in the same physical machine. As long as more and more users start using the application, you may consider moving the database to a second machine.
Remember that when you add a new application, the first months only a fraction of the users in the company start using the application, so you have several weeks/months to recollect performance metrics that can help you make the decission about moving the database to a second server.
Jose Ramon Huerga