fimphiu-bythepoolside · module pool session #401 request database ps_txn state passivated session...

26.11.14

1

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

By the Poolside Oracle ADF Business Components Applica5on Module Pooling Explained

Frank Nimphius Senior Principal Product Manager Mobility and Development Tools November, 2014

By the poolside: ADF ApplicaMon Module Pooling Explained

2


Program Agenda

1

2

3

4

5

Ready to dive?

Swimming 101: Basic seSngs

GeSng out of the pool: AcMvaMon and passivaMon

Cleaning the pool

For a great pool party…

By the poolside: ADF ApplicaMon Module Pooling Explained 3 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Ready to dive?

By the poolside: ADF ApplicaMon Module Pooling Explained 4


Web ApplicaMons Are Stateless, Really? A common misconcep5on

•  The HTTP protocol is stateless •  State management in standard JEE web apps

– Client side (HTML hidden tag; viewstate) – Server side (ApplicaMon, Session)


ApplicaMon Modules A reminder

•  Expose View Objects to the view layer • Define master-‐detail relaMonships between View Objects via Links •  Expose client interface methods • Manage transacMons against a data source • Manage session state


26.11.14

2


ApplicaMon Modules Impact on scalability


What Is a Pool? In computer science terms

•  A shared resource cache •  Objects, threads, connecMons, memory •  Advantages

–  PreiniMalized –  Standard configuraMon –  Resources are reusable –  Scale beyond limited resources



The ApplicaMon Module Pool

•  Provides sessions ability to maintain VOs, EOs and their state •  Exploits session “idle Mme” to reuse AMs for other sessions

–  Reduces the number of objects created –  Shares a limited amount of memory between sessions

•  Saves AM/VO/EO state to the database as a temporary store –  PassivaMon and acMvaMon

•  References to AMs in the pool are for root AMs


Swimming 101: Basic seSngs


Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | By the poolside: ADF ApplicaMon Module Pooling Explained 11 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | By the poolside: ADF ApplicaMon Module Pooling Explained 12

26.11.14

3


ConnecMons • AMs use connecMons to allow VOs/EOs to perform queries/DML/transacMons

• Oracle recommends JDBC Data Sources over JDBC URLs – Select “JDBC DataSource” – Specify the JNDI lookup for the DataSource

•  Implies the WLS ConnecMon Pool is used, not ADF BC managed ConnecMon Pool


Enable ApplicaMon Module Pooling •  jbo.ampool.doampooling • Turns on AM pooling mechanism

•  “Enable Application Module Pooling” must be turned on (the default) for production systems

• Oracle will not support your application otherwise



SeSng Names


jbo.ampool.initpoolsize jbo.ampool.maxpoolsize jbo.recyclethreshold jbo.ampool.minavailablesize jbo.ampool.maxavalablesize jbo.ampool.maxinactiveage jbo.ampool.monitorsleepinterval jbo.dofailover jbo.doconnectionpooling jbo.ampool.dynamicjdbccredentials jbo.ampool.resetnontransactionalstate jbo.ampool.doampooling



jbo.ampool.initpoolsize jbo.ampool.maxpoolsize jbo.recyclethreshold jbo.ampool.minavailablesize jbo.ampool.maxavalablesize jbo.ampool.maxinactiveage jbo.ampool.monitorsleepinterval jbo.dofailover jbo.doconnectionpooling jbo.ampool.dynamicjdbccredentials jbo.ampool.resetnontransactionalstate jbo.ampool.doampooling


jbo.ampool.initpoolsize jbo.ampool.maxpoolsize jbo.recyclethreshold jbo.ampool.minavailablesize jbo.ampool.maxavalablesize jbo.ampool.maxinactiveage jbo.ampool.monitorsleepinterval jbo.dofailover jbo.doconnectionpooling jbo.ampool.dynamicjdbccredentials jbo.ampool.resetnontransactionalstate jbo.ampool.doampooling jbo.ampool.timetolive jbo.ampool.disconnect_level


26.11.14

4


AM Pooling Parameters


Pool Size Pool Performance Pool Cleanup AM Behaviour

19 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |




•  IniMal Pool Size jbo.ampool.initpoolsize • Maximum Pool Size jbo.ampool.maxpoolsize

20


