Apigee代理性能调整

Question

Is there a recommended/best way to generate a report for time spent on each policy for an API proxy?

Currently my approach is to use JS to collect the timestamps and calculate the delay around each policy, and then report it using the stats collection policy.

That's too invasive for performance checks and my data collection alone adds time to the overall response.

What would be the best no invasive way to report on the time taken for each step when analyzing the data across many requests (the ui, in the trace mode does show the time for each policy on an individual request basis)

Thanks,

Ricardo

Answer 1

There's not a public API supported to calculate this information and return a nice, clean response of aggregated policy execution time data. Best bet is to try using Analytics reports with request_processing_latency and response_processing_latency measures. ( http://apigee.com/docs/content/analytics-reference ). Then, if needed, utilize trace to identify policy execution times.

Alternatively, you can try downloading the trace session and parsing the timestamps between policies to build your information, but trace in UI does this already..

Answer 2

You consider using debug API. http://apigee.com/docs/api/debug-sessions

First you'll need to start a session for example:

curl -H "Content-type:application/octet-stream" -X POST https://api.enterprise.apigee.com/v1/organizations/{org}/environments/{env}/apis/{api_name}/revisions/{revision #}/debugsessions?"session=MySession" \\ -u $ae_username:$ae_password

Get info from session:

curl -X GET -H "Accept:application/json" \\ https://api.enterprise.apigee.com/v1/organizations/{org}/environments/{env}/apis/{api_name}/revisions/{revision #}/debugsessions/MySession/data \\ -u $ae_username:$ae_password

Answer 3

The time spent for each policy can be found using the debug trace in UI.

Please see the below screenshot for the same.

Also as Diego said you can use debugsession API call to get a debug session.

For the debug session you can also define the time limit as to how much time you want to debug session to run. With this if you are running your performance test for 1 hour you can create debug session for that much amount of time.

     curl -v -u jhans@apigee.com               http://management:8080/v1/organizations/weatherapi/environments/prod/apis/ForeCast/revisions/6/debugsessions?session=ab\&timeout=300 -X POST

From the UI you can download the trace session which would contain an XML having the timestamp for each policy

     <Point id="Condition">
      <DebugInfo>
        <Timestamp>05-02-14 04:38:14:088</Timestamp>
        <Properties>
            <Property name="ExpressionResult">true</Property>
      </Point>
     <Point id="StateChange">

The above is an example for getting timestamps for any policy in debug trace from UI.

Answer 4

Ricardo, here is what I suggest.

Disclaimer: It is very meticulous and time consuming. I would recommend this approach only when you are really blocked on a performance issue and there is no other solution.

Let us say your proxy has few policies a service callout to external service and a backend.

So the total latency would be Sum of time taken by (p1, p2, p3...) + service callout target + time taken by your backend.

1. Very 1st step would be to stub out the external dependencies. You can use a null target (a stub proxy on Apigee edge without any logic) to do so.
2. Now disable all other policies ( enable = false on the policy schema ). Conduct a load test and benchmark your proxy performance against stubbed endpoints. Also at this time no policies are active.
3. Start activating the policies one by one or a few at a time, and re-run the load test each time.
4. Finally you can run the load test against real backends (removing the stubs)

At the end of this series of load test you will know which policy, backend is making the most significant performance impact.