Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.paradox    |    To crash or not to crash, asks Borland    |    9,834 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 8,880 of 9,834    |
|    Jim Moseley to All    |
|    Re: I need help in asking the right ques    |
|    01 Nov 07 13:43:11    |
   
   From: jmose@mapson.attglobal.net   
      
   Craig,   
      
   I have gone through this (and still am!), so I understand. I've resorted   
   to running the WireShark network monitor (freeware that used to be Ethereal).   
    It shows you all of the network traffic. You'd be amazed at how much data   
   gets shipped back & forth for the seemingly simplest task.   
      
   Since you can narrow down where it is really slow, you can start a WireShark   
   trace just before jumping to the next record, then stop the trace. This   
   will show all the network usage - could be thousands of records (or hundreds   
   of thousands!). If you page down the trace, look for any large time gaps,   
   meaning there's a lag somewhere. Whatever is the last instruction is probably   
   causing the delay.   
      
   In WireShark's Statistics menu, the Protocol Heirarchy will show you how   
   much SMB traffic (peer-to-peer file sharing) has happened. You can also   
   see a summary of each I/O type, on Statistics | Service Response Time | SMB.   
      
      
   WireShark doesn't do a very good job helping you narrow down which file is   
   causing all the I/O, though. I have to export the list to Excel, and tweak   
   it there. I can send instructions if you're interested.   
      
      
   Outside of that, here are my guesses on what you might need to change in   
   your application to speed it up:   
      
   1. You might be constantly reopening tcursors. Make the tcursor variable   
   global to the form or library, and use this code instead of just tc.open(..):   
   ok = tc.isAssigned()   
   if not ok then   
    ok = tc.open("myTableName.db")   
   endif   
      
   2. Block sizes on your tables are too large. When you open a table, you   
   get 8 pages of data. If you use 32k or 16k block sizes, that can add up   
   to lots of wasted bandwidth.   
      
   3. You have lots of files in the ":Work:" folder. This causes long seek   
   times searching for the right file.   
      
   4. You open forms, reports, libraries with just the filename and no extension.   
    This can also cause long seek times. Use this logic instead:   
   myform = "ABC123"   
   if not f.open(myForm + ".fdl",winStyleDefault+winStyleHidden) then   
    errorClear()   
    if not f.open(myForm + ".fsl",winStyleDefault+winStyleHidden) then   
    errorShow()   
    return   
    endif   
   endif   
      
   5. You have obsolete printers & drive mappings. This can greatly slow down   
   a networked application, as Paradox is constantly trying to resolve all   
   printers   
   & drives. Make sure every printer is 'Ready'.   
      
      
   Let me know if you need any help interpreting the WireShark output. It is   
   very powerful, but pretty cryptic.   
      
   HTH,   
   Jim Moseley   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca