ADF 11.1.1.2 performance issues

[prasad narahari]

All,
I just joined a team, we have a ADF application on which users are complaining the performance of the application. We are entering into a fire mode on this. So, trying to check your thoughts on what should be the immediate focus points.

Here is one of the third party testing report using load testing tool Pingdom Tools,

This specific test was done on April 24 at 13:44:57 from Dallas, Texas, USA. The web page took 21.57 s to load, used 10 requests, and weighed in at 7.9 kB.

The Google Page Speed performance grade for this web page is 74/100.

The application is accessible to both external and internal customers.

I know we will have to address this at various levels, but a quick check of the code, found following:

1. There is only one application module for the whole application

2. 80 VOs, 36 jtfs, 6 pages, 11 taskflows, 110 concurrent active sessions of users, 3265 registered users

I dont want to skew your suggestions only at application level.

Look forward to hear your suggestions and recommendations.

--
Thanks
Prasad
Cell:510-565-5008

[Chris Muir]

Hi Prasad

The EMG gets a lot of questions like this, where people say their
application isn't performing and supply some statistics and hope we
can solve the problem. It's pretty hard to solve from our angle.
It's like telling your mechanic via email your car has 340 bolts, 1
engine, 16 gears, 4 seats and asking why your doesn't car go fast? As
you can see the information is fairly meaningless (without attempting
to be rude), we're limited by the information you tell us (what you're
not telling us is also important), and we're constrained by the
tyranny of (virtual) distance.

Can I suggest a different approach?

If what you've told is correct and there is only 1 page with a
problem, work with the divide and conquer approach. From what I can
gather (because your page makes multiple requests) you must be using
regions/embedded task flows, and the combination is causing the delay?
Comment out half the page content (and relating bindings) and
re-measure. Still a speed problem? Yes, the issue is in the code
that isn't commented out. So comment out half that again and
re-measure. Still a speed problem? ... and so on ... If the answer
is no at any point, then it's the other 1/2 you just commented out
that has issues.

Once you get it down to one component, say it was region with a table,
that table must be based on a VO. Is the VO query tuned? How long
does it take to return a result? This is just an example of where
things can go wrong, but you see the divide and conquer approach right
through the view layer now to the model layer.

The technique is fairly obvious I'm sure, but you'll appreciate the
point at the moment the picture is way too high for us to assist. So
please analyze the problem and come back with something substantial
and focused, not generalized.

What I can say from my own experience with programming ADF in real
production systems, there has always been a reason on my side (or my
team's sides) where we've done something suboptimal. I haven't yet
hit a point where it's the framework that was the worst offender
(ignoring bugs). There will be arguments by the doomsayers that ADF
doesn't scale, but for most customers they wont have hit the
frameworks breaking point yet.

Regards,

CM.

PS. Just a reminder, I'm an Oracle ADF product manager.

> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodolo...@googlegroups.com
>
> All content to the ADF EMG lies under the Creative Commons Attribution 3.0
> Unported License (http://creativecommons.org/licenses/by/3.0/). Any content
> sourced must be attributed back to the ADF EMG with a link to the Google
> Group (http://groups.google.com/group/adf-methodology).

[Simon Lessard]

Hi Prasad,

As Chris we cannot do miracle without seeing the application, but I can think of an easy performance boost wit ha single app module and 80 VO and it's to enable lazy loading of the component, this will prevent all 80 VO from being loaded with the AM instantiation. To enable that, open the application module, go to the General tab, open the tuning section (collapsed by default), click the customize instantiation behavior and select Lazy Loading.

Other than that you could try the following excellent suggestion by Andrejus: http://andrejusb.blogspot.fr/2011/11/stress-testing-oracle-adf-bc_16.html.

Regards,

~ Simon

--

You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

--
Simon Lessard, ADF Architect

CMA SYSTeMS

( +33(0) 6 79 37 39 85 (France)

( +1.418.930.0279 (Canada)

[Chad Thompson]

On Wednesday, April 25, 2012 at 8:45 AM, prasad narahari wrote:

Here is one of the third party testing report using load testing tool Pingdom Tools,

This specific test was done on April 24 at 13:44:57 from Dallas, Texas, USA. The web page took 21.57 s to load, used 10 requests, and weighed in at 7.9 kB.

In addition to the great suggestions about database tuning, you'll also want to look at how security is implemented on your application - pages (or task flows) that have security enabled for users and groups can generate quite a bit of LDAP traffic - make sure that the performance between your app and LDAP is also optimized as much as it can be.

The bigger recommendation:  "Pingdom" is a difficult tool to use for measuring system performance - start by looking as much as you can at the pieces of the application to see where the pain point is. If you stress test the BC components and everything looks 'fine', then look at page security, etc.  Make sure that you're making adjustments based on measurements, not intuition.

- Chad

[missgeburt]

Fine tuning the BC is another approach, which is the 2nd that pops up in my mind after Chad Thompson's suggestion.

In many cases, what you need to retrieve is just a few rows for populating a table, not all the data from the database.

Doing the same for LOVs view objects will reduce the time for launching the LOV's popup as well (although in your case it wouldn't have impact on the test values).

Regards, Todor

[Florin Marcus]

One quick note on Pingdom tool:

It's hardly a good way of testing the scalability of your ADF
application.
Each ping(request) from the Pingdom server will create a new HTTP
Session, a new application module instance, therefore a new database
connection.
If you set your ping to fire every 2 seconds, you can easily imagine
the load you will produce, considering the default application module
time-to-live setting, which is one hour.

Thanks,

Florin Marcus
Red Samurai Consulting
www.redsamuraiconsulting.com

[prasad narahari]

All,

Thanks a lot for your suggestions!!

I was trying to provide the information I thought could be of use :) instead of providing nothing.

My expectation was to hear about the common steps one would take, assuming that general application specific tuning will be done by the development team.

 

For ex, Simon has pinpointed one of the few changes that I have short listed after going through the code here:

- Change the AM tuning setting to 'Lazy Loading' (Simon also recommended this)

- AM Polling and Scalability "Maximum Availability" to 150 which is close to maximum number of concurrent users that we have seen on our application

- Introduce nested AMs if needed. This would be my last resort (I am against making too many changes to the application that is already in production, but will do if absolutely needed)

- Move bucketed aggregate information to an on-demand URL rather keeping on home page (which business may not like but will be a proposal from my end)

 

There is lot of information on this subject bits and pieces every where.

I was hoping to see comments from others what they have done for their situtions earlier. Although each application is different but I believe diagnosis starts with almost same steps.

 

Pardon my typing couldnt do spell check.

 

Also, on a side note: miracles can be expected while posting to this group when you look at the kind of people we have on this group :)

Thanks

Prasad

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com

All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).  Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Brian Fry]

In addition to the other suggestions here, you may find the following white paper informative:
http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adfloadstresstesting-354067.pdf

 -- Brian

[Simon Lessard]

Hi,

Another bottleneck that I didn't mention in the previous post is the passivation itself. However, that one can be harder to circumvent if you're using the full ADF stack (read data bindings). The idea is that among your VO, some may not need to maintain any state. This is often the case if you expose a method on an AM and that method is the only one working with the VO. In such case, it's possible to prevent the VO from passivating its state, saving memory, CPU and DB bandwidth (if using DB passivation). To do that, open the VO, General tab, Tuning section, uncheck passivate state. Be wary of that one though, if the VO is used with an iterator in the data binding layer unchecking that can have dire results.

Regards,

~ Simon