Forum Stats

  • 3,817,238 Users
  • 2,259,294 Discussions
  • 7,893,709 Comments

Discussions

Shared Component - List of Values - slow to load on Oracle Cloud

2

Answers

  • AceSobe
    AceSobe Member Posts: 20 Bronze Badge
    Answer ✓

    You are correct. There seems to be an an issue on Oracle Cloud right now when editing a Dynamic List of Values via Shared Components. I have the same application in an onsite server and problem does not occur. It may not be Apex related, but probably performance related within the Oracle Cloud environment.

    User_HP5NAScott Wesley
  • AceSobe
    AceSobe Member Posts: 20 Bronze Badge

    He is not blaming anyone. He is asking a question about the performance of Apex on Oracle Cloud. You may not be experiencing this but the issue is not about the code he is writing, but the performance of the environment itself. Instead of lecturing him about development abilities, you should try to understand the question.

    Scott Wesley
  • User_HP5NA
    User_HP5NA Member Posts: 7 Green Ribbon

    AceSobe

    Many thanks for your considered response. I thought there must be an issue somewhere.

    Scott Wesley
  • Billy Verreynne
    Billy Verreynne Software Engineer Member Posts: 28,807 Red Diamond
    edited Dec 12, 2020 10:29AM

    So Cloud Infrastructure is intelligent - the rain drops are like synapses firing neurons in a large neural network??

    The cloud database infrastructure identifies a SQL that happens not only to be an APEX SQL, but also a SQL specifically for building an APEX LoV. And slows this down. Only LoVs and nothing else.

    The cloud network on the other hand detects the TCP packets containing the LoV payload, and either slows these packets down, or drop them causing retransmission. Only LoVs and nothing else.

    So there you are. Your assumption that APEX LoVs are specifically slow on cloud infrastructure, validated. And in a Trumpian world of today, this is okay as stupidity and ignorance rule.

    Or you can read @fac586's posting again where he supplied a reference to Joel's comments of his experience about APEX performance issues. Who is Joel? Oracle senior development director and product manager for APEX. And understand that APEX performance is DIRECTLY a result of YOUR code and YOUR database. And not an APEX specific issue that only happens on cloud infrastructure. AS I HAVE SHOWN ABOVE.

    I used a very basic and simplistic method to isolate a performance related issue with web-based client-server. The 1st step in troubleshooting a performance issue. Subsequent steps will include looking at APEX debug traces, SQL execution plans, database session wait states and so on.

    So you have a very basic choice. Investigate your performance issue as shown, and at the same time educate yourselves and gain real world experience. Or feel abused by the truth and stark realities presented, and keep wearing them MAGA silly hats.

  • Scott Wesley
    Scott Wesley Member Posts: 6,188 Gold Crown

    Some things I would explore

    • get some peer review on the 'simple' sql statement. There could be a parsing thing going on, as validation does get performed on these queries in the form of interpreted SQL. Share it here, sanitised if necessary.
    • Try move your SQL to a view, and have the dynamic LOV query the view, and see if the problem still exists. Perhaps compile time on the view will resolve whatever parsing problems occur.
    • Is it also a problem on a truly simple query on emp-dept? I've had data dictionary performance issues on shared environments before, especially when there's a large number of applications - so I might have thought this problem would be reversed. And this has been my own usage, not the builder. That said, I find the advanced shared LOV page in apex.oracle.com a bit slower than it used to be.
    • Are there APEX version difference differences between these instances that could be at play? I heard at one point they have been working on dictionary performance.

    Sorry, Billy, I think you're off-point on this one. I'm pretty sure the OP relates to page 4000:4111, and this seems like a fair question to task, though I agree the LOV SQL should be shared.

  • User_HP5NA
    User_HP5NA Member Posts: 7 Green Ribbon

    Scott,

    An example typical query is driven off a table APPLICATION_STATUS that has and ID, NAME, DESCRIPTION and audit columns there are only 6 rows. We have similar query based LOVs that aren't any more complex with similar number of rows, i.e. less than a block of data, that are all slow to load in the APEX Developer pages. The LOVs with Static values could have 20+ rows and are instantaneous to load.

    I have been running on 20.1 both in the Cloud and hosted.

  • Billy Verreynne
    Billy Verreynne Software Engineer Member Posts: 28,807 Red Diamond

    My issue is that cloud is blamed, APEX LoV specifically, and the expectation that this should be a known issue by the APEX team, as if it is a problem they own.

    The expectation is unreasonable. Cloud and APEX LoV are symptoms of the problem. No evidence is provided that these are the actual cause.

    Elementary error analysis has not been performed. As the error occurs over a complex client-server architecture, there are a number of moving parts. Anyone if which could be contributing to the problem.

    Elementary problem definition is to isolate the error. Determine just where it occurs.

    The WHAT needs to be known of a problem before the WHY can be addressed.

    The WHAT is still unknown. Thus the error has NOT been identified. Only more unsubstantiated claims that this is an APEX LoV issue on cloud infrastructure as similar symptoms were encountered. And somehow this should be a known APEX team issue.

    Making a diagnosis as to what the problem's root cause is based on these symptoms is plainly ridiculous.

  • AceSobe
    AceSobe Member Posts: 20 Bronze Badge

    For the ones still not believing there is an issue with editing LOVs in Oracle Cloud Apex:

    Just create the following LOV:

    select 'Y' as RETURN_COLUMN,'Yes' as DISPLAY_COLUMN from dual

    After created, post your time when you want to edit the same LOV, both in Oracle Cloud vs any On-Premise Apex. My times are 40+ seconds vs 1 second. If you don't have the ability to perform this simple test, please avoid posting.

    Scott Wesley
  • jariola
    jariola Member Posts: 10,737 Silver Crown

    I'm not sure does it relate to APEX 20.2. I have ATP where is APEX 20.1, and get editing shared components LOV is fast.

    Different ATP with APEX 20.2, it takes sometime before LOV editing pages renders.

  • AceSobe
    AceSobe Member Posts: 20 Bronze Badge

    Thanks for pointing that out. I only have 20.2 in my ATP. Same version on-premise.