2016-05-17 3 views
0

Итак, у меня есть веб-приложение, работающее на Azure, и есть конечная точка API, которая будет обрабатывать длительный процесс (примерно час, который я могу сказать). Это нормально при запуске локального на визуальной студии, но когда он переходит на лазурь, он не запускается после запроса на 55 секунд.Azure Web Apps Длительный запрос процесса

У меня есть исследование, освещающее эти проблемы на каждой платформе, я изменяю шансы добавить эту строку кода в конечную точку.

System.Web.HttpContext.Current.Server.ScriptTimeout = 10000; 

Так что теперь он может продлевать до таймаута, но все равно не обрабатывается через 3 минуты 50 секунд. В этот момент я узнал, что есть другая вещь, звоните Load Balancer. Все они говорят, что балансировка нагрузки Azure автоматически уничтожит весь запрос через 4 минуты. Поэтому я застрял на этом месте.

Так что я попробовал все это решение.

1.System.Web.HttpContext.Current.Server.ScriptTimeout = 10000; 2.System.Net.ServicePointManager.SetTcpKeepAlive (true, 30000, 30000); 3.Use Начать новую тему, чтобы обрабатывать длительный процесс и возвращать код состояния http клиенту, чтобы процесс был запущен. 4.Make long process as another async function

То, что я пытаюсь достичь, довольно прост, долгая функция процесса, которая может запускаться по задаче планировщика или вручную (вызов AJAX).

Любое предложение?

+0

Я думаю, что вам нужно, чтобы сломать ваше описание на то, что происходит на конце API-клиента, а затем, что происходит на стороне сервера (или то, что вы хочу случиться) Мне любопытно увидеть более подробную информацию о подходе 3. где вы немедленно возвращаетесь - почему это не удается? –

+0

@ G.Stoynev Конечная точка клиента будет вызовом AJAX, а первый проект - отправить запрос серверу, а затем вернуть сервер после завершения этого длинного процесса, в то время как серверный конец - это весь процесс процесса (проверьте, добавьте данные в база данных, но запись огромна). Для подхода 3 это всего лишь моя глупая идея, поэтому позволяет сказать, что клиент не хочет получать результат, когда процесс выполняется или нет, он получает ответ от сервера и отображает «Процесс запуска» для пользователя. Таким образом, поток будет работать на фоновом режиме, и нет никакого ответа на результат. Любое предложение? –

+0

Как насчет того, инициирует ли клиент вызов Ajax и возвращает сервер HTTP статус, если запрос начал обрабатываться, но не был завершен. На стороне клиента обработчик onsuccess может запрашивать сервер до тех пор, пока он не получит статус http OK, который указывает, что он завершен. Клиент должен знать о синусоиде, чтобы однозначно идентифицировать операцию. –

ответ

1

Так вот как я располагаюсь в этом процессе.

если это длительный процесс запуска, он будет обращаться на веб-работу, я переписать весь процесс в webjob с помощью Azure SDK WebJob на визуальной студии 2015.

Кроме того, для того, чтобы ускорить весь процесс (просто для того, чтобы сэкономить на лазурном кредите), я прямо использую DatabaseContext и делаю каждую требуемую таблицу runnig на ToList() с анонимным типом. Finanlly, я получаю список элементов, которые нужно вставить, и используйте BulkInsert.

Все делается за 3 мин. Время работы Azure с 70 тыс. Записей.

// Обновление для последней реализации

Я до сих пор с помощью WebJob для некоторого фонового процесса, но я могу ускорить процесс, используя EntityFramework BulkInsert, наряду с Parallel.ForEach() моего логического процесса. Кроме того, я также использую Parallel.ForEach() с using(var context=new DatabaseContext()){...} при работе с массовым обновлением. (Существует bulk.update библиотека там обеспечивают хорошее решение тоже)

Кроме того, я стараюсь Azure.Functions, которые кажутся для замены Auzre.WebJob. Это более быстрый запуск, чем WebJob, с использованием того же триггера очереди.

Для всех фоновых процессов у Azure есть несколько решений для вас, просто поделитесь тем, кому это нужно.

  • WebJob
  • Функции
  • Логические приложения
1

Я думаю, что вы нажмете по умолчанию тайм-аут Azure Web Apps (я думаю, что это 3 минуты, если я правильно помню, но могу ошибаться). Не могли бы вы установить SCM_COMMAND_IDLE_TIMEOUT из портала - настройки веб-приложения => настройки приложения => добавить параметр с необходимым значением (скажем 360 (в секундах)). Reference. Существует функциональность, которая будет убивать внешние операции, когда они находятся вне времени (информация находится по ссылке выше).

+1

Как это связано с таймаутом HTTP-запроса? Он говорит, что это значение имеет значение «default», когда процесс сборки запускает какую-либо команду, ему разрешено работать до 60 секунд без создания какого-либо результата. Если этого недостаточно, вы можете сделать это дольше, например, сделать это 10 минут " –

0

Хотя я не отвечаю на большинство ваших вопросов, я решил выразить мнение, что ваш «3.» вариант, чтобы вернуть статус успеха клиенту AJAX, это ваш первый шаг в решении проблемы.

Сетевая инфраструктура, которая реализует трафик TCP/IP/HTTP, недовольна подключениями, которые кажутся пустыми в течение времени, превышающего ваш типичный веб-запрос. Такое поведение чаще всего находится вне вашего приложения (слоя) - на более низких уровнях инфраструктуры. У вас может быть или нет доступ к ним, и если вы это сделаете, вы сможете «исправить» свою проблему.

Использование варианта 3. из вашего вопроса в сочетании с опросом или какой-либо формой push-уведомления - ваше лучшее решение IMO.

Смежные вопросы