Назад | Перейти на главную страницу

Тот же запрос WMI намного медленнее на другом компьютере

Я разместил этот вопрос некоторое время назад на переполнение стека, но, к сожалению, ответа пока не получил. На самом деле это не очень срочно, так как эта проблема, похоже, существует только на моей машине - пока. Но мне сказали, что при использовании WMI на других машинах в нашей сети были подобные проблемы.

Исходный вопрос:

Итак, у меня есть этот метод, который считывает квоту пользователя:

public ulong GetQuotaLimit(string username, string domain, char volume)
{
    var scope = GetManagementScope(this, @"root\cimv2");
    var path = new ManagementPath(
                        string.Format(
                                      "Win32_DiskQuota.QuotaVolume='Win32_LogicalDisk.DeviceID=\"{0}:\"',User='Win32_Account.Domain=\"{1}\",Name=\"{2}\"'",
                                      volume, domain, username));
    var diskQuotaObj = new ManagementObject(scope, path, null);
    var result = Convert.ToUInt64(diskQuotaObj.Properties["Limit"].Value);
    return result;
}

Он отлично работает на машине моего коллеги (~ 200 мс), но по какой-то причине этого не происходит на моей собственной машине - требуется НАМНОГО больше времени, чтобы получить ответ от машины, которая поддерживает квоту пользователя (~ 2000 мс). Спецификации для обеих машин практически одинаковы (одна и та же ОС, одно и то же HW), и они расположены в одной сети и в одном домене.

Итак, я проверил сетевой трафик на обеих машинах на предмет этого запроса и обнаружил одну странную вещь: после установления соединения и аутентификации машина моего коллеги сразу же переходит к фактическому запросу (начиная с кадра 491).

192.168.131.95 это машина, которая поддерживает квоту

192.168.131.175 это машина моего коллеги

192.168.144.11 моя машина

Записи фильтруются по этим IP-адресам

Но моя машина продолжает трехстороннее рукопожатие TCP (кадры 90-92), затем ждет некоторое время (что вызывает задержку) и продолжает вторую аутентификацию (начиная с кадра 126), прежде чем, наконец, сделает то, что предполагается. to do - отправка актуального запроса.

Похоже, что клиент (моя машина) каким-то образом потерял соединение, но я не вижу ни одного кадра, который бы действительно это указывал. Я также слышал, что у WMI есть некоторые проблемы с фрагментацией, но сегменты / дейтаграммы на самом деле меньше, чем фрагментация - обычный порог фрагментации (1500 байт?), И wirehark не указал, что кадры были повторно собраны, поэтому это не должно быть причиной.

Кто-нибудь знает, почему это происходит?