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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
