Hi again, On 9/27/05, Lefteris Tsintjelis <[EMAIL PROTECTED]> wrote: > > John McCaskey wrote: > > Hi, > > > > I think I can shed a bit of light on the topic. There are several > reasons > > why your multithreaded code is not a good example and would be slower. > > > > 1) locking/unlocking mutexes of course does add *some* overhead > > *lots* would probably be a better choice here! :)
Well, it certainly depends on how much lock contention there is. In a well designed multi-threaded app you want to minimize the lock contention so that it will be minimal. In your example lock contention is very heavy, so in that case *lots* may be a better word! > 2) you have a single database connection and are passing it around between > > threads thus serializing the actual queries, as such the queries are not > > multithreaded at all and your code is kind of a silly use of threading > -- > > this combined with #1 above naturally does make your threaded code > slower > > But this is what I had in mind though. I wanted to be that way instead of > opening multi threaded connections but, from the looks of it, I guess you > are right and its not really worth the trouble. I have read somewhere that > opening a few connections can be slower but I guess that was probably > wrong. Ok, I can understand why you would have it in mind, but it's going to be a bad idea. Opening multiple connections will of course add some overhead, but its a different kind. What you have to ask yourself is whether the queries you are running in seperate threads are capable of being run in parallel server side. If so then opening multiple threads will be a performance win. If the queries you are running will get serialized on the server anyway then the extra overhead of the additional connections will slow you down. The current implementation you have however will always be slower than doing it without threading as thats esentially what happens with your lock contention anyway. > 3) "show status" may not be a good example of threaded performance server > > side -- A better test would be a variety of different insert queries or > > such, or changes to different tables. Depending on your table type some > > locking may occur on inserts that can serialize them if you are > inserting > > the same data or data on the same data page in the database, more > disparate > > queries however will actually execute in parallel and should see a speed > > increase. > > I have tried with other queries, some random ones as well, and the results > where very similar. Yep, your example would have the same results with any query due to the above mentioned serialization and lock contention you have. However, if you fixed that and opened one connection per thread (or a pool of say 5 connections that would be shared by 5-n threads) then the type of query and how it executes server side is going to have a definate impact. Good luck! Thnx, > > Lefteris > >
