Простой SQL-запрос для чтения одной (большой) записи занимает вечность при запуске модуля K8S и мгновенно при запуске в ⇐ C#

[Anonymous]

У меня есть простая таблица в SQL Server:

Код: Выделить всё

CREATE TABLE [dbo].[MyTable]
(
[Ticket] [uniqueidentifier] NOT NULL,
[UserID] [int] NOT NULL,
[Progress] [int] NOT NULL,
[Created] [datetime2](7) NOT NULL,
[KeepRes] [bit] NOT NULL,
[Result] [nvarchar](max) NULL,
[ResultFetched] [datetime2](7) NULL,
[CorrelationID] [varchar](100) NULL,

CONSTRAINT [PK_MyTable]
PRIMARY KEY CLUSTERED ([Ticket] ASC)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
)

Обратите внимание, что строки этой таблицы могут иметь довольно большой столбец «Результат» (300 МБ или около того).

Я запрашиваю эту таблицу из мое приложение в .Net6/C# с ​​помощью простого выбора с первичным ключом.
Я использую Entity Framework Core:

Код: Выделить всё

public void QueryTable(Guid ticket)
{
using (MyDBContext db = new MyDBContext)
{
var res = db.MyTable.Find(ticket);
Console.Write("Res found:" + (res != null));
}
}

Этот код является частью моего приложения и развернут в двух средах:

• IIS, работающий под управлением Windows Server 2014
• модуль K8S

Обе среды указывают на один и тот же экземпляр базы данных — SQL Server 2014.< /p>
Теперь самое интересное:
когда извлекаемая запись имеет столбец Result размером более 500 КБ, оператор db.MyTable. Find(ticket); занимает менее секунды при запуске в среде № 1 и более минуты при запуске в среде № 2.
Еще один тест, который я выполнил: что запрос занимает сопоставимое время (менее секунды) в обеих средах, если полученная запись имеет столбец Result размером менее 500 КБ (около 10 КБ или меньше).
Почему существует ли разница в производительности между двумя средами только для конкретного запроса с полученными большими записями?
Объединение сред в сеть
Существует металлический сервер, на котором размещены все эти среды. Операционная система металлического сервера — Windows Server 2012 Data Center R2. IP 10.0.1.1. На металлическом сервере также работает база данных SQL Server.
IIS работает на виртуальной машине (скажем, с IP 10.0.1.2). Эта виртуальная машина работает поверх металлического сервера с использованием VMWare Workstation 15 Player. ОС виртуальной машины — Windows Server 2016 Datacenter.
Среда K8S развертывается на трех виртуальных машинах, работающих поверх металлического сервера, с использованием VMWare Workstation 15 Player. ОС этих трех виртуальных машин — Linux Ubuntu Server 20.04.
Одна виртуальная машина является главным узлом. Остальные две виртуальные машины — это рабочие узлы, на которых работают модули. IP-адреса виртуальных машин: 10.0.1.10 (главный), 10.0.1.11 и 10.0.1.12 (рабочие).
Теперь K8S имеет внутренний механизм внутреннего назначения IP-адресов, который дает другим внутренним адресам, например 192.168.1.X, разным модулям (не уверен, актуально ли это в этом разговоре...). В любом случае, в нашей строке подключения мы ссылаемся на SQL Server по адресу 10.0.1.1 (металлический сервер, на котором работает SQL Server).
Дополнительный эксперимент 1Мы добавили в тест третью среду, еще один кластер K8S, с той же версией приложения, работающей на точно такой же конфигурации модулей (тот же YAML, который развертывает ресурсы в кластере).
Примечание: в данном случае экземпляр БД другой: у него точно такая же схема, ресурсы, версия СУБД, конфигурация сети и т. д., это просто другой экземпляр.< /p>
Результат запроса сопоставим со средой №1, работающей в IIS.
Дополнительный эксперимент 2
Мы пытались выполнить тот же запрос с помощью автономного SQL-клиента командной строки (Python).

Код: Выделить всё

    sudo apt install python3-pip
pip install mssql-cli
python3.8 -m mssqlcli.main -S 10.0.1.1 -U  -d mydb -P 

Если мы выполним эти строки из командной строки рабочего узла (то есть вне пода K8S), запрос будет быстрым и займет меньше секунды. Если мы выполним эти строки как часть модуля K8S, это снова займет около 1 минуты.
Итак, итог: мы имеем сопоставимые результаты с клиентом Python и EF Core, и это Кажется, в данный момент виновата сеть модуля. Правильно ли я читаю эти результаты?

Подробнее здесь: https://stackoverflow.com/questions/769 ... run-is-k8s