#5579 - Update SLOW_SERVER / relative performance scores
| Identifier | #5579 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Update SLOW_SERVER / relative performance scores |
| Status | Completed |
| Tags |
Roadmap: v11 (custom) |
| Handling member | PDStig |
| Addon | core |
| Description | In Composr, we have relative performance calculations against "lead developer's machine". But Chris is no longer the lead developer, and these specs are outdated.
Instead, change this system to an absolute score and use a "reference machine". Ideally, we should modify the logic / calculations to something already commonly used online so that we can then find the score of a machine whose specs closely match Composr's recommendations. But if this cannot be done, just have documentation of what different machines scored. |
| Steps to reproduce | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".


Comments
* This is calculated by processing 10,000 MD5 operations on uniqid and calculating the amount of time it takes.
* Then, based on that time, we calculate the average amount of operations that could be performed in 1 second. And this is the final score.
* For example, a score of 900,000 means the server can perform about 900,000 MD5 hashes on uniqids in one second.
Based on this new calculation, the 2014 iMac referenced in v10 would have scored about 180,000. Our warning for normative performance was set at 4%, which is about 8,000.
In v11, I think we should bump the threshold up to 25,000 as it requires more resources than v10 did. The threshold can be configured in Health Check.
I may consider raising it even higher for the default as some slow servers struggle immensely with generating cache but do fine when cache is available.
The issue though is we cross into page speed territory. This is a different metric and is already monitored separately by the Health Check. So CPU speed might need to remain as it is, based on hard calculations instead of web requests.