3 Replies Latest reply on Sep 12, 2017 12:29 PM by thatJeffSmith-Oracle

    Tracing and Performance Tuning with Tomcat/ORDS

    Rumburak 9000

      Hi,

       

      we created some RESTful Services (Apex): GET, POST (Blobs) etc... the performance is (very) much slower than a direct sql/plsql via jdbc Connection from the application. How can we measure where the bottleneck is? Beginning at the http-call, how much time was spent in tomcat, in ORDS, in database? Also I need a best practice/Tuning Guide for configuring tomat/ords.

      Bye,
      Jens

        • 1. Re: Tracing and Performance Tuning with Tomcat/ORDS
          thatJeffSmith-Oracle

          I would start by putting ORDS into debug mode - this will cause much more info to be collected, so it will be easier to see what's happening. It'll add overhead, but it should be worth it.

           

          Then you can consult the catalina logs.

           

          Is the performance issue just limited to your service with the BLOBs? How big are they?

          • 2. Re: Tracing and Performance Tuning with Tomcat/ORDS
            Rumburak 9000

            No, not only the blobs, some simple sql-queries too. The BLOB size differs from 1MB to 300 MB(!) - The Database is a joke (1,5 GB SGA in a VM). The App developers (c#) did some tests in parallel. The performance of the calls is varying. When they did their high pressure tests, I could not recognize any waiting sessions in the database, so my first question was: "Please tell me, WHERE you measured the bad performance before saying, the database is slow."

             

            The App-Development decided to use RESTful-Services with ORDS (and tomcat). But now they tend to use the direct database connection, without analyzing where they have their bottleneck.

             

            I will try it with the debugging mode. Thank you!

            • 3. Re: Tracing and Performance Tuning with Tomcat/ORDS
              thatJeffSmith-Oracle

              Also check your version of ORDS. There are some significant performance enhancements included in 3.0.10 for large pagesizes...so if you were returning 10k rows in a single GET, that would be faster.

               

              And we have even more perf improvements in our current Early Adopter (Beta), version 17.3.

               

              For the high pressure tests, it could have simply been the jdbc connection pool was overwhelmed at the default settings.