Hi Mike,
here's the query plan. It's pretty lengthy, sorry.
After I fixed the worst problem the performance difference between
PostgreSQL and Derby is ca. 5x. In my table comparing PostgreSQL and Derby
before after, Derby is flat at 200ms or so for each query.
I *think* what's happening is that
Hi Mike,
after mulling over the feedback, I failed to explain my yellow rubber duck
why I can't introduce some new tables here to avoid the pathologically long
OR statements that match main records against fields.
Basically I had to check if a main record was under a category or any of
it's
Hi Mike,
see answers below inline:
On Wed, Apr 15, 2015 at 2:03 AM, mike matrigali mikema...@gmail.com wrote:
Do many of the queries share a similar structure to the query you describe
in point 5?
Yes, but few have hundreds of arguments. When they do, these queries,
unsurprisingly, take a
While it may be that PostgreSQL is faster, make sure you are measuring
accurately.
First, you should be running the Java Server VM, preferably Java 8.
Second, the server VM JIT compile threshold is 10,000 executions of a given
method -- so the VM will get faster and faster as it progressively
I compared the performance on PostgreSQL vs. Derby for this report.
Unsurprisingly PostgreSQL performs much better.
The database that I'm working with has grown over the years. I have a
feeling that we crossed some threshold and that Derby performance has
decreased to the point where it is now
Our application is a bit off the beaten path in that what matters to
us is performance from standstill to user logging in and running a
report. Caching isn't very helpful because the user won't be running
the reports twice in a row and new data will be entered in-between
each time the user runs a
Do many of the queries share a similar structure to the query you describe in
point 5?
Can you give an order of magnitude on the number of expected rows in t2 from
that query, also
maybe an estimate of overall size of the database tables involved in all the
queries.
Is the target system
I've been able to a more real-world testing that takes into account
other things going on in the system that takes time.
For the worst report(the default report), the overall system performance I get:
First run: PostgreSQL = 15s / Derby = 45s
Second run: PostgreSQL = 5s / Derby = 23s
Are you sure that under Tomcat the application is really using the Tomcat
connection pool? If not that would certainly account for the differences.
Even if Tomcat DBCP is configured, checking that the pool configurations
are similar would seem like an important check.
-Brett
On Mon, Apr 13,
I don't think that's the problem:
1. The same amount of heap is configured
2. I've checked with VisualVM and it uses much less than the provided
memory(ca. 250mbyte vs. 1024mbyte heap).
On Mon, Apr 13, 2015 at 4:54 AM, Bryan Pendleton
bpendleton.de...@gmail.com wrote:
I've tried to figure out
I know the Tomcat setup isn't using the clientdriver when it slows
down, because when I first tried to switch to the ClientDriver it
failed. After I copied the derbyclient.xxx.jar to tomcat/lib/, it
worked.
On Mon, Apr 13, 2015 at 9:51 AM, Dyre Tjeldvoll
dyre.tjeldv...@oracle.com wrote:
On
I'll be trying to do more logging.
Do you have any handy pointers to documentation?
To log SQL statements seems like the most promising:
https://db.apache.org/derby/docs/10.11/ref/rrefproper43517.html
I didn't find anything to log connection IDs (distinct/count).
I never tried JMX mbeans
And, by testing with a network server I think you can access JMX mbeans
with VisualVM/JConsole to check connection counts.
--
Kristian
13. apr. 2015 13:12 skrev Kristian Waagan krist...@apache.org:
Hi Øivind,
Have you turned on SQL-logging/-tracing in Derby to check the activity?
Possible
Hi Øivind,
Have you turned on SQL-logging/-tracing in Derby to check the activity?
Possible things to check:
o connection IDs (distinct/count)
o expensive connection validation queries (not all of these are direct SQL,
check pool docs/conf)
o commits?
o different queries?
While one would expect
Have you put the app under a profiler to see what components are taking
the most time in each container? Seems like the best way to get some
facts on the table.
On Sun, 2015-04-12 at 23:50 +0200, Øyvind Harboe wrote:
Hi,
I'm having problems with performance degrading dramatically when I
I did. See the stacktrace in my initial post.
On Apr 13, 2015 3:18 PM, Tim Watts t...@cliftonfarm.org wrote:
Have you put the app under a profiler to see what components are taking
the most time in each container? Seems like the best way to get some
facts on the table.
On Sun, 2015-04-12
I've tried to figure out what the differences are between these two
environments without luck.
Perhaps the amount of memory available to Derby is dramatically
different in the one case than in the other, and Derby is working
very hard to accomplish its tasks with insufficient memory?
bryan
I found another crucial clue:
if I use ClientDriver instead of EmbeddedDriver and connect to the
Derby database running under Jetty, I get identical performance with
Tomcat and Jetty.
This is very strong indication that there is something about the
combination of EmbeddedDriver and Tomcat that
18 matches
Mail list logo