jbo.ampool.initpoolsize jbo.ampool.maxpoolsize jbo.recyclethreshold jbo.ampool.minavailablesize jbo.ampool.maxavalablesize jbo.ampool.maxinactiveage jbo.ampool.monitorsleepinterval jbo.dofailover jbo.doconnectionpooling jbo.ampool.dynamicjdbccredentials jbo.ampool.resetnontransactionalstate jbo.ampool.doampooling jbo.ampool.timetolive jbo.ampool.connection_threshold


jbo.ampool.initpoolsize

•  a.k.a. IniMal Pool Size – default 0 •  On applicaMon starMng

–  “Primes” AMs before they’re needed •  Does not control the minimum number of AM instances

– A pool monitor sweep could reduce to zero



jbo.ampool.maxpoolsize

•  a.k.a. Maximum Pool Size – default 4096 •  Maximum amount of AM instances that can be created in the pool •  Generally we leave this at the default as it is rarely reached


0

100

200

300

400

Application Module Pool


26.11.14

5


0

100

200

300

400

Minimum AMs = 0 Application

Module Pool


0

100

200

300

400 Maximum AMs = 400


Module Pool



0

100

200

300

400 Maximum AMs = 400


Module Pool


0

100

200

300

400




0

100

200

300

400

Session #1 Request



0

100

200

300

400

AM #1 Instantiated

Session #1 Request



26.11.14

6


0

100

200

300

400

AM #1 Unavailable

Session #1 Request


Session #1 Response


0

100

200

300

400


AM #1 Idle



0

100

200

300

400

AM #1 Unavailable

Session #1 Request



0

100

200

300

400

AM #1 Unavailable

Session #1 Response Session #1 Request




0

100

200

300

400


AM #1 Idle


0

100

200

300

400




26.11.14

7


0

100

200

300

400




0

100

200

300

400





0

100

200

300

400



0

100

200

300

400





0

100

200

300

400



0

100

200

300

400




26.11.14

8


0

100

200

300

400



0

100

200

300

400





0

100

200

300

400



0

100

200

300

400





0

100

200

300

400



0

100

200

300

400


Session #401 Request


26.11.14

9


0

100

200

300

400


Session #401 Request ?!


0

100

200

300

400


Session #401 Request Session #400 AM

State Passivated



0

100

200

300

400



Database

ps_txn

State Passivated

Session #400 AM


0

100

200

300

400



Database

ps_txn

State Passivated

Session #400 AM Session

#400 AM



0

100

200

300

400



Database

ps_txn

#400 AM Available

Session #400 AM


0

100

200

300

400



Database

ps_txn

#400 AM Unavailable

Session #400 AM


26.11.14

10


0

100

200

300

400



Database

ps_txn

Session #401 Response Session

#400 AM


0

100

200

300

400


Database

ps_txn Session #400 AM



0

100

200

300

400



Database



0

100

200

300

400


Database




0

100

200

300

400



Database



0

100

200

300

400


Database



26.11.14

11


0

100

200

300

400



Database



0

100

200

300

400


Database




0

100

200

300

400


Database

ps_txn Session #400 Request

Session #400 AM


0

100

200

300

400


Database


State Passivated

Session #401 AM Session

#400 AM



0

100

200

300

400


Database


State Passivated

Session #401 AM

Session #401 AM

Session #400 AM


0

100

200

300

400


Database


Session #401 AM

Session #400 AM

#400 AM Available


26.11.14

12


0

100

200

300

400


Database


Session #401 AM

Session #400 AM

#400 AM Available

State Activated

Session #400 AM


0

100

200

300

400


Database


Session #401 AM

Session #400 AM

#400 AM Available

State Activated

Session #400 AM



0

100

200

300

400


Database


Session #401 AM

#400 AM Unavailable

State Activated

Session #400 AM

Session #400 Response


0

100

200

300

400


Database

ps_txn

Session #401 AM



0

100

200

300

400


Database

ps_txn

Only ¼ of sessions are “active”

Session #401 AM


0

100

200

300

400


Database

ps_txn

¾ of sessions are “idle”

Session #401 AM


26.11.14

13





• Referenced Pool Size jbo.recyclethreshold

73 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

jbo.recyclethreshold •  a.k.a. Referenced Pool Size – default 10 • Most acMve AMs are pinned to memory

– Referred to as “Session Affinity” – As memory is faster, increases through put for those users

• Also pins database connecMons and reuses the relaMng JDBC prepared statement cache resulMng in faster responses

• Once we hit the “threshold” less acMve sessions are passivated – Making room for more acMve sessions



