Вопрос
Существуют ли способы повысить производительность операций с метаданными между контейнером на базе Linux, работающим в службе приложений Azure, и подключенным томом, размещенным в службе "Файлы Azure"?
Контекст
Недавно я перенес решение, в котором все было на одном сервере, на решение на основе Azure, где:
- Код выполняется в контейнере, размещенном в службе приложений Azure.
- Те файлы, которые являются частью бизнес-данных, находятся в Azure Files (т.
Настройки > Конфигурация > Сопоставления путей раздел).
Это привело к некоторым проблемам с производительностью операций, которые выполняют поиск в папке, чтобы увидеть, существуют ли определенные файлы. В настоящее время это делается с помощью PHP функция существования файла.
При тестировании на моем локальном устройстве я могу повысить производительность, добавив : кэшировано к параметру привязки; например --mount type=bind,source=d:\my\host\path, target=/var/my/container/path:cache; но я не могу найти ничего подобного в службе приложений Azure.
Мой контейнер работает под управлением Linux (Убунту: 21:10); и я читал, что операции с метаданными SMB (включая проверку существования файла) имеют более высокие накладные расходы в Linux, чем в Windows; так что, возможно, это связано (например, поскольку Azure Files использует SMB); хотя я не уверен (поскольку путь монтируется к контейнеру, поэтому ОС контейнера может не знать о базовой реализации).
я включил большие общие папки увеличить число операций ввода-вывода, доступных для файлового ресурса; но это не имеет значения (что, учитывая, что это проблема метаданных, а не производительности ввода-вывода, имеет смысл).
В настоящее время я думаю, что решением было бы обновить код, чтобы сохранить представление файловой структуры в базе данных приложения, чтобы мы могли запросить это, чтобы получить ту же информацию быстрее; но у этого есть недостаток, заключающийся в том, что каждая операция по загрузке или удалению файла должна также обновлять базу данных, чтобы синхронизировать / дублировать информацию о диске и базе данных; поэтому я стремлюсь решить эту проблему с инфраструктурой, а не перекодировать, если это возможно.
