if both pc got dual network, maybe can try connecting the lan directly bypassing the switch...?

I have a .net app that connect to SQL server machine using gigabit lan, both pc running on the same gb lan switich, tested no problem copying huge file. almost max out gb connection.

by slow mean, it connect to sql server get like 10k rows of data consists of ~30 columns, and put up to datagridview, takes about 10 seconds to complete.

if i run the app directly in the sql server machine, the exact same operation take less than 1 second.

both pc are i7 or better, no 32G ram, nothing in the background hogging any resource.

I wonder if there are anything limiting the speed of data transfer or displaying data i need to be aware of ?

Gut feeling is that you're grabbing the rows one by one, necessitating a network round trip per row. Fetch all of them in one shot, not row by row.

Don't know .net or SQL Server enough, but for Go and PostgreSQL, there's this concept of "single round trip query mode": https://pkg.go.dev/github.com/jackc/pgx/v5#QueryExecMode
to slurp all results at once.

A little more of a leap, but understanding this: https://colin-scott.github.io/personal_webs...ve_latency.html and the implications allows you to visualize performance bottlenecks better.

e.g. in your case, doing best case, one network round trip might be about 0.5ms. 10k rows = 5 seconds already spent sending and waiting for network, at least. It's not about bandwidth. It's about latency.

not by row, not using SP, doing something like select * from table1, no filter

I wonder does it matter if i use computer name / ip v6 / ip v4 ?

or it only matters when connection is established, after that it no longer matter(as long as each query doesnt disconnect)

Show me your loop.

Are you slurping all data into memory before iterating through the result? Or fetching per row?

ie, are you: (php code, adapt to your current language)



or

no loop, something like this

Using the DataAdapter to retrieve all of a table takes time, especially if there are many rows in the table. This is because accessing the database, locating and processing the data, and then transferring the data to the client is time-consuming. Pulling all of the table to the client also locks all of the rows on the server. To improve performance, you can use the WHERE clause to greatly reduce the number of rows returned to the client. You can also reduce the amount of data returned to the client by only explicitly listing required columns in the SELECT statement. Another good workaround is to retrieve the rows in batches (such as several hundred rows at a time) and only retrieve the next batch when the client is finished with the current batch.