5 Replies Latest reply on Jun 20, 2016 5:47 PM by e.*181572*en

    mod_plsql to ORDS 3.0.5 significant performance degradation


      Thanks to good old mod_plsql being dropped in OHS 12.2.1, which is needed for newer "strong" cipher suites, I was forced to try ORDS as a replacement.   I had tried APEX Listener 1.1 before which was fine for APEX (very minor degradation), but not for PL/SQL Web Toolkit applications.   ORDS 3.0 added the missing functions such as multiple DADS and security authorization verification function.  The configuration consistency and debugging are not mature, but it can be made to functional work.  The URL mapping documentation is totally wrong, old APEX REST is best left disabled, and defaults.xml parameters are really for all "DADS" unless they start with jdbc or db.   So I thought the worse was over just getting it to work.   Then came performance testing.   It ranges from 6 to 10 times worse.   Pages taking 0.5 to 1.5 seconds now run about 3.5 to 7 seconds. Yes it is less than 10 seconds, but a very noticeable degradation to end users (even enterprise SSO is faster).   Tracing down the degradation, wwv_flow_file_mgr.get_file and APEX ajax calls are the biggest offenders.   With work, I could move the image files to Apache directories, but I cannot move ajax calls.  I also isolated that it is NOT the interface between OHS and WebLogic and NOT WebLogic.   The same issue occurs with direct access to the standalone ORDS.   I made sure there were 3+ simultaneous database connections that were not disconnecting.   I also setup the ORDS caching which is generating cache files, but no help.  So it is something with how ORDS and JDBC interface.   Very disappointing.


      I am going to reverse proxy OHS 12.2.1 (front-end with TLS 1.2 and strong encryption) to OHS 11.1.1.x with mod_plsql (much faster) until ORDS matures and performs better.   OHS 11g is supported until Dec. 2018.


      Any ideas what is wrong with ORDS 3.0.5?   Others have mentioned a performance degradation from 2.0.x

        • 1. Re: mod_plsql to ORDS 3.0.5 significant performance degradation

          to achieve stronger cipher suites you can terminate your TLS at vanilla Apache and recede proxy back to OHS you don't need to reverse different versions of OHS to OHS.


          APex just sits on top of OWA. you say you have performance issues, it would be nice to get a breakdown of modPLSQL and ORDS can you provide a timeline from chrome Dev tools in both cases please?

          • 2. Re: mod_plsql to ORDS 3.0.5 significant performance degradation

            Thanks.  Yes, it was 50/50 whether to user OHS 12.2.1 or vanilla Apache 2.4, but I have to configure Oracle Fusion Middleware 12.2.1 anyway for BI Publisher. 


            I cannot paste in the Chrome inspect Network images, but here are some exact numbers:


            Simple web page with some small images and one form checkbox:   422ms via mod_plsql  and 3.41s via ORDS


            Four ajax calls via radio button click:  625ms via mod_plsql and 6.54s via ORDS  (the final straw on ORDS)


            I am seeing that calls via ORDS are doing extra logons/logoffs to APEX_REST_PUBLIC_USER which correspond with the number of get_files and ajax calls.  Mod_plsql only uses the pooled APEX_PUBLIC_USER connections which ORDS uses only partially for each web page.  This is despite having APEX rest services turned off (partly because APEX did not work otherwise and partly because I don't need it for backward compatibility purposes).    Seems like the configuration needs to mature some.  The extra connects/disconnects are a performance killer.





            • 3. Re: mod_plsql to ORDS 3.0.5 significant performance degradation



              Ok, so a vanilla hello world application works fine and is even faster than mod-plsql - thats good.


              Now, what is strange and maybe I do not fully get your set up; ORDS from an OWA perspective  (not rest services) but purely from mod-plsql migration to ORDS only requires one schema account and thats the APEX_PUBLIC_USER.


              in your example you are mentioning APEX_REST_PUBLIC_USER - in your mod-plsql application where are you using this schema, if you are not then you have set up differently. You can make an AJAX request to the APEX_PUBLIC_USER. Ajax is a client concept, the server side does not care this was an AJAX request.


              your example says mod-plsql uses the pooled APEX_PUBLIC_USER account, ORDS can do the exact same. Compare the exact URL request in mod-plsql and ORDS they should be the exact same, I fail to understand how you have set up your environment and ORDS is now using a different schema and as you say is using two schema's; seems its your set up is slightly wrong.


              I am migrating a very large application (15million lines of code + ) from mod-plsql to ORDS and I do not have the issue you mentioned.

              • 4. Re: mod_plsql to ORDS 3.0.5 significant performance degradation



                I have PL/SQL Web Toolkit applications too so I need multiple users, APEX_PUBLIC_USER and other schemas not related to APEX or ORDS.   For APEX purposes, I only need APEX_PUBLIC_USER as done via mod_plsql  ORDS is for some reason deciding to do multiple connections to APEX_REST_PUBLIC_USER per APEX web page (not by my choice) in addition to initially using the pooled APEX_PUBLIC _USER connections which is causing the performance problems.  A few other users are reporting performance problems too that worked fine with APEX Listener 2.x.   REST is disable in ORDS and in my workspace.   #WORKSPACE_IMAGES# URLS and ajax calls via dynamic actions appear to be causing the extra connects/disconnnects to APEX_REST_PUBLIC_USER.  

                • 5. Re: mod_plsql to ORDS 3.0.5 significant performance degradation

                  P.S.  My PL/SQL Web Toolkit applications are performing very well so the problem is limited to APEX.   That is good news for anyone with just PL/SQL Web Toolkit usage.