There goes nothing then. With the tip of your GIT repo being at commit 53cb0560c7dc62558aeb11ff65d22fb13c4610ff:
| CPU (cores/threads) | Test | IPS | Duration |
|---|---|---|---|
| Xeon-2150B, 10/20 | Elixir create | 25295 | 10s |
| Xeon-2150B, 10/20 | pgbench create | 33692 | 10s |
| Xeon-2150B, 10/20 | Elixir update | 41635 | 30s |
| Xeon-2150B, 10/20 | pgbench update | 131118 | 30s |
| i7-4870HQ, 4/8 | Elixir create | 16981 | 10s |
| i7-4870HQ, 4/8 | pgbench create | 30152 | 10s |
| i7-4870HQ, 4/8 | Elixir update | 21701 | 30s |
| i7-4870HQ, 4/8 | pgbench update | 47926 | 30s |
Observations:
- Overall, most numbers are a little lower than before – interesting. Might be due to thermal throttling, especially on the MBP. But I can’t notice a significant difference overall.
pgbenchuses less CPU than Elixir which leaves more CPU for Postgres – I noticed Postgres utilising the CPU more in thepgbenchtests.
Let me gather my full feedback on the testing methodology:
- Shouldn’t use
.exsscripts, that’s less efficient (although I doubt it amounts to much). - Should use the same set of random keys used to insert/update records. It’s going to be a little more scientific and get more consistent results that way IMO.
- Should use more Elixir processes. Your observation on the numbers when going from 10 to 40 makes sense. Between processes being extremely lightweight and the DB pool limits your tests should IMO do their best to keep the Postgres DB very busy.
- Again, standardise the output of all commands. You can capture and hide
pgbench’s output and just output the IPS/TPS number.
