Ubiquity-workerman (incredible) results in last run #5118
Comments
|
Well Kumbia-Workerman will be faster :) jeje |
|
We will check #5122 results in the next run in the plain Workerma with Mysqli. |
|
So there was a problem in the Ubiquity-workerman tests, not revealed by the initial test phase, nor by the logs in the last run. To confirm that, I made a script checking that the number of Db queries executed, and that the number of rows read on the server side corresponds to the executed code, at a given concurrency level.
For Mysql, my script looks like this: class QueriesCheck {
/**
* @var Database
*/
private $db;
public function __construct($dbOffset='default'){
$this->db=Database::start($dbOffset);
}
public function run($url,$concurrency=512,$count=15000,$expectedQueries=15000,$expectedRows=15000):void{
$queries=$this->getQueries();
$rows=$this->getRows();
$this->resetCache();
\passthru("ab -c $concurrency -n $count $url");
$queries=$this->getQueries()-$queries;
$rows=$this->getRows()-$rows;
$message="queries: $queries/$expectedQueries, rows: $rows/$expectedRows";
if($rows<$expectedRows || $queries<$expectedQueries){
throw new \RuntimeException("Problem: ".$message);
}
echo $message;
}
public function getQueries():int{
return $this->db->queryColumn("Show session status like 'Queries';",1);
}
public function getRows():int{
return $this->db->queryColumn("show session status like 'Innodb_rows_read';",1);
}
public function resetCache():void{
$this->db->query('RESET QUERY CACHE;');
}
}
(new QueriesCheck())->run($argv[1],$argv[2]??512,$argv[3]??15000,$argv[4]??15000,$argv[5]??15000);It would be nice if Techempower had a Python equivalent for checking our tests. |
|
It's difficult as the benchmark is by time, but it can be done |
|
I find more information, that normally the bench don't check. Workerman MysqlUbiquity-workerman with MysqliThe sockets errors are never show like errors. Comparison db with 512 concurrent.
What we see:
The results are completely different from wrk and what we see. |
|
On the run of the 2019-09-23 where Ubiquity-workerman generated socket errors, The results showed that these errors were present:
|
I'm not talking about doing this check during the benchmark, but beforehand, when using the In the We then check that the number of queries and the number of lines read from the DB is at least |
|
The visualize only show the >300 errors, never the socket errors. If show the socket errors it will be always present for any framework. I hope that it will be present the socket errors, not only the errors from the language or server. |
|
You have the wrong Run, between your table (run of 2019-09-23) And the results table you showed (run of 2019-10-01) The results of the 2019-09-23 run are in line with the expectations: And this is also the case for the 2019-10-01 run; wrk for the run 2019-10-01 Db/queryDisplayed as
|
|
Yes, my fault. (Monday !!) |
I wish that were true,
The
Ubiquity-workermancouple would be the fastest on the Multiple queries test (see 42f65a64-69b2-400d-b24e-20ecec9848bc).Ubiquity is fast, and so is Workerman. But it seems more than unlikely that the workerman-raw version will be slower than the one associated with a Framework (even if Ubiquity uses Mysqli, and workerman PDO), and this is not the only point of comparison that can raise suspicion...
I didn't see anything suspicious in the query raw file.
The logs just indicate an error that occurred on 1 worker
I'll try to investigate this on my side...
The text was updated successfully, but these errors were encountered: