Re: Alternative MySQL PEAR DB sequence behavior

"Tomas V.V.Cox" wrote: > > "Stig S. Bakken" wrote: > > > > "Tomas V.V.Cox" wrote: > > > > > > "Stig S. Bakken" wrote: > > > > > > > > Looks good (but I haven't run any concurrency tests), so I'll commit > > > > it. > > > > > > > > > > We should setup a basic test to use for example "ab" (Apache Benchmark). > > > With it is easy to test concurrency problems. > > > > I think a good test would be somewhere around 50 simultaneous PHP > > requests that constantly generate sequence operations (so each request > > runs for, say, 30 seconds). > > > > I spend some time in this fun thing and done a mini test suite. This a > bash script (launch.sh) that launchs "n" php processes in background, > each of them will do "m" requests to the database. The first param is > the number of process and the second the number of request per process. > > In my tests I a good combination of both params was: ./launch.sh 100 100 > (grater values may eat your resources, be careful). > > I know that it won't launch real simultaneous request, but seems to be > near it (a better sync system is welcome :), also it doesn't provide a > method to analyze the data. Hm, right now all concurrency.php does is to check whether nextId returns an error. The race condition occurs if the "UPDATE *_seq SET id=LAST_INSERT_ID(id+1)" statement is not atomic, so that mysqld reads the current value of the table in request 1, reads the current value is request 2, and then both update the sequence with the same value, and both requests think they have gotten unique ids. If this turns out to be a problem, it would be better to leave a couple of "dupes" in the table and garbage-collect them (the same way sessions are gc'ed), or delete the previous value after a new one has been fetched. - Stig