Distributed file system(dfs) load analysis?

Question

1C

Hello!
There are 3 physical servers. On them, data is scattered around the servers in different ways: documents, photos / scans, file IB 1C. This data is presented as one shared folder thanks to DFS.
DFS itself works for us on a virtual DC server, where DHCP and DNS work along with it. The DC server, among other things, is located on one of these 3 physical servers, but the data for DFS is one screw, the image of the DC virtual machine is another screw. The problem is that DFS began to hang, where the most resource-intensive thing is IB 1C.
1) How to analyze workload data?
There is a standard Windows perfmon and, in principle, I can collect standard parameters using it, but it's not clear to me whether this will be enough. I found separate perfmon counters for DFS, but which ones are needed, what information they display and how to interpret their result is not clear. In theory, it’s even a little unclear to me where there will be a bottleneck in resource congestion. I can only assume that taking into account the fact that DFS is only a link server, then the main load on DC is the network, DC is an intermediary in fact, if you look only at DFS. On physical servers, the main load is the screws where the DFS data is located. Where is the processor and memory eaten up most on physical or virtual servers when accessing through DFS is not clear?
2) DFS work?
What protocol does DFS use for its work, as I understand it SMB? The bottom line is that, as I mentioned, file IB 1C is used from the data. The specifics of our company is that we receive a lot of IS from clients and many employees from different places (several terminals, their own computers) can access this IS, it may also not be stored for a long time, so the web server and client-server option is not suitable for us. IS data, while we have a client-server version of 1C. Who faced with 1C in DFS where to catch a bottleneck, since STARTING IB in DFS can take up to 10 minutes? IS can be of different sizes, typical / non-standard, different configurations.
As a speed solution is also a question. How viable is the option if you physically forward the screw on the virtual terminal server, place IB on it, drive the folder with these IB into DFS. As a result, those who sit on this terminal are the people who most of all need these information security and they access not over the network but to the local disk, the rest access over the network through DFS.

Answer 1

look in the file replication service event log

I took note, but this is not enough for me, I want to see in numbers what is really happening, so the first thing that should come to mind is pefmon. In addition, I probably forgot to mention, but DFS is not replicated with other domains, at least in the next 2-3 months this will not happen, but in principle it will be introduced one more DC later. We have a problem, after all, not only within 1C, all other data also began to slow down during operation, it is more obvious, of course, in 1C.

Actually, file 1s has two main problems - blocking, and a large amount of data transmitted over the network.
With DFS, you multiply both of these problems by the number of users.

In principle, before managed forms in 1C on DFS, IS worked more or less tolerably, and 8.3 sometimes moves well if there are not many users in a particular IS and a heavy load on DFS, I just need to adjust everything to new realities.

The normal organization of work with 1s over the network is a shared network resource with file access, if there are few users and the network is fast, if the network is slow, then the terminal, or web access.
If there are many users, then the transition to SQL.

We have the most-most maximum for 1 IB can reach 5 users. And what about the web server, provided that the information security will be published by accessing the DFS over the network, while the web server itself is a separate computer, how will the load go in this case? After all, the request / response formats in this case, in theory, are in the post / get format. In this case, the client made a request to the web server computer, the web server sent a request to the IS on DFS and back DFS-> web server-> client. We have rare IBs, about 70-80, which do not change very often, unlike the rest, so a web server would be suitable for them, but I tried to implement this option. There is an error in the screenshot that I ran into in this approach, I set up delegation to DC for the web server service on DC in relation to the computer that is the web server, but I don’t know where to dig further.

The normal organization of work with 1s over the network is a shared network resource with file access, if there are few users and the network is fast, if the network is slow, then the terminal, or web access.
If there are many users, then the transition to SQL.

In principle, I understand this, I'll tell you more if we abstract from our network and put the usual 4 computers in a local grid. For 4 or more users, file IB over the network, from experience, a web server is definitely installed. All the advice on the Internet for regular file information security over a network is a gigabit network, SSD is nonsense, RAMDISK is a clinic.
In our case, the first thing I asked was which protocol DFS uses, since the peculiarity is that not only 1C has locks on tables in the file version, but there is an opinion that the standard MS SMB protocol does not favor normal operation in 1C, in the abstract example above this is experimentally proven, and it has been experimentally tested more than once; the web server solves all issues with the speed of file information security by 3-12 times.
In addition to the question in the comment above about the client-> web server-> DFS mode, my proposed option, which is described at the end of the main question, is still viable.