Обсуждение: [GSoC] Summery of pg performance farm
Hello monters and hackers,
This is a late summary of pg performance farm in gsoc. Although it is not yet perfect, but it has began to take shape.
1. The implementation of the basic test results upload interface to ensure that the upload operation for the atomic level (including different client numbers in different modes (rw, ro) corresponding to the results of the value).
2. Implementation of the data report related to the list page. Compare each metrics whith the previous results. If any of the metrics are a 5% improvement( or regression), there is one aspect that is progressive (or regressive). This means there may be aspects of "improvement", "regression" and "status quo" in one test result.This is the report List page for an example: http://140.211.168.111/#/machineInfo/pmJEjJjSk3WREM3Q
3.The details page of the test report is implemented. The test results in the "read only" and "read & write" mode of this report are detailed in this page, as well as the link of previous report and other details.
Here is an example: http://140.211.168.111/#/detailInfo/KScN58FCUWRD2fuC2R7VeY
4. A simple user center was implemented to allow users to browse the owning machine and apply for a new machine (I originally planned to access the community's user information interface at logon verification, but this seems to require some waiting...So this part is temporarily not present.)
5. Implement the action of approvaling machine and sending notification email in django admin.
We plan to add some useful features and write test cases to pg performance farm in the future. If anyone has any good ideas or opinions. Please feel free to email my mentors and me. And You are also welcome to leave a message on this issue page: https://github.com/PGPerfFarm/pgperffarm/issues
Best Regards,
Hongyuan Ma
On 2018-Aug-19, Hongyuan Ma wrote: > Hello monters and hackers, Is that "monsters" or "mentors"? > 2. Implementation of the data report related to the list page. Compare each > metrics whith the previous results. If any of the metrics are a 5% > improvement( or regression), there is one aspect that is progressive (or > regressive). This means there may be aspects of "improvement", "regression" > and "status quo" in one test result.This is the report List page for an > example: http://140.211.168.111/#/machineInfo/pmJEjJjSk3WREM3Q Great stuff! I think the visualization that many had in mind was that the numbers would be displayed in charts there time is the horizontal axis, and the numerical performance result number is the other axis. That way, we can see how the results go up or down with commits. Individual happy/sad faces for individual commits are not enough to see the bigger picture. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Aug 19, 2018 at 12:20:37PM -0300, Alvaro Herrera wrote: > On 2018-Aug-19, Hongyuan Ma wrote: > > 2. Implementation of the data report related to the list page. Compare each > > metrics whith the previous results. If any of the metrics are a 5% > > improvement( or regression), there is one aspect that is progressive (or > > regressive). This means there may be aspects of "improvement", "regression" > > and "status quo" in one test result.This is the report List page for an > > example: http://140.211.168.111/#/machineInfo/pmJEjJjSk3WREM3Q > > Great stuff! > > I think the visualization that many had in mind was that the numbers > would be displayed in charts there time is the horizontal axis, and the > numerical performance result number is the other axis. That way, we > can see how the results go up or down with commits. > > Individual happy/sad faces for individual commits are not enough to see > the bigger picture. I advised Hongyuan to try something simple here at first. My initial thought was a quick indicator (to not take up too much space on the screen) and to drill down into the individual plant specifics to view more details of history. pgbench is running read-only and read-write tests with scale factors at 10, 1 x memory, and 2 x memory. We could reduce the variations of the tests if folks feel that would make more sense. I thought the current number of variations might be too many things to trend on this page, but we can change that. Regards, Mark -- Mark Wong http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, RemoteDBA, Training & Services