Replies: 1 comment
-
We did some testing on production and found out that the request timeout needs to be set to 3 minutes in order to accommodate the vote results endpoint on slow 3g networks. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The response times for API calls with larger payloads can be extremely slow at times. I was curious what the bottleneck is for these calls so I did a little digging.
The vote results API endpoint returns all of the cast vote data for a Decred proposal vote. The response time for a mainnet proposal with 20k-30k votes can be between 5-10 seconds.
Listed below is the response time of the vote results endpoint on test-proposals for a proposal with ~3k votes. The response payload size was ~1.4 MB.
Conclusion
The largest contributors to the slow response times are the extra database read required to fetch the trillian tree and the extra decoding that we have to do as a result of the generic data structure that is saved to the key-value store. Previous testing revealed that the response time for fetching the trillian leaves will increase ~100ms for every 10,000 additional leaves.
The politeiad backend is typically not going to be as performant as a standard web server backend because of the tradeoffs that we made in order to be able to return timestamp inclusion proofs for any individual piece of data. politeiad is going to be CPU bound on these expensive calls. The response times can be reduced by increasing the CPU resources of the politeiad server or by scaling out politeiad horizontally.
Beta Was this translation helpful? Give feedback.
All reactions