0

100

200

300

400


Database

ps_txn


0

100

200

300

400


Database

ps_txn

jbo.recyclethreshold=200




0

100

200

300

400


Database

ps_txn




0

100

200

300

400


Database

ps_txn



26.11.14

14



0

100

200

300

400


Database

ps_txn




0

100

200

300

400


Database

ps_txn





0

100

200

300

400


Database

ps_txn


0

100

200

300

400


Database

ps_txn




0

100

200

300

400


Database

ps_txn



0

100

200

300

400


Database

ps_txn



26.11.14

15


0

100

200

300

400


Database

ps_txn



0

100

200

300

400


Database

ps_txn





0

100

200

300

400


Database

ps_txn




0

100

200

300

400


Database

ps_txn





0

100

200

300

400


Database

ps_txn



0

100

200

300

400


Database

ps_txn




26.11.14

16


0

100

200

300

400


Database

ps_txn



Least Recently Used AM#16


0

100

200

300

400


Database

ps_txn



Session #16 AM

Session #16 AM

State Passivated




0

100

200

300

400


Database

ps_txn



Session #16 AM

#16 AM Available


0

100

200

300

400


Database

ps_txn


Session #201 Request Session #16 AM

#16 AM Available



0

100

200

300

400


Database

ps_txn


Session #16 AM Session #201 Response



0

100

200

300

400


Database

ps_txn


Session #16 AM


26.11.14

17


0

100

200

300

400


Database

ps_txn


Session #16 AM



0

100

200

300

400


Database

ps_txn


Session #16 AM




0

100

200

300

400


Database

ps_txn


Session #16 AM



0

100

200

300

400


Database

ps_txn


Session #16 AM




0

100

200

300

400


Database

ps_txn


Session #16 AM




0

100

200

300

400


Database

ps_txn


Session #16 AM


Session #46 AM

State Passivated

Session #46 AM



26.11.14

18


0

100

200

300

400


Database

ps_txn


Session #16 AM


Session #46 AM

#46 AM Available


0

100

200

300

400


Database

ps_txn


Session #16 AM


Session #46 AM

#46 AM Available



0

100

200

300

400


Database

ps_txn


Session #16 AM


Session #46 AM

#46 AM Available


0

100

200

300

400


Database

ps_txn


Session #16 AM

Session #46 AM




0

100

200

300

400


Database

ps_txn


Session #16 AM

Session #46 AM


0

100

200

300

400


Database

ps_txn


Session #16 AM

Session #46 AM

200 active sessions kept in memory


26.11.14

19


0

100

200

300

400


Database

ps_txn


Session #16 AM

Session #46 AM

Less active sessions kept

out until needed


0

100

200

300

400


Database

ps_txn


Session #16 AM

Session #46 AM

Memory saved



0

100

200

300

400


Database

ps_txn


Session #16 AM

Session #46 AM

Theoretical maximum users


GeSng out of the pool: AcMvaMon and passivaMon



ApplicaMon Modules Possible states

• Available – Ready for use

• Unavailable – Processing – Currently checked out to a servlet thread

• Referenced – Processing complete – Checked into pool – Pinned for a future session request


ApplicaMon Modules Lifecycle

New session, request received

No

Yes Is there an available

AM in the pool?

Is the pool below the threshold?

Yes Instantiate an AM,

AM = Available

Checkout AM, AM = Unavailable

No

Continuing processing the

request/response

To be defined


26.11.14

20


ApplicaMon Modules Lifecycle

New session, request received

No

Yes Is there an available

AM in the pool?

Is the pool below the threshold?

Yes Instantiate an AM,

AM = Available

Checkout AM, AM = Unavailable

No

Continuing processing the

request/response

Passivation?


PassivaMon When does it happen?

•  If a request from a new session is received… • … And total AMs >= jbo.recyclethreshold … • … And all the AMs in the pool are in the referenced state

– The more LRU “referenced” AM is a candidate for passivaMon



PassivaMon What is it?

• ADF persists the AM state to a store •  Steps

1.  Retrieve all state associated to the AM instance 2.  Convert the state into XML 3.  Write the XML to the persistence store 4.  (CondiMonally) Mark AM as available

•  AcMvaMon reverses the process –  PassivaMon record in persistence store cleared


PassivaMon What is persisted?

•  TransacMonal -‐ new, modified and deleted enMMes •  Non-‐transacMonal -‐ for each acMve view object

