High Time to first byte (TTFB) in Windows Server 2012 R2

Question

My Windows Server 2012 R2 has a long wait time on first access. It doesn't matter which service it is: RDP server, SMB access, Microsoft SQL Server or mail server that run on it. The first access experiences always a delay. After accessing, say, SMB for the first time accessing other services, for example MS SQL Server database, is fast. Or for example, after checking mail I can access SMB share very fast. When I let the server rest for some time, the delay is there again.

Accessing a CentOS virtual machine that runs in Hyper-V on this host is always fast (I think). There are 2 virtual machines with 512MB of RAM assigned to each; dynamic memory is off.

I can think of the following as a possible cause:

• Network problem
• Problem on the client computer side
• Insufficient RAM on server (should 8 GB be enough?)
• Inefficient disk subsystem on server that wakes all the HDDs and waits till they spin up
• Something else

Task manager shows that an average CPU load on server is mostly around 1-2% and 30% of RAM is taken.

Which steps would you take in order to find out what is the problem?

Update

Today I upgraded from 8 GB RAM to 16 GB and it didn't change anything in first access delay.

Also I turned off the page file on host. Again, it didn't change anything.

Update

Finally I managed to catch the right moment with WireShark. From its logs I can see that:

1. Client PC and the server find each other over LLMNR
2. They negotiate over TCP to use SMB
3. They switch to SMB2
4. Then the client PC sends TCP ACK to the server port 445
5. After 4 seconds of waiting the client PC sends NBNS broadcast LAN request (Name query NB MY_SERVERNAME<1c>)
6. Then it resends this request after 1 second of waiting
7. It resends this request again after 700 ms second of waiting
8. After 6,5 seconds starting from step 1 the client PC finally sends SMB2 Session setup request, NTLMSSP_NEGOTIATE and normal SMB communication begins.

Update

Turning off "NetBIOS over TCP/IP" doesn't help.

Looked into Event Viewer and found there interesting messages from MS SQL Server 2008 R2 Express:

========================
Level: Information
Date: 17-Jun-22
Source: MSSQL$SQLEXPRESS
Task Category: Server
========================

Time  Event ID
08:44:02    17401   Server resumed execution after being idle 822 seconds: user activity awakened the server. This is an informational message only. No user action is required.
08:08:36    17401   Server resumed execution after being idle 346 seconds: user activity awakened the server. This is an informational message only. No user action is required.
07:47:31    17403   Server resumed execution after being idle 1792 seconds. Reason: timer event.
07:02:20    17403   Server resumed execution after being idle 1792 seconds. Reason: timer event.
06:17:08    17403   Server resumed execution after being idle 1792 seconds. Reason: timer event.
05:31:57    17403   Server resumed execution after being idle 1792 seconds. Reason: timer event.
04:46:45    17403   Server resumed execution after being idle 1792 seconds. Reason: timer event.
04:01:34    17403   Server resumed execution after being idle 1792 seconds. Reason: timer event.

08:08:36 is the time when I connected to the database with client application.

This issue doesn't have anything to do with MS SQL Server User Instances.

Update

There is one service that doesn't experience this delay:

I made in Delphi an Indy-based HTTP server that accesses the same database on MS SQL server. Requests to this application over HTTP are served instantly.

Requests to the same database using ADO experience a delay the first time.