Apigee代理性能调优

时间:2014-02-04 21:41:26

标签: apigee

是否有推荐/最佳方式为API代理的每个策略生成时间报告?

目前,我的方法是使用JS收集时间戳并计算每个策略的延迟,然后使用统计信息收集策略进行报告。

这对于性能检查而言太具有侵略性,仅我的数据收集就为整体响应增加了时间。

在分析多个请求中的数据时,报告每个步骤所花费的时间的最佳无侵入方式是什么(ui,在跟踪模式下确实显示了基于单个请求的每个策略的时间)

谢谢,

里卡多

4 个答案:

答案 0 :(得分:2)

不支持公共API来计算此信息并返回汇总的策略执行时间数据的良好,干净的响应。最好的办法是尝试使用带有request_processing_latencyresponse_processing_latency指标的Google Analytics报告。 (http://apigee.com/docs/content/analytics-reference)。然后,如果需要,使用跟踪来识别策略执行时间。

或者,您可以尝试下载跟踪会话并解析策略之间的时间戳以构建您的信息,但UI中的跟踪已经这样做了。

答案 1 :(得分:0)

您考虑使用调试API。 http://apigee.com/docs/api/debug-sessions

首先,你需要开始一个会话,例如:

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

从会话中获取信息:

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

答案 2 :(得分:0)

可以使用UI中的调试跟踪找到每个策略所花费的时间。

请参阅以下屏幕截图。

另外,Diego说你可以使用debugsession API调用来获得调试会话。

对于调试会话,您还可以定义要调试会话运行的时间的时间限制。如果您运行性能测试1小时,则可以在很长一段时间内创建调试会话。

     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

您可以从UI下载跟踪会话,该会话将包含具有每个策略的时间戳的XML

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

以上是从UI获取调试跟踪中任何策略的时间戳的示例。

答案 3 :(得分:0)

李嘉图 这是我的建议。

免责声明:这是非常细致和耗时的。只有当你真的遇到性能问题并且没有其他解决方案时,我才会推荐这种方法。

我们假设您的代理几乎没有针对外部服务和后端的服务标注的策略。

因此,总延迟将是(p1,p2,p3 ...)+服务标注目标+后端所用时间的总和。

  1. 非常第一步是将外部依赖关系存根。您可以使用空目标(Apigee边缘上的存根代理而不使用任何逻辑)来执行此操作。
  2. 现在禁用所有其他策略(对策略架构启用= false)。进行负载测试,并针对存根端点对代理性能进行基准测试。此时此政策尚未生效。
  3. 逐个开始逐个激活策略,每次都重新运行负载测试。
  4. 最后,您可以针对真实后端运行负载测试(删除存根)
  5. 在这一系列负载测试结束时,您将了解哪个策略后端正在对性能产生最显着的影响。