[SOLVED] Slow wapt-get: solution

[erickeke]

A workaround for a bug that has long annoyed me

Client version: 1.7.4.6077 and higher, on W10 > 1803

Machine out of domain

On some machines, wapt-get update takes a very long time to complete.

When running `wapt-get update -ldebug`, we regularly find this in the logs:

2019-06-13 14:59:43,460 DEBUG Transaction took too much time: 2.33699989319
2019-06-13 14:59:45,822 DEBUG Transaction took too much time: 2.31399989128
2019-06-13 14:59:48,397 DEBUG Transaction took too much time: 2.31700015068
2019-06-13 14:59:50,740 DEBUG Transaction took too much time: 2.30399990082
2019-06-13 15:00:17,855 DEBUG Transaction took too much time: 2.37700009346
2019-06-13 15:00:20,233 DEBUG Transaction took too much time: 2.34000015259

Simultaneously, when these messages appear, Procmon remains stuck for approximately 2 seconds on "CreateFile \\WORKGROUP*\MAILSLOT\NET\NETLOGON":

mailslot.PNG (9.69 KB) Viewed 4921 times

Workaround:

Disable NetBIOS over TCP/IP:

Capture.PNG (18.68 KB) Viewed 4921 times

After running `wapt-get update -ldebug` again, the "Transaction took too much time" message disappears. Procmon no longer attempts to open mailslots.

From what little I understand, it seems to be related to an Active Directory (AD) call concerning user account management. The AD call is even used to query a local, non-domain account... I need to investigate further to understand this better.

The thread below was very helpful, as the timeouts mentioned were similar to those I encountered:
https://social.technet.microsoft.com/Fo... inserverDS

The first answer addresses the problem, and disabling NetBIOS over TCP/IP solves it, allowing us to finally enjoy a fast WAPT connection

I think the Wapt team hasn't encountered the problem because they primarily use Wapt on machines in an AD domain.

I will complete my post later.

[htouvet]

Thank you very much for this analysis.
Indeed, on our infrastructure, NetBIOS is generally disabled.

The slowness problem may also be related to the search for the groups to which the machine is attached.
( setuphelpers.get_computer_groups() )
who appeals to the AD

I think we need to configure this usage...

Could you try putting an empty host_profiles entry in wapt-get.ini?

<waptdir>\wapt-get.ini:

Code: Select all

[global]
host_profiles=

The information gathered potentially involves Active Directory or name searches:

setuphelpers.host_info():

Code: Select all

    info['profiles_users'] = get_profiles_users()
    info['local_profiles'] = get_local_profiles()
    info['local_administrators'] = local_admins()
    info['local_groups'] =  {g:local_group_members(g) for g in local_groups()}
    info['local_users'] =  local_users()

in a WaptPython, we can test which one might take time.

[dcardon]

Hello Erickeke,

A workaround for a bug that has long annoyed me.

Client version: 1.7.4.6077 and above, on W10 > 1803.

Machine not in domain.

On some machines, wapt-get update takes a very long time to complete.

Thanks for your long quote. Have you had a chance to look into which function is taking too long with the NetBIOS part?

As you mentioned in your email, we tend to always disable NetBIOS (there's a package in the store for that) )

We've made some changes to improve this issue. It should be included in the next release.

Hopefully this will solve the problem. Otherwise, disabling NetBIOS is also a very good idea!

Sincerely,

Denis

[erickeke]

Sorry, I missed quite a few messages, and then I was on vacation and missed more. I updated my email to one I check more often.

No, I haven't looked at the function yet, I'll get back to it when I have 5 minutes, I promise!