Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM SQL » View Thread |
Messages 1 to 4 of 4 total |
Commit speed widely variable |
Sun, Jul 24 2011 6:44 PM | Permanent Link |
Bruce Rogers | Hi all,
I have an application out with a small number of clients. It has been in production for about 5 years so it's pretty stable. The issue I've got at the moment is with the receipting system, it has a header and detail file to hold the receipts. There are about 800,000 detail records. When a new receipt is added it inserts the new header record, then inserts one or more detail records, generally no more than 3 detail lines. The Save receipt process updates some totals in other tables and all this is done in a transaction. From time to time the users complain that it can take "ages" to save. I put some timings into track this and found that the commit call, which normally takes less than 1 second to compete, sometimes takes 30 seconds. This condition comes and goes. On one occasion when it became very slow they kicked all but one user off the program and that user still experienced very slow save times. I have yet to try and look closely at what happens during commit, but this sounds like a server/network thing to me. But I thought I'd wave my hand and see if anyone has ideas. I'm using D7 and DBISAM 4.30.1 in client server mode. The app runs across a Gigabit LAN and they have a decent high end server with about 30 people on it. Although as I said above the issue is evident with only one person in. Thanks, Bruce. |
Mon, Jul 25 2011 8:43 AM | Permanent Link |
Huseyin Aliz myBiss ApS | Probably a network hickup
Bruce Rogers wrote: > Hi all, > > I have an application out with a small number of clients. It has > been in production for about 5 years so it's pretty stable. The > issue I've got at the moment is with the receipting system, it has a > header and detail file to hold the receipts. There are about 800,000 > detail records. When a new receipt is added it inserts the new > header record, then inserts one or more detail records, generally no > more than 3 detail lines. The Save receipt process updates some > totals in other tables and all this is done in a transaction. > > From time to time the users complain that it can take "ages" to save. > I put some timings into track this and found that the commit call, > which normally takes less than 1 second to compete, sometimes takes > 30 seconds. > > This condition comes and goes. On one occasion when it became very > slow they kicked all but one user off the program and that user still > experienced very slow save times. > > I have yet to try and look closely at what happens during commit, but > this sounds like a server/network thing to me. But I thought I'd > wave my hand and see if anyone has ideas. > > I'm using D7 and DBISAM 4.30.1 in client server mode. The app runs > across a Gigabit LAN and they have a decent high end server with > about 30 people on it. Although as I said above the issue is evident > with only one person in. > > Thanks, > Bruce. |
Mon, Jul 25 2011 3:01 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Bruce,
<< From time to time the users complain that it can take "ages" to save. I put some timings into track this and found that the commit call, which normally takes less than 1 second to compete, sometimes takes 30 seconds. >. I would guess that something is occurring on the server that is preventing the writes from taking place in a reasonable amount of time. Are there any regularly-scheduled AV scans, backups, automatic updates, etc. ? -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Jul 25 2011 7:16 PM | Permanent Link |
Bruce Rogers | Yes, that does sound like it. Thanks guys.
"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:56A9A887-AE8F-42EE-BC99-CE884434B96D@news.elevatesoft.com... > Bruce, > > << From time to time the users complain that it can take "ages" to save. > I put some timings into track this and found that the commit call, which > normally takes less than 1 second to compete, sometimes takes 30 seconds. > >. > > I would guess that something is occurring on the server that is preventing > the writes from taking place in a reasonable amount of time. Are there > any regularly-scheduled AV scans, backups, automatic updates, etc. ? > > -- > Tim Young > Elevate Software > www.elevatesoft.com |
This web page was last updated on Wednesday, May 15, 2024 at 08:40 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |