У нас есть DLL, которая используется в качестве промежуточного уровня между клиентской частью нашего веб-сайта и внутренней системой продажи билетов. Метод вставки в систему продажи билетов немного сложен для объяснения, но краткая версия заключается в том, что он медленный. Лучший сценарий, который у меня есть, - это время отправки 9 секунд.
Однако настоящая проблема в том, что я могу получить это время только через приложение Windows, а не через веб-сайт ASP.NET. Я установил и тестовое приложение Windows, и веб-страницу для тестирования, и хотя код копируется между ними, веб-страница последовательно отправляется через 17-20 секунд, в то время как приложение Windows получает 8-11 секунд.
Что могло быть причиной этого?
Обновлено: В ответ на пару ответов ...
Вызов веб-службы занимает большую часть времени, но я не могу контролировать эту веб-службу, поскольку она предоставляется поставщиком системы продажи билетов. Мне нужно выяснить, почему веб-служба занимает разное количество времени, когда ее вызывают из другого типа приложения. Код в обоих случаях одинаков, и он запускает цикл, а затем сообщает записанное время.
Код такой:
for (int i = 0; i < numIterations; i++)
{
startTimes[i] = DateTime.Now;
try
{
cvNum = Clearview.Submit(req, DateTime.Now, DateTime.Now, false);
}
catch (Exception ex)
{
exceptionCount++;
lblResult.Text += @"<br />Exception Caught: " + ex.Message + @"<br />";
}
endTimes[i] = DateTime.Now;
}
Это один и тот же цикл в обоих случаях, и я отмечаю время прямо до и после вызова библиотеки, которая выполняет дальнейшую обработку, а затем вызывает веб-службу. Но такая обработка должна быть последовательной, не так ли? Я проследил во время отладки и не заметил никакой задержки до фактического вызова веб-службы ...
РЕДАКТИРОВАТЬ снова: работая с муравьями, в обоих случаях 99,4% времени отправляется только при вызове веб-службы. Кажется, там нет никакой разницы ... за исключением того, что по истечении времени ожидания веб-страница занимает больше времени, чем приложение Windows.
Вы используете HttpWebRequest, сгенерированный Reference.cs, клиентский веб-клиент JavaScript или что-то еще?
Тестирование между двумя разными бэкэндами веб-сервисов: сгенерированным Reference.CS в одном случае и WebClient в другом. Ссылка создается в .DLL, используемом как приложением Windows, так и веб-страницей.





Добавьте к своему приложению логи с обеих сторон - они покажут вам, куда идет время. Если это не помогает, используйте Wireshark для отслеживания сетевой активности.
Возможно, возникла проблема с расположением веб-службы по отношению к веб-серверу. Кроме того, структура страницы и другая обработка в вашем веб-интерфейсе могут влиять на то, сколько времени требуется приложению для обработки.
Как уже упоминалось, элементы ведения журнала с обеих сторон - отличная идея, если это не дает вам того, что вам нужно, вы можете попробовать профилировщик производительности, такой как Ants Profiler от Red Gate, который может помочь идентифицировать строку, метод или класс, которые используют большую часть времени.
Я только что добавил отредактированную дополнительную информацию. У меня нет доступа к внутренним компонентам веб-службы, но я не уверен, почему это все равно имеет значение ...
Кроме того, поскольку я тестирую на своем рабочем столе, веб-сервис находится в одном месте для обоих клиентов ...
В этом случае я бы посмотрел на Ants Profiler, посмотрел на время выполнения цикла. Кроме того, в одном случае возникает больше исключений, чем в другом? Исключения обходятся дорого.
Играем с Муравьями, но никаких исключений не выбрасывают.
Хорошо, посмотрим, смогут ли муравьи между двумя приложениями выделить одну конкретную строку, для которой требуется больше усилий.
Как я и подозревал, это вызов веб-службы. 99% времени уходит только на один звонок ...
Вы используете оба на одной машине? Находится ли вызываемый вами средний уровень на удаленном компьютере? Временные интервалы, которые вы упомянули смутно, напоминают проблему тайм-аута DNS, когда открытие соединения влечет за собой штраф за первый (неработающий / неверный) ответ DNS на тайм-аут. Вы уверены, что любой файл конфигурации / var, указывающий DLL на средний уровень, одинаков в обоих вызовах?
Я поддерживаю предложение использовать Wireshark, чтобы увидеть, что происходит. По крайней мере, вы можете убедиться, что время внутренней обработки (в любом случае должно быть) одинаковым ...
Это была проблема конфигурации, одна отправлялась в производственную систему, хотя обе использовали правильную веб-службу. Разница во времени была из-за того, насколько загружена база данных prod. Честно говоря, не знаю, почему это вообще сработало ... Спасибо!
какие Windows и веб-клиенты вы используете для веб-служб?