The StoriesController#index and StoriesController#show endpoints are sort of re-used for multiple types of pages because we use top level routing in the controller, so dev.to/:user and dev.to/:organization for example, share a controller action. I'm not sure what the right way to do this but it makes the Skylight dashboards a bit more complicated.
Any PRs to effectively refactor this stuff is welcome. @lightalloy
you did some work here, but we never really touched on this elements. Feel free to give it some thought.
There's plenty we can do to modify and tune performance outside of the context of Skylight, so anyone outside the absolute core team will not get the whole picture, but we will be trying to offer more dashboards in the future, to really open things up. But we will be doing so conservatively, with a very strong bias towards principles of least privilege until we feel like it's better to have certain things totally in the open.
Ben, thanks for mentioning me.
I still think that the StoriesController has too many responsibilities, and they should be separated for better maintainability and profiling.
I've worked on separating views to start with, but that's only a small part of the task.
I would love to continue work on the refactoring, but I suppose that's not the top priority right now. I'll return to this issue when it's possible, or I can help if there are other contributors who want to work on it.
I suppose it's possible to separate those routes using route constraints.
I saw StoriesController#show in drilled down , it seems
SELECT FROM articles
This query is getting hit multiple times (4 times, 2 with multiple parameters and 2 times with same parameters) in single request. (as you said, this might be due to using same endpoints for multiple routing)
Still average response time is better than Comment query with 2 calls and taking 171 ms average. (Definitely area for improvement compared to above)
Overall very interesting insights. It will be interesting to see details on what benchmarks (SLA) you would create to further enhance the app
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A few more specific things to note:
The
StoriesController#indexandStoriesController#showendpoints are sort of re-used for multiple types of pages because we use top level routing in the controller, sodev.to/:useranddev.to/:organizationfor example, share a controller action. I'm not sure what the right way to do this but it makes the Skylight dashboards a bit more complicated.Any PRs to effectively refactor this stuff is welcome. @lightalloy you did some work here, but we never really touched on this elements. Feel free to give it some thought.
There's plenty we can do to modify and tune performance outside of the context of Skylight, so anyone outside the absolute core team will not get the whole picture, but we will be trying to offer more dashboards in the future, to really open things up. But we will be doing so conservatively, with a very strong bias towards principles of least privilege until we feel like it's better to have certain things totally in the open.
Ben, thanks for mentioning me.
I still think that the
StoriesControllerhas too many responsibilities, and they should be separated for better maintainability and profiling.I've worked on separating views to start with, but that's only a small part of the task.
I would love to continue work on the refactoring, but I suppose that's not the top priority right now. I'll return to this issue when it's possible, or I can help if there are other contributors who want to work on it.
I suppose it's possible to separate those routes using route constraints.
I saw
StoriesController#showin drilled down , it seemsSELECT FROM articlesThis query is getting hit multiple times (4 times, 2 with multiple parameters and 2 times with same parameters) in single request. (as you said, this might be due to using same endpoints for multiple routing)
Still average response time is better than
Commentquery with 2 calls and taking 171 ms average. (Definitely area for improvement compared to above)Overall very interesting insights. It will be interesting to see details on what benchmarks (SLA) you would create to further enhance the app