–  Current row indicator –  New rows and their posiMon –  ViewCriteria and parameters –  Flag indicaMng whether the row set had been executed –  Range start and size –  Access mode –  Fetch mode and size –  Any view object custom data –  Transient view object arributes (if configured to do so) –  Select, from, where and order by clauses (if created dynamically)



PassivaMon Persistence store op5ons

•  File – Faster, since no DB roundtrip involved – More suitable for single node deployments without failover

• Database – Slower, since requires DB roundtrip – Standard seSng is to use the AM connecMon – AutomaMcally creates and uses the ps_txn table and the ps_txn_seq sequence – Recommended approach to support failover in a cluster


PassivaMon Performance impact

• AcMvaMon / PassivaMon enhances applicaMon scalability but… •  I/O overhead impacts average session throughput

– The most acMve sessions are not impacted – Performance will degrade if the referenced pool is too small

• High number of check ins / check outs indicates either – Heavy load – Inadequate value for jbo.recyclethreshold


26.11.14

21


Cleaning the pool


Maxpoolsize vs recyclethreshold

•  jbo.ampool.maxpoolsize can be set above jbo.recyclethreshold • Useful for heavy load scenarios • Pool will instanMate new AMs unMl

–  jbo.ampool.maxpoolsize is reached – Or the server runs out of memory – Or an AM is checked into the pool as referenced or available – Or user sessions end or Mme out



Maxpoolsize vs recyclethreshold In other words…

if (all AMs up to the threshold are currently unavailable) then allocateAMAboveThreshold else passivateAnAMAndUseSpaceBelowRecycleThreshold endif;





• Pool Polling Interval jbo.ampool.monitorsleepinterval •  Idle Instance Timeout jbo.ampool.maxinacMveage • Maximum Instance Time to Live jbo.ampool.Mmetolive • Maximum Available Size jbo.ampool.maxavailablesize • Minimum Available Size jbo.ampool.minavailablesize

124


jbo.ampool.monitorsleepinterval a.k.a. Pooling Interval • default: 600 seconds (600000 ms) • Defines how osen to sweep the AM pool to reclaim AMs • Designed to shrink the pool to either:

– jbo.ampool.minavailablesize under light load – jbo.ampool.maxavailablesize under heavy load

•  Implements 2 strategies in reclaiming AMs relaMng to – jbo.ampool.maxinacMveage – jbo.ampool.Mmetolive


jbo.ampool.maxinacMveage

• AMs are reclaimed when: – They have been idle/unused greater than jbo.ampool.maxinacMveage – Default: 600 seconds (600000 ms) – But not less than total number of AMs = jbo.ampool.maxavailablesize

•  If system is under heavy load

– But not less than total number of AMs = jbo.ampool.minavailablesize •  If system is under light load


26.11.14

22


jbo.ampool.Mmetolive

• Or AMs are reclaimed when: – They have been idle/unused greater than jbo.ampool.Mmetolive – Default: 60 minutes (3600000 ms) – Regardless if total number of AMs is <= jbo.ampool.minavailablesize

• RecommendaMon: – Set to -‐1 (turns the feature off)





•  Enable ApplicaMon Module Pooling jbo.ampool.doampooling

•  Failover TransacMon State Upon Managed Release jbo.dofailover

•  Disconnect ApplicaMon Module Upon Release jbo.doconnecMonpooling

•  Reset Non-‐TransacMon State Upon Managed Release jbo.ampool.resetnontransacMonalstate

•  (Disconnect Level) jbo.ampool.disconnect_level

128


For a great poolside party…


Our advice

• Never keep the default seSngs for the AM Pool • Choose iniMal values that make sense

– According to past and/or projected usage parerns – Take CPU and memory resources into account

• Always have a lifeguard on hand – Be proacMve and monitor your producMon applicaMons – Tweak the seSngs accordingly



Dive deeper A 2h ADF Insider series – by Chris Muir


bit.ly/bythepoolside Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

Treffen der Deutschen ADF Community Warum Ø  Neuigkeiten zu Oracle ADF erfahren Ø  Mit Product Managern und Experten sprechen Ø  Networking, Austausch Ø  und Mitgestalten

Wo Raum Kopenhagen

Wann Mirwoch, 19. Nov., 17.00 – 17.45 Uhr

fimphiu-bythepoolside · module pool session #401 request database ps_txn state passivated session...

Documents