[
https://issues.apache.org/jira/browse/TC-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971379#comment-15971379
]
Jeremy Mitchell commented on TC-231:
------------------------------------
Before optimization in our TO test enviro that connects to a remote postgres db:
(1) Test GET: https://to-cdn-01.test.removed.com/api/1.2/deliveryservices - 200
- (Took 99277ms)
(1) Test GET: https://to-cdn-01.test.removed.com/api/1.2/deliveryservices - 200
- (Took 108338ms)
After:
(1) Test GET: https://to-cdn-01.test.removed.com/api/1.2/deliveryservices - 200
- (Took 3270ms)
(1) Test GET: https://to-cdn-01.test.removed.com/api/1.2/deliveryservices - 200
- (Took 3379ms)
> GET /api/deliveryservices is very slow when resultset gets large
> ----------------------------------------------------------------
>
> Key: TC-231
> URL: https://issues.apache.org/jira/browse/TC-231
> Project: Traffic Control
> Issue Type: Improvement
> Components: Traffic Ops API
> Affects Versions: 2.0.0, 2.1.0
> Reporter: Jeremy Mitchell
> Assignee: Jeremy Mitchell
>
> With the change from mysql to postgres and when postgres is hosted in a
> remote environment (seperate from TO), /api/version/deliveryservices is very
> slow as the number of delivery services grows. This is because the code loops
> thru the result set and builds "example urls" for each deliveryservice. This
> operation is expensive.
> Rather than breaking the API and leaving out exampleURLs by default from the
> response, I suggest we allow the API consumer to pass thru a query parameter
> such as:
> ?exclude=exampleURLs
> UPDATE: actually, a better solution is to just optimize the underlying
> queries. This is usually solved by simply joining tables in the query. 1
> complex query involving joins is better than 500 simple queries.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
