File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes JForum and the fly likes Better DB Performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Products » JForum
Bookmark "Better DB Performance" Watch "Better DB Performance" New topic

Better DB Performance

Migrated From
Ranch Hand

Joined: Apr 22, 2012
Posts: 17424
Hi I have been working with JForum now for a few months. I see the features built as very useful however I see some performance bottlenecks which I would like to see them be addressed.

My bias is currently with Mysql, but I am sure many of the other DB installations could benefit from this as well.
Since this is a heavily data driven system with a really high read rate and a lower write rate (don't get me wrong it's high but not as high as the reads), would it be possible to make changes to split the queries into 2 connection pools? (one for read and one for writes/or complicated queries involving both)

This will considerably reduce the amount of DB contention with something like mysql. running mysql in a master slave setup would allow you to connect to one of N slave for reads and write to a single node that would be replicated to the slaves. However currently in the way JForum is constructed this is not possible.

This could easily be abstracted with the DataAccessDriver or another entity which would bind the query to a connection. In cases where a DB implementation doesn't benefit from this type of optimization, we can just use 1 connection pool. And it has no impact whatsoever at that point.

Does this sound valid?
[originally posted on by greggiacovelli]
I agree. Here's the link:
subject: Better DB Performance
It's not a secret anymore!