Performance over network
in [Visual Objects]
|
Prev: Vulcan Advantages (was Choice SQL Database)
Next: mySQL_msSQL_Oracle connection and other relations / ALL command
From: p.callegari on 11 Dec 2008 19:56 Dirk My experience: xp prof as server + 5 xp workstation + Gb Lan + Switch + CAT6 cables. VO Exe = 2mb DLL=8mb DB=very big (2gB) Programming guidelines: CDX indexes + optimized filter queries (filtered fields included in CDX) I launch the program in each workstation from a local directory that contain a copy of exe, dll's and some CAVO dll's as Cato*.dll, CavoDbf.rdd, Dbfcdx.rdd, VO28GUI.DLL, _DbfCdx.rdd etc etc, while dbf's stay on a shared directory on server. Every day i have a scheduled backup with ROBOCOPY that 1) copy server modified files on a backup dir 2) upgrade older exe and dll's on all workstations if i make a new version of my program. With this approach speed is not a problem. Speed of workstations is about the same than working on server (only a 1-2 seconds delay on startup), and with robocopy i have not to worry about copying new files from server to workstation. Recently i upgraded to terminal services. I bought 5 cheap HP thin clients with linux that RDP with the same xp Prof server. I'm very happy because thin client are noiseless, very fast to configure, no time for MS stuff (windows update etc etc) and only 10 watt consumption. Speed is very fast (same as working on server). XP SP3 is software-limited only to 1 RDP, so you need.... a little workaround. Ciao Paolo
From: Dirk (Belgium) on 12 Dec 2008 03:57 Paul D B wrote: > > But Dirk: what I would do, before going through the effort of > redesigning, is see if it is the data access that slows things down, > or the building/painting of a too complex window that is overloaded > with controls. It is quite easy to test: - open the childwindow > without opening the DBF's - or if this is too hard to do, use copies > of the DBF's that contains only a few records - and do the test with > the data on the local drive, and again with the data on the remote > drive. > > Paul, These tests are all done. Empty DBF's over the network takes 2 seconds less then full DBF's (2 seconds on 14 or 9 seconds). So, it is realy the window design with takes so much time. It is a childwindow, with 9 tabs. Each tab is a splitwindow(!): On top is one record (recordview) - on bottom is a databrowser (browseview) of the same shared DBF. Each top has at least 1 subdatawindow with a parent-child DBF. Most top have about 25 linked controls to this DBF. Childwindow = DataWindow with 9 Tabs Tab one = Splitwindow with Top-part and Bottom part Top-Part = DataWindow + SubDataWindow DataWindow with 25 controls SubDataWindow with databrowser with 10 columns Bottom-Part = DataWindow with databrowser Databrowser with 20 columns Tab two = Splitwindow with Top-part and Bottom part Top-Part = DataWindow + SubDataWindow DataWindow with 25 controls SubDataWindow with databrowser with 10 columns Bottom-Part = DataWindow with databrowser Databrowser with 20 columns .... Tab nine = Splitwindow with Top-part and Bottom part Top-Part = DataWindow + SubDataWindow DataWindow with 25 controls SubDataWindow with databrowser with 10 columns Bottom-Part = DataWindow with databrowser Databrowser with 20 columns All Tabs are linked in such a way that changing some records on one tab also change records on other tabs. This changes are only 'applied' when moving from one tab to another tab. The fastest time needed to open this childwindow (local exe + local dbf + empty dbf) is about 3312 milliseconds (3,5 seconds). local exe + local dbf + empty dbf = 3312 milliseconds local exe + network dbf (100) + empty dbf = 6687 mseconds local exe + network dbf (1GB) + empty dbf = 5194 mseconds local exe + local dbf + full dbf = 4469 milliseconds local exe + network dbf (100) + full dbf = 9017 mseconds local exe + network dbf (1GB) + full dbf = 7452 mseconds network exe + local dbf + empty dbf = 7108 milliseconds network exe + network dbf (100) + empty dbf = 11861 mseconds network exe + network dbf (1GB) + empty dbf = 9064 mseconds network exe + local dbf + full dbf = 8065 milliseconds network exe + network dbf (100) + full dbf = 14004 mseconds network exe + network dbf (1GB) + full dbf = 10619 mseconds Cheers, Dirk --
From: Paul D B on 16 Dec 2008 03:14 Dirk (Belgium) wrote: > Paul D B wrote: > >> >> But Dirk: what I would do, before going through the effort of >> redesigning, is see if it is the data access that slows things down, >> or the building/painting of a too complex window that is overloaded >> with controls. It is quite easy to test: - open the childwindow >> without opening the DBF's - or if this is too hard to do, use copies >> of the DBF's that contains only a few records - and do the test with >> the data on the local drive, and again with the data on the remote >> drive. >> >> > > Paul, > > These tests are all done. Empty DBF's over the network takes 2 seconds > less then full DBF's (2 seconds on 14 or 9 seconds). > So, it is realy the window design with takes so much time. > > It is a childwindow, with 9 tabs. > Each tab is a splitwindow(!): On top is one record (recordview) - on > bottom is a databrowser (browseview) of the same shared DBF. Each top > has at least 1 subdatawindow with a parent-child DBF. Most top have > about 25 linked controls to this DBF. > > Childwindow = DataWindow with 9 Tabs > Tab one = Splitwindow with Top-part and Bottom part > Top-Part = DataWindow + SubDataWindow > DataWindow with 25 controls > SubDataWindow with databrowser with 10 columns > Bottom-Part = DataWindow with databrowser > Databrowser with 20 columns > Tab two = Splitwindow with Top-part and Bottom part > Top-Part = DataWindow + SubDataWindow > DataWindow with 25 controls > SubDataWindow with databrowser with 10 columns > Bottom-Part = DataWindow with databrowser > Databrowser with 20 columns > .... > Tab nine = Splitwindow with Top-part and Bottom part > Top-Part = DataWindow + SubDataWindow > DataWindow with 25 controls > SubDataWindow with databrowser with 10 columns > Bottom-Part = DataWindow with databrowser > Databrowser with 20 columns > > All Tabs are linked in such a way that changing some records on one > tab also change records on other tabs. This changes are only > 'applied' when moving from one tab to another tab. > > The fastest time needed to open this childwindow (local exe + local > dbf + empty dbf) is about 3312 milliseconds (3,5 seconds). > > local exe + local dbf + empty dbf = 3312 milliseconds > local exe + network dbf (100) + empty dbf = 6687 mseconds > local exe + network dbf (1GB) + empty dbf = 5194 mseconds > > local exe + local dbf + full dbf = 4469 milliseconds > local exe + network dbf (100) + full dbf = 9017 mseconds > local exe + network dbf (1GB) + full dbf = 7452 mseconds > > network exe + local dbf + empty dbf = 7108 milliseconds > network exe + network dbf (100) + empty dbf = 11861 mseconds > network exe + network dbf (1GB) + empty dbf = 9064 mseconds > > network exe + local dbf + full dbf = 8065 milliseconds > network exe + network dbf (100) + full dbf = 14004 mseconds > network exe + network dbf (1GB) + full dbf = 10619 mseconds > > Cheers, > > Dirk Hi Dirk, well you have done some precise testing now and this allows you to pinpoint several problems. I must admit that the difference between: > local exe + local dbf + empty dbf = 3312 milliseconds and > network exe + local dbf + empty dbf = 7108 milliseconds is surprising, given the fact that the application is already loaded in memory and that these timings are for the opening of a childwindow only (but that was your initial problem and question, and I have no answer for that). But it is clear that you have to redesign your window which is overloaded. Not easy, I've got a few similar windows (also with several tabs that all have browsers and all share the same servers) and the fact that you are sharing servers between the subpages and that they communicate which each other, makes it quite difficult to redesign it. But it is clear that you should go to an approach where you only open the servers and browsers when the user opens that tabpage. -- Paul
From: Dirk (Belgium) on 16 Dec 2008 04:12 Paul D B wrote: > Dirk > > Hi Dirk, well you have done some precise testing now and this allows > you to pinpoint several problems. I must admit that the difference > between: > > local exe + local dbf + empty dbf = 3312 milliseconds > and > > network exe + local dbf + empty dbf = 7108 milliseconds > > is surprising, given the fact that the application is already loaded > in memory and that these timings are for the opening of a childwindow > only (but that was your initial problem and question, and I have no > answer for that). > > But it is clear that you have to redesign your window which is > overloaded. Not easy, I've got a few similar windows (also with > several tabs that all have browsers and all share the same servers) > and the fact that you are sharing servers between the subpages and > that they communicate which each other, makes it quite difficult to > redesign it. But it is clear that you should go to an approach where > you only open the servers and browsers when the user opens that > tabpage. Paul, Redesign will be done next month. January is de performance month for me for the whole application. BUT the fact that a network EXE is slower then the local EXE can not be fixed by me, because this is a Microsoft Problem. I was hoping that someone could (a) confirm this problem with his application (b) give me a solution (registry etc) but I receive nothing about that. So, I also will have to write an application loader, and a new upgrade senario (this would be the most problem). Tx for your replies, Dirk --
From: Marc Verkade [Marti IT] on 16 Dec 2008 05:08
Hai, We have seen that communicating through a share F:\App.exe works slower than using an UNC path like \\serverip\appshare\app.exe Perhaps worth a try. -- Grtz, Marc "Dirk (Belgium)" <dirk.dot.herijgers(a)pbprojects.dot.be> schreef in bericht news:4iK1l.109737$xx1.44073(a)newsfe24.ams2... > Paul D B wrote: > >> Dirk >> >> Hi Dirk, well you have done some precise testing now and this allows >> you to pinpoint several problems. I must admit that the difference >> between: >> > local exe + local dbf + empty dbf = 3312 milliseconds >> and >> > network exe + local dbf + empty dbf = 7108 milliseconds >> >> is surprising, given the fact that the application is already loaded >> in memory and that these timings are for the opening of a childwindow >> only (but that was your initial problem and question, and I have no >> answer for that). >> >> But it is clear that you have to redesign your window which is >> overloaded. Not easy, I've got a few similar windows (also with >> several tabs that all have browsers and all share the same servers) >> and the fact that you are sharing servers between the subpages and >> that they communicate which each other, makes it quite difficult to >> redesign it. But it is clear that you should go to an approach where >> you only open the servers and browsers when the user opens that >> tabpage. > > > Paul, > > Redesign will be done next month. January is de performance month for > me for the whole application. > > BUT the fact that a network EXE is slower then the local EXE can not be > fixed by me, because this is a Microsoft Problem. I was hoping that > someone could > (a) confirm this problem with his application > (b) give me a solution (registry etc) > but I receive nothing about that. > > So, I also will have to write an application loader, and a new upgrade > senario (this would be the most problem). > > Tx for your replies, > > Dirk > -- > |