Discussions
Categories
- 196.8K All Categories
- 2.2K Data
- 235 Big Data Appliance
- 1.9K Data Science
- 449.9K Databases
- 221.6K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 549 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 532 SQLcl
- 4K SQL Developer Data Modeler
- 186.9K SQL & PL/SQL
- 21.3K SQL Developer
- 295.5K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.1K Development Tools
- 104 DevOps
- 3.1K QA/Testing
- 645.9K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 154 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 17 Java Essentials
- 158 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 203 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 401 LiveLabs
- 37 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.6K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 230 Portuguese
Shared Component - List of Values - slow to load on Oracle Cloud
Answers
-
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.
-
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.
-
AceSobe
Many thanks for your considered response. I thought there must be an issue somewhere.
-
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
MAGAsilly hats. -
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.
-
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.
-
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.
-
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.
-
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.
-
Thanks for pointing that out. I only have 20.2 in my ATP. Same version on-premise.
