This would be the last part of the cache analysis exercise in PeopleSoft. If you are landing here directly, make sure you check out the previous parts;
Until now, we have a got a good idea of how things behave when they are not cached. We had a look at the SQLs executed by the Application Server, and also went to an extent of understanding what might have happened behind these SQLs; all setup on a simple page definition in PeopleSoft.To conclude this series, let us try to understand the whole scenario when the definitions are cached.
Not so surprisingly, the number of SQLs executed in this case is far less. A brief summary is provided below. It starts with queries against PSVERSION
SELECT VERSION FROM PSVERSION WHERE OBJECTTYPENAME = 'SYS'
SELECT OBJECTTYPENAME, VERSION FROM PSVERSION
What I interpret here is that, PeopleSoft tries to get the version information to see if something has "changed". If not, it just loads the definitions from the cache. This is also evident against each "save" event of the object definition in Application Designer, wherein the version count is incremented by 1.
After this, the only queries (specific to my scenario) that gets executed are, the queries against user personalization.
SELECT OBJNAME, FLAG, PTCUSTOMFORMAT FROM PSUSEROBJTYPE WHERE MENUNAME = :1 AND PNLGRPNAME = :2 AND PNLNAME = :3 AND OPRID = :4 AND FIELDTYPE = :5
SELECT PTCUSTOMFORMAT FROM PSUSEROBJTYPE WHERE MENUNAME = :1 AND PNLGRPNAME = :2 AND PNLNAME = :3 AND OPRID = :4 AND FIELDTYPE = :5
SELECT PTCUSTOMFORMAT FROM PSUSEROBJTYPE WHERE MENUNAME = :1 AND PNLGRPNAME = :2 AND PNLNAME = :3 AND OPRID = :4 AND FIELDTYPE = :5
The page gets loaded after this, all in a flash..In a sense, this gives a huge performance benefit to the users using the system, and also minimizes the overhead of reloading unchanged definitions from the database.
No comments:
Post a Comment