Re: [sqlite] Odd performance issue under Windows - correction
John Elrick wrote: John Stanton wrote: John Elrick wrote: John Stanton wrote: I would look at the disk controller/disk drive hardware and the software driver to see if they are reporting correctly to the OS. Some of your numbers are too fast for regular disk technology and suggest that there are either hardware defects or intentional shortcuts to always perform some form of lazy write. Even the fastest 15,000 RPM disks will take a minimum of 8 millisecs for a secure disk write, and it is that disk latency which is the limiting factor in secure buffer flushing. One performance timed example from an older machine with our application was 128 INSERTS in 15.069 seconds. That would be 110 milliseconds per write. The faster machine was showing about 2.0 seconds for the same operation, or 15 milliseconds per write. The Ruby script I posted showed 8 seconds to save 1000 rows, or just at the edge of what you show as a minimum possibility, however it showed 115 seconds or around 115 milliseconds per write on the "slower" machine. While I agree that 8 milliseconds is just too darn good to be true, I'm a little hesitant to call 110 milliseconds a reasonable number for a secure disk write. But then again, I could be wrong. I'm no expert in low level hard drive programming, which I why I have asked for ideas here. The 8mS is for the fastest disks available and assuming infinite speed of the rest of the machine. The 100mS number would not be unexpected from say 5,400 RPM disks and an OS like Windows which has many distractions to divert it from its purpose. I should be very suspicious of the integrity of the machine which performed in 8Ms. - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Odd performance issue under Windows - correction
John Stanton wrote: John Elrick wrote: John Stanton wrote: I would look at the disk controller/disk drive hardware and the software driver to see if they are reporting correctly to the OS. Some of your numbers are too fast for regular disk technology and suggest that there are either hardware defects or intentional shortcuts to always perform some form of lazy write. Even the fastest 15,000 RPM disks will take a minimum of 8 millisecs for a secure disk write, and it is that disk latency which is the limiting factor in secure buffer flushing. One performance timed example from an older machine with our application was 128 INSERTS in 15.069 seconds. That would be 110 milliseconds per write. The faster machine was showing about 2.0 seconds for the same operation, or 15 milliseconds per write. The Ruby script I posted showed 8 seconds to save 1000 rows, or just at the edge of what you show as a minimum possibility, however it showed 115 seconds or around 115 milliseconds per write on the "slower" machine. While I agree that 8 milliseconds is just too darn good to be true, I'm a little hesitant to call 110 milliseconds a reasonable number for a secure disk write. But then again, I could be wrong. I'm no expert in low level hard drive programming, which I why I have asked for ideas here. John - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Odd performance issue under Windows - correction
John Elrick wrote: John Stanton wrote: The real time with the pragma off is 1.78 seconds. The real time on the "faster" machine is 8.4 seconds. When I set the synchronous pragma to off on the "faster" machine, the time drops to 1.64. John Do your various machines use the same hard disk controller and similar technology disks? No. Some of the machines are actually in the hands of other team members and the client. My local machines range from my son's EMachines desktop to a brand new HP laptop running Vista. So we have eight machines with widely varying hardware configurations, yet five of them are within a second or so of being 10 times slower than the average of other three for this particular operation. John I would look at the disk controller/disk drive hardware and the software driver to see if they are reporting correctly to the OS. Some of your numbers are too fast for regular disk technology and suggest that there are either hardware defects or intentional shortcuts to always perform some form of lazy write. Even the fastest 15,000 RPM disks will take a minimum of 8 millisecs for a secure disk write, and it is that disk latency which is the limiting factor in secure buffer flushing. - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Odd performance issue under Windows - correction
John Stanton wrote: The real time with the pragma off is 1.78 seconds. The real time on the "faster" machine is 8.4 seconds. When I set the synchronous pragma to off on the "faster" machine, the time drops to 1.64. John Do your various machines use the same hard disk controller and similar technology disks? No. Some of the machines are actually in the hands of other team members and the client. My local machines range from my son's EMachines desktop to a brand new HP laptop running Vista. So we have eight machines with widely varying hardware configurations, yet five of them are within a second or so of being 10 times slower than the average of other three for this particular operation. John - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Odd performance issue under Windows - correction
John Elrick wrote: John Elrick wrote: John Elrick wrote: Griggs, Donald wrote: John Elrick wrote: "what the heck is happening that is creating a better than order of magnitude difference in execution time on five out of seven Windows machines?". John, If the database is opened and closed just once for your testing, I think you can find out if buffer flushing is involved by *temporarily* adding Pragma synchronous=OFF; At the beginning of your test. Thanks Donald. The results are now identical. So, it has to do with buffer flushing differences between the machines. Now I have to figure out what the differences are given that the XP laptop is configured as shipped and is showing the performance improvement. Corrected text: "Thanks Donald. The results are now in line." The real time with the pragma off is 1.78 seconds. The real time on the "faster" machine is 8.4 seconds. When I set the synchronous pragma to off on the "faster" machine, the time drops to 1.64. John Do your various machines use the same hard disk controller and similar technology disks? - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Odd performance issue under Windows - correction
John Elrick wrote: John Elrick wrote: Griggs, Donald wrote: John Elrick wrote: "what the heck is happening that is creating a better than order of magnitude difference in execution time on five out of seven Windows machines?". John, If the database is opened and closed just once for your testing, I think you can find out if buffer flushing is involved by *temporarily* adding Pragma synchronous=OFF; At the beginning of your test. Thanks Donald. The results are now identical. So, it has to do with buffer flushing differences between the machines. Now I have to figure out what the differences are given that the XP laptop is configured as shipped and is showing the performance improvement. Corrected text: "Thanks Donald. The results are now in line." The real time with the pragma off is 1.78 seconds. The real time on the "faster" machine is 8.4 seconds. When I set the synchronous pragma to off on the "faster" machine, the time drops to 1.64. John - To unsubscribe, send email to [EMAIL PROTECTED] -
