Java application has performance issue when a mandatory profile is used
This is a tough one. I don't have all the information but (long story short) I have picked up this support issue which I am trying to solve remotely with limited information.
Here is the scenario.
My client has a custom built java application (compiled AFAIK) that runs with IE and is used to fetch images from a server (Details on actual functionality are scant).
What they have noticed is that the application takes up to 7 seconds longer to execute when the user is logged in with a mandatory profile than if they were using a local or roaming profile.
We have checked all the obvious like missing settings but it definitely seems to have something to do with the profile being mandatory. We have taken a roaming profile that works and just changed the ntuser.dat to ntuser.man - and the problem occurs.
I am pretty sussed on user profiles but java is not my area of expertise.
Anyone have any ideas why this application should perform differently just because of the profile used?
Here is the scenario.
My client has a custom built java application (compiled AFAIK) that runs with IE and is used to fetch images from a server (Details on actual functionality are scant).
What they have noticed is that the application takes up to 7 seconds longer to execute when the user is logged in with a mandatory profile than if they were using a local or roaming profile.
We have checked all the obvious like missing settings but it definitely seems to have something to do with the profile being mandatory. We have taken a roaming profile that works and just changed the ntuser.dat to ntuser.man - and the problem occurs.
I am pretty sussed on user profiles but java is not my area of expertise.
Anyone have any ideas why this application should perform differently just because of the profile used?
ASKER
Thanks Venabili,
Yes - we have about 1GB of ProcMon dumps for different scenarios where users are logging on with mandatory and roaming profiles.
I have been through them as best I can but at between 100MB and 190MB per dump there is too much information. I have tried eliminating various processes to see what is going on but the shear quantity of registry accesses by the target application and IExplore.exe are overwhelming.
It is also comparing apples with oranges to a certain extent because the process paths in the two environments are not exactly the same. Apart from the order of things being a bit mixed up they don't always access the registry the same number of times - this does not seem to account for the time gap though - I could not find any point where there was definitely a jump that would point to the issue.
The only thing I did find in one of the dumps only was where the javaw.exe environment suddenly started creating a bunch of threads - (about 15 of them) - and then destroying them - this took about 4 seconds - but it was only in one of the dumps.
This is pretty much where I am now and why I am stumped.
The obvious solution is to go back to the developers - but apparently that is not an option
Yes - we have about 1GB of ProcMon dumps for different scenarios where users are logging on with mandatory and roaming profiles.
I have been through them as best I can but at between 100MB and 190MB per dump there is too much information. I have tried eliminating various processes to see what is going on but the shear quantity of registry accesses by the target application and IExplore.exe are overwhelming.
It is also comparing apples with oranges to a certain extent because the process paths in the two environments are not exactly the same. Apart from the order of things being a bit mixed up they don't always access the registry the same number of times - this does not seem to account for the time gap though - I could not find any point where there was definitely a jump that would point to the issue.
The only thing I did find in one of the dumps only was where the javaw.exe environment suddenly started creating a bunch of threads - (about 15 of them) - and then destroying them - this took about 4 seconds - but it was only in one of the dumps.
This is pretty much where I am now and why I am stumped.
The obvious solution is to go back to the developers - but apparently that is not an option
>> My client has a custom built java application that "runs with IE"
Is it a java-applet or a stand-alone java application?
If its a java applet you can try out a few things:
1. to make sure if, for some reason, the network access is slow, use a proxy such as fiddler to see time taken for each request
2. On the system tray java console, take frequent thread dumps and inspect the stack -- they might give a hint if there's any java security policy is causing this
(I frankly do not expect any of this)
From procmon dump, filter the list with your process of interest and compare timestamps for the faster and slower. I have found it mostly helping out in such issues. (you might see death by thousand cuts rather than a single operation causing a lot of delay)
Is it a java-applet or a stand-alone java application?
If its a java applet you can try out a few things:
1. to make sure if, for some reason, the network access is slow, use a proxy such as fiddler to see time taken for each request
2. On the system tray java console, take frequent thread dumps and inspect the stack -- they might give a hint if there's any java security policy is causing this
(I frankly do not expect any of this)
From procmon dump, filter the list with your process of interest and compare timestamps for the faster and slower. I have found it mostly helping out in such issues. (you might see death by thousand cuts rather than a single operation causing a lot of delay)
I see that the difference in 7 seconds? what is the absolute time taken in each case? slower by what percentage?
ASKER
Thanks for the response, syskrash
Difference is around 6-7 seconds to 14-17 seconds.
the process we are looking at as javaw.exe - which I assume means this is an applet. I am currently around 14,000Km from the client so don't have the means to check anything other than what I receive through emails.
I have filtered out the process (in this case javaw.exe) and had a look - but there are 56,000 entries and it is difficult to see where the time is going loopy.
Also, as I understand things the application running according to procmon does not match what the user is seeing - what I means is the start and stop times of the process don't necessarily match the start and stop times of what the user sees appearing on the screen (which is what they are using to measure the time difference).
Responding to your points above
1. Network - we pretty much ruled this out through repeated tests from the same workstation to the same server only changing the type of profile. Consistently 6-7 seconds on a Roaming profile and consistently 14-17 sec on the Mandatory - so I don't think the network comes into play.
2. I can try and explain how to do this to the guys on site - but I am not sure I know exactly what to do - and they are asking me so that gives you some idea on the skills chain involved
Not ideal but that is what I have to work with - I thought there might be something obvious out there the Java Guru's knew about that might help.
Thanks for the response though - every alternative view point is useful providing more perspective.
Difference is around 6-7 seconds to 14-17 seconds.
the process we are looking at as javaw.exe - which I assume means this is an applet. I am currently around 14,000Km from the client so don't have the means to check anything other than what I receive through emails.
I have filtered out the process (in this case javaw.exe) and had a look - but there are 56,000 entries and it is difficult to see where the time is going loopy.
Also, as I understand things the application running according to procmon does not match what the user is seeing - what I means is the start and stop times of the process don't necessarily match the start and stop times of what the user sees appearing on the screen (which is what they are using to measure the time difference).
Responding to your points above
1. Network - we pretty much ruled this out through repeated tests from the same workstation to the same server only changing the type of profile. Consistently 6-7 seconds on a Roaming profile and consistently 14-17 sec on the Mandatory - so I don't think the network comes into play.
2. I can try and explain how to do this to the guys on site - but I am not sure I know exactly what to do - and they are asking me so that gives you some idea on the skills chain involved
Not ideal but that is what I have to work with - I thought there might be something obvious out there the Java Guru's knew about that might help.
Thanks for the response though - every alternative view point is useful providing more perspective.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the response - unfortunately client has not responded so I don't know if they have solved the problem.
Is there ANY logging that can show where the time goes - does it happen all over the application or only for some operations?