commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [OT] Co-location of app and DB
Date Thu, 10 Mar 2005 06:21:28 GMT
Wonder if any of the native JDBC drivers can take advantage of being
on the same box. Rather than using full networking, they could use the
faster local networking thingymabob (yup, you can tell I only have a
vague grasp on what I'm suggesitng).

For my personal stuff, I've always run the database and applications
on the same machines. Due to the increased security (a local database
isn't open to the Internet) and because for personal stuff I'm on a
pretty constrained budget/setup. Also because apps become atomic; if a
machine dies, I only lose 1/4 of my apps (as they're spread over 4
boxes). If I was using one as a dbms, and it died, all apps would die.

Also could make it easier for me to migrate from one box to another
when there is a problem; though currently I have different styles of
box. An Apache 1.3/PHP/Mysql box and a Java/Apache2/Postgres box.

So there are some pluses.

That said, it's probably not worth it for performance. Stick gigabit
ethernet in. I imagine that most databases will still go out to the
TCP/IP layer for the database connection, so it won't be as quick as
could be hoped. After that, it'll depend on the SQL I guess, and the
application. Anything classed as a small application is probably not a
huge performance worry a la Amazon's site or something.

I recently tried to use hsqldb as a memory-cache for an Oracle
database to save the many round trips that were happening (code reuse
meant that we wanted to run the real-time code in a batch mode, but
didn't want a separate series of daos/sql to talk batch to Oracle). 
As it was a memory only database, I was hoping for big improvements in
speed. Instead I got minor improvements. There are a whole host of
reasons as to why, but the moral is that to show said major
improvements I'm going to have to do more than just switch to memory.

More indexes for the memory-only (max table was 1200 rows, but the
nasty SQL statement was slow, so I added the one index). Compare to an
Oracle db under load and not one sitting idle and able to do stunning
caching. Run over larger datasets to see if memory becomes better over
time.

The only one I'm expecting good results from is the second.

So, same machine might be worth it if it saves you rack rental, or
allows your failover system to be easier, but likely as not isn't
worth it if you're just concerned with performance.

My one-pence (not even worth tuppence),

Hen


On Wed, 09 Mar 2005 13:54:33 -0500, Matt Sgarlata
<sgarlatm@users.sourceforge.net> wrote:
> For performance and other reasons, we collocate the presentation tier
> and business object tier on the same server.  Question: why not take
> this even further and put everything on the same server?  If the DB is
> on the same server as the rest of your application, then won't you get a
> performance boost since the DB and app servers don't have to communicate
> over a slow network, but rather can communicate through the server's
> main memory?
> 
> I understand that for performance tuning of the database and to ensure
> proper backups, etc. that the DB server often has different needs than
> the application server, so that is why they are kept separate.  However,
> I'm wondering if for small applications it wouldn't just be better to
> keep the DB server and the app server on the same box.  What do you guys
> think?
> 
> Thanks,
> 
> Matt
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message