Forum Stats

  • 3,750,416 Users
  • 2,250,175 Discussions
  • 7,866,972 Comments

Discussions

ORDS on Tomcat9, slow response

Paul Jorstad
Paul Jorstad Member Posts: 67 Blue Ribbon

Hello, I have a Tomcat 9 running ORDS 19.1 (Windows 64bit). The problem is that after a while the response on the web services slows down to about 3 seconds. If I restart Tomcat, the services are fast again, 50ms typically. If I then let the system stand still a while (I guess 30mins ++), all services slows down to 3 seconds again. So - there seems to be an issue with caching or connection pooling, but not sure where to look.

Paul Jorstad

Answers

  • EJ-Egyed
    EJ-Egyed Member Posts: 125 Blue Ribbon
    edited Dec 13, 2019 9:54AM

    What are you setting as your connection pool size in your ORDS configuration directory? That is typically the biggest performance culprit if you are just using ORDS without too much configuration. In your catalina.YYYY-MM-DD.log file, are you seeing messages like the ones below during startup when your ords.war file is being deployed?  If so then you'll need to make some adjustments to your pool size.

    19-Sep-2019 14:38:34.037 WARNING [main] . *** jdbc.MaxLimit in configuration |apex|| is using a value of 10, this setting may not be sized adequately for a production environment ***

    19-Sep-2019 14:38:34.037 WARNING [main] . *** jdbc.InitialLimit in configuration |apex|| is using a value of 3, this setting may not be sized adequately for a production environment ***

    Paul Jorstad
  • Paul Jorstad
    Paul Jorstad Member Posts: 67 Blue Ribbon
    edited Dec 16, 2019 4:13AM

    Thank you for replying :-)
    I have modified some values in defaults.xml:

    <entry key="cache.caching">true</entry> <!-- changed from false to true -->

    <entry key="cache.directory">D:\temp\ords_cache</entry><!-- changed -->

    <entry key="cache.duration">days</entry>

    <entry key="cache.expiration">7</entry>

    <entry key="cache.maxEntries">500</entry>

    <entry key="cache.monitorInterval">60</entry>

    <entry key="cache.procedureNameList"/>

    <entry key="cache.type">lru</entry>

    <entry key="debug.debugger">false</entry>

    <entry key="debug.printDebugToScreen">false</entry>

    <entry key="error.keepErrorMessages">true</entry>

    <entry key="error.maxEntries">50</entry>

    <entry key="jdbc.DriverType">thin</entry>

    <entry key="jdbc.InactivityTimeout">1800</entry>

    <entry key="jdbc.InitialLimit">6</entry> <!-- changed from 3 to 6 -->

    <entry key="jdbc.MaxConnectionReuseCount">1000</entry>

    <entry key="jdbc.MaxLimit">50</entry> <!-- changed from 10 to 50 -->

    <entry key="jdbc.MaxStatementsLimit">10</entry>

    <entry key="jdbc.MinLimit">1</entry>

    <entry key="jdbc.statementTimeout">900</entry>

    <entry key="log.logging">false</entry>

    <entry key="log.maxEntries">50</entry>

    <entry key="misc.compress"/>

    <entry key="misc.defaultPage">apex</entry>

    <entry key="security.disableDefaultExclusionList">false</entry>

    <entry key="security.maxEntries">2000</entry>

    <entry key="security.requestValidationFunction">wwv_flow_epg_include_modules.authorize</entry>

    <entry key="security.validationFunctionType">plsql</entry>

    Also, I have modified the Java options so the process can use up to 1024m of memory, and the process runs now at approx 500m of memory

    Still, the response is very fast after a restart, But i slows down to 3 seconds after 30 minutes or so....

    I get this message in the catalina log, but not sure how significant that is:

    16-Dec-2019 09:19:17.843 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: [d:\apps\Tomcat9.0\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;D:\Oracle\product\19.0.0\client_1\bin;D:\apps\Java\jdk1.8.0_144\;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\ProgramData\chocolatey\bin;C:\Program Files\dotnet\;C:\Program Files (x86)\dotnet\;C:\Program Files\Microsoft\Web Platform

  • User_1P99F
    User_1P99F Member Posts: 3 Green Ribbon
    edited Aug 20, 2021 10:52AM

    Hi Paul,

    I 'm facing exactly the same issue.Have you managed to find a solution?

    Thanks

    Dimitris

  • thatJeffSmith-Oracle
    thatJeffSmith-Oracle Distinguished Product Manager Posts: 7,906 Employee

    your ORDS is 2+ years old...consider upgrading at your earliest convenience

    what happens if you take tomcat out of the picture and run ORDS standalone?

  • User_1P99F
    User_1P99F Member Posts: 3 Green Ribbon

    I 'm using ORDS 19.2 and upgrade to 21.2 is my first priority.

    I face the behavior described by Paul for both containers(Jetty & Tomcat).

  • thatJeffSmith-Oracle
    thatJeffSmith-Oracle Distinguished Product Manager Posts: 7,906 Employee

    put ords into debug mode, set logging to info/verbose, setup a test env with 21.2 and report back

  • User_1P99F
    User_1P99F Member Posts: 3 Green Ribbon

    After upgrading to ORDS 21.2 (from 19.2) ,system is up and running since Monday (for 4 days),without any restart

    on Tomcat.All this period didn;t noticed any performance issues like before.

    I would like to mention that i had similar issues on a secondary envoironment ,with ords 21.1 and apex 21.1.

    This time ,it was the response to POST Requests(ajax calls),that suffered from an around 2 seconds delay.

    After upgrading to ORDS 21.2 problem solved as well.

    In both envoironments an apex upgrade to 21.1 had taken place before ords upgrade.

    So,after upgrading apex version,perhaps i should, kind of "refresh" or something, ORDS?


    Thanks in addvance.

  • thatJeffSmith-Oracle
    thatJeffSmith-Oracle Distinguished Product Manager Posts: 7,906 Employee

    You should keep your ORDS up to date as much as possible - we put a huge priority on performance and security, you don't want to miss out on those.

    User_0MDVC