Slow responses for package documentation

[kerscher]

When accessing pages with routes such as /:snapshot/package/:package-name and /:snapshot/docs, response times and failure rates are much higher than other pages.

For /:snapshot/docs, the difference is more than double the time it takes to access other pages.

[snoyberg]

The /:snapshot/docs should be relatively slow, it's a lot of content. I don't think we should worry about that unless further stats show it's requested a lot (which I doubt is the case).

The /package/:package-name is more concerning to me. That's a pretty database-heavy page, perhaps adding some indices to the database will speed it up.

On Wed, Nov 1, 2017 at 12:20 AM, Yghor Kerscher notifications@github.com wrote:

When accessing pages with routes such as /:snapshot/package/:package-name and /:snapshot/docs, response times and failure rates are much higher than other pages.

For /:snapshot/docs, the difference is more than double the time it takes to access other pages.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fpco/stackage-server/issues/239, or mute the thread https://github.com/notifications/unsubscribe-auth/AADBBz52QP2x6hktzGa9Axcl54oXmXrDks5sx50ugaJpZM4QNgNK .

[kerscher]

Indices added based on load testing data and correspondent handlers query usage. Besides /package/:package-name, routes using the following handlers improved, sometimes up to 30–50%:

• getPackageR
• getAllSnapshotsR
• getStackageHomeR (!!!)

The big offenders now are getPackageBadgeR and getBranchFeedR — the last one by far the biggest offender.