On Tue, Aug 27, 2019 at 6:58 AM Chris Davis <chr...@actongate.co.uk> wrote:
> > With any networked VFP application sharing a DBC the SMB performance of > the server hosting the DBC is very important? > No. Yes, network performance is very important, but that is a complex mix of network throughput, latency, congestion, theoretical max speed (VFP did some pretty nifty things on 10 Mbps networks, way back when), the basic hardware specs (CPU, clock speed, RAM amount, hard disk performance) and the other demands on the server (running VFP and Exchange and SQL Server on the same machine, for example). And finally, the actual structure and logic of the app is so important: I've been called in on apps where all the temp files were written back to the network, or all of the data files were opened, queried and closed on every call, ruining the VFP caching. Ideally, all of the relatively static resources used by the app should be installed on the local machine: EXE, external reports, temp files, local working tables and the DBC, and a startup program should be invoked each time the app is launched to download an updated version if available from the network. That cuts down on calls to the network to just data, and removes all the contention from sharing the DBC. Assuming your answer to the above question is Yes or Of Course, then when > you have one server that seems to perform well and one that doesn't it > would be useful to easily compare the setup of the two. > No two Windows machines are the same. > Is anyone aware of any utilities that make the configuration and tweaking > of SMB easy or at least allow you to compare to setups? > Is there a reason you are focusing on Server Message Block as the source of the problems? IME, a bad network card or cable is responsible for poor network throughput. Basic SMB is about the same from workstation shares through workgroups and domains and Active Directory. Performance Monitor on the server is one of the easiest clue factories: CPU load, HDD performance, network load gives so many useful clues. Something is always the bottleneck, it's just a matter of narrowing down the possibilities. And the Log reader is an application woefully underused: I often find a log full of error messages that the onsite folks have never seen. > Of course, if your answer to the first question isn't yes I would also be > interested in your thoughts. > > I know there is a lot more that comes into the performance of an > application other than the setup of the server, i.e the spec of the client, > the os of the client, other software such as anti virus, network > infrastructure etc etc. > > Where I am going with this... > > We have lots of sites where an application works well and one site where > it doesn't, and without having to spend hours and hours investigating all > the various settings and registry entries, I just want to start with the > servers and make a comparison to see if there are any obvious differences. > On the machine, or dialed in by remote control, File Explorer, This PC, right-click, Properties, will give you the basic OS version, CPU and RAM. Right-click on the taskbase and Task Manager, More details, will show you any obvious bottlenecks. Back to File Explorer, this PC, right-click and Manage brings up the Computer Management console, Event Viewer will let you look at the logs. --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/cacw6n4tsvq4ego0mn25z0w7rdu0mfk9-fmsk2pxbzv_xbyr...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
