<font size=2 face="sans-serif">Alexei, awesome work.</font>
<br>
<br><tt><font size=2>> Rollbacks are caused not by retry logic but by
create_or_update logic:<br>
> We first try to do INSERT in sub-transaction when it fails we rollback
<br>
> this transaction and do update instead.</font></tt>
<br>
<br><tt><font size=2>if you take a look at my patch addressing deadlocks(</font></tt><a href=https://review.openstack.org/#/c/80461/><tt><font size=2 color=blue>https://review.openstack.org/#/c/80461/</font></tt></a><tt><font size=2>),
i actually added a check to get rid of the blind insert logic we had so
that should lower the number of rollbacks (except for race conditions,
which is what the function was designed for). i did some minor performance
testing as well and will add a few notes to the patch where performance
can be improved but requires a larger schema change.  Jay, please
take a look there as well if you have time.</font></tt>
<br>
<br><tt><font size=2>> Tomorrow we'll do the same tests with PostgreSQL
and MongoDB to see if <br>
> there is any difference.</font></tt>
<br>
<br><tt><font size=2>i look forward to these results, from my quick testing
with Mongo, we get about 10x the write speed vs mysql.</font></tt>
<br>
<br><tt><font size=2>> >>>>> We required a non mongo
backend to graduate ceilometer. So I don't think<br>
> >>>>> it's too much to ask that it actually works.</font></tt>
<br>
<br><tt><font size=2>i don't think sql is the recommended back in real
deployments but that said, given the modest load of tempest tests, i would
expect our sql backend be able to handle it.</font></tt>
<br>
<br><font size=2 face="sans-serif">cheers,<br>
gordon chung<br>
openstack, ibm software standards</font>