>Many business apps are "bursty" - they go long periods with no network traffic at all, then generate bursts of traffic in response to user inputs.
>
>I think you've said elsewhere that your app has a SQL Server back-end. If so it would be client-server. As Mike points out, if you've written it for speed and efficiency then traffic and "average" use of bandwidth will be minimized. Well-written client-server generates less traffic than working against native VFP tables on a remote computer, but if it's poorly written and doesn't make use of client-server best practices then traffic could be as high as native tables.
>
>Tore's argument is valid in that VFP traffic can flow on most common network connections and speeds. The total traffic your app generates will be the same, but with a faster network the bursts take less time to transmit, so your app feels more responsive. Also, on a faster network your app's traffic will consume a smaller fraction of total bandwidth, so it will have less effect on other users.
>
>In the real world all wired LANs have been gigabit (1000Mbit) or better for many years. No server should ever be attached at a speed lower than that, regardless of what types of traffic it processes. If there are multiple virtual servers hosted on a single physical server computer, that physical machine will usually need multiple gigabit connections, or one or more higher speed links such as 2.5gig or 10gig.
>
>The type of connection is also important:
>
>- Wired LAN is optimal for any use, and is required for your SQL server back-end connection to the network backbone
>- Your clients can be connected by business-grade Wi-Fi but performance and reliability will be lower than wired
>- WAN connections between your clients and the back-end server typically have high latency and will be less responsive and less reliable
>
>With all that in mind this is how I'd respond to that question:
>
>- The app's SQL Server back-end should be connected to the network backbone by at least a gigabit (1000Mbit) wired LAN connection for normal/baseline responsiveness. A higher speed connection will improve responsiveness
>
>- The app has a client-server architecture which minimizes network traffic between the back-end server and the client workstations
>
>- Network traffic between the back-end server and client workstations is bursty. Long term average bandwidth usage will depend on the number of simultaneous client workstations in use, and the activity levels of those workstations. As a rule of thumb, average bandwidth usage for one client workstation will be a small fraction of the usage incurred by a streaming app running on that same computer
>
>- For best performance and reliability, client workstation connections using Wi-Fi or over a WAN link should be avoided where possible
>
>If the questionnaire only lets you circle one choice, then circle "1000". But maybe you can add some other comments, or at least you'll have some ammunition if they ask you to explain your choice :)
>
>>One of the questions on a long questionnaire I am filling out for a customer is:
>>"What is the bandwidth requirement for the servers to be connected to the network (10/100/100/10G)?"
>>
>>What would be somewhat appropriate answer?
>>
>>TIA

Thank you very much for the detailed reply. Yes, the application is a client-server (SQL Server back-end). And I agree with everything you said. I have actually submitted the questionnaire, leaving this item blank. If they catch and come back to me, I will circle 1000. I think the questionnaire is very generic for a large organization (many questions didn't even apply to my app). The things is that this customer has been using my VFP/.NET app for about 10 years. Now, they want to move it from Server 2008 to Server 2019. And I have already done tons of these for other customers. I am sure you know why they do it. But this customer corporate IT "treats" this as an application upgrade. Even though the VFP application does nothing on the server; everything is on the client desktop. The only thing that happens on the server is my ASP.NET (C#) application.

Again, thank you.