I’ve taken a few days before posting to avoid ranting too much. I’ll try and keep this post rant free. I suspect I’ll fail;
"Are you using TPS files?If so I would assume you’re being hit with the oplocks effect.
Two things are important to understand here;
a) Oplocks (Opportunistic Locks) do not slow the program down. They speed it up. They allow files to be cached locally but only when one user is using the program. It’s traditional to turn them off (to avoid possible file corruptions) but in themselves they are not the problem.
The “one person fast, second person slow” is “caused” by Oplocks, but they cause the “one person fast” not the “second person slow”.
b) >> " the performance with 2 people at the same time is very very slow. "
While “performance” covers a range of possible situations, (do you mean read-speed? write-speed? All browses are slow? Some browses are slow? Reports are slow?) I’m going to assume you mean that specific browses take a long time to load - as this is what most people notice.
This is caused by you “doing it wrong”. Specifically you should test your problem browses in the following 2 ways;
remove the filter? Does that make it faster? Most programmers create terrible filters without matching keys. Which means whole-table-scans - which are slow.
remove embed code. Does that make it faster? Lots of programmers write unnecessary embed code (like doing manual record FETCHES instead of just adding to the browse VIEW). Worse, filtering in code is “client side” which is the slowest filtering there is.
So my suggestion to you is find out which browse is slow, then deploy test versions of the browse to see which technique you’ve used is causing the slowness.
Of course it’s possible that the LAN is just congested, or the SAN is just slow (both helped in the single-user case by local caching) but more often it’s your code that’s bad, not the network.