[OT] Co-location of app and DB

[Matt Sgarlata <sg...@users.sourceforge.net>]

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

Re: [OT] Co-location of app and DB

[Matt Sgarlata <sg...@users.sourceforge.net>]

I think Oracle has a JDBC driver that can take advantage of being on the 
same box as the DB, but it actually goes a step further: the driver 
allows you to execute Java code within the Oracle database itself.  I 
would only recommend that approach for small amounts of Java code.  I 
wouldn't try to load up Tomcat inside an Oracle DB ;)

Thanks for your thoughts Henri.

Matt

PS - Sorry I posted this here... it's *way* off-topic :)  I meant to 
post to spring-user, not commons-dev.

Henri Yandell wrote:
> 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
> <sg...@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

Re: [OT] Co-location of app and DB

[Henri Yandell <fl...@gmail.com>]

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
<sg...@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