DB access very slow

[j0lea]

I have two installation of nukes, one from snapshot from around sep/4, another from around sep/19. Both of them are running using hsqldb, same machine same jdk, same everything. Now, if I deploy from the sep/4 snapshot all pages come back very fast but if I deploy from the sep/19 one, the logo (on the top of the page, orange "nukes on jboss") comes back very very slowly. I'm using jboss 3.2.2RC3 and I know there were some important changes in nukes between those dates, Any change that could explain this behavior?

[julien1]

I don't think so, there was no special changes between the two dates. Did you try to put jboss in commit option A so it caches lot of things between access ?

to do that you edit jboss/server/default/conf/standardjboss.xml, find the CMP 2.x container and change the commit-option from B to A.

tell me if it improves things.

julien

[j0lea]

I tried the commit option A, same results, and actually it seems that is not only graphics as I originally thought, but every request is taking 2-3 (some even more) longer. Just to put things in perspective I've created a jmeter script to get some real numbers, the script logs in, simulates a click in manage groups, manage html, etc... (all the default admin options) then logs out. I did it three times in a row for the old snapshot, three for the recent snapshot (commit option B), then I repeat the same tests for commit option A. The results clearly show times for the recent snapshot are an average twice or three times as big compared to the old snapshot (it doesn't matter if I'm using commit option A or B).
I've attached the results and the jmeter script.

--juan

[julien1]

I will look at it as soon as I have a free slot to fill ;-), the #1 priority is finishing forums for now.

Did you try to profile one call with optimize it ? to see where is spent most of the time ?

Also what are the jboss configs ? the first is jetty and the second tomcat ?

julien

[j0lea]

I did some profiling, there is function call that doesn't appear when executing the old snapshot, but I get every single time in the new snapshot as the one that takes most of the time:

org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke

I'm still using RC3, default config with tomcat.
It is definitely not a problem with DB access, although is kind of strange that nobody else is noticing this (or at least I haven't seen any comments)

--juan

[julien1]

still strange, I will look at it when I will have s free slot for that. Anyway I want to test forums performances before going live with them so I will do it at the same time.

what are your doing with nukes ? evaluating it ? using it ?

julien

[skywind8]

Just to note, I am seeing this same behavior on the completely fresh installation of nukes that I just got working.

It's particularly obvious when I click 'Home' and it reloads the logo. I'm also noticing that the logo appears to be 2 megs in size - kinda large for that tiny of a png.

If I re-save the logo.png in Adobe ImageReady as "optimized" it is only 32 kb (and looks just fine).

Maybe this is affecting some of the performance, at least for anyone still showing the standard logo?

[julien1]

for me the logo is in png and is 32kb.

sh-2.05a$ pwd
/Users/julien/Java/nukes/nukes/src/bin/nukes-lib-jar/org/jboss/nukes/core/themes/invaders/images

sh-2.05a$ sh-2.05a$ ls -l
total 64
drwxr-xr-x 5 julien staff 170 Oct 10 01:04 CVS
-rw-r--r-- 1 julien staff 32491 May 31 19:06 logo.png

are we talking a bout the same one ?

[skywind8]

We are talking about the same image but from two different perspectives... I'm used to the 'properties' of an image (viewed through the browser) matching the actual file size on disk - in this case it didn't. (See attached screenshot.) My copy of the image is also only 30 k on the server.

I timed the image loading today - the text for the page loads practically instantly, and then I wait 17 seconds for the logo to appear. I don't know what the server is doing with all that time, but it certainly affects user perception of whether the page is loaded.

If you have any pointers for how I could track it down, I'll try - I'm just lost as to where to look, since I'm not sure what all is involved in serving up this image.

[skywind8]

And just to cover the obvious... this isn't a slow net connection for me, as the machine I'm using is on my local LAN with a direct ethernet connection.

[j0lea]

good observation, after reading your post I did a little debugging, the problem seems to be in the function writeTo(OutputStream out) (class org.jboss.nukes.resources.ByteArrayResource), it says:
int delta = content.length - offset;
while (delta > 0 && !shutdown)
{
out.write(content, offset, delta);
offset += 256;
delta = content.length - offset;
}

I think it should say something like this:

int bytesToWrite = content.length - offset;
int chunkSize = 256;
while (bytesToWrite > 0 && !shutdown)
{
if(chunkSize > bytesToWrite) // last chunk
{
chunkSize = bytesToWrite;
}
out.write(content, offset, chunkSize);
offset += chunkSize;
bytesToWrite = content.length - offset;
}

I did that change, rebuild and everything works OK, I don't get the delay anymore and my files have the right size.

--juan

[julien1]

yes I changed that part recently and bugs may be there. I will see this week end.

thanks.

julien

[julien1]

after watching carrefully, this loop was totally bugged, my mistake. it was soomething like an arithmetic suite writen to the output like :

1 + 2 + 3 + ... + n = n (n+1) / 2

I changed the code according to what you did.

thanks for that bug, julien