WEB API передача большой инфы

[shadow7256]

Уважаемые,

Есть ASP.NET MVC WEB API проект. Есть метод который принимает объект класса (ну понятно дело клиент передает XML версию этого объекта и WEB API создает сам объект, наполняет его из XML и передает в метод).

Сегодня поставил опыт, передал XML размером примерно 160КB (там изображения закодированые были в Base64).

Пользую Фиддлер для передачи инфы. Так вот, время, между тем как я передал из Фиддлера и когда сработал брекпоинт в начале WEB API метода было больше одной минуты

Это вообще нормально что так медленно это дело все? как то это дело можно ускорить? кто то на работе намекнул как работает DropBox API, там как то по частям вроде передается все..

Если есть опыт поделитесь
Спасибо

[Palych]

время, между тем как я передал из Фиддлера и когда сработал брекпоинт в начале WEB API метода было больше одной минуты

Это значит что прежде чем передать управление API, сервер прочитал содержимое запроса согласно Content-Length. А канал наверное медленный...
Или это на локальном сервере?

[shadow7256]

это на локальное машине моей. Да, по умолчанию, прежде чем управление передается в контроллер все содержимое заносится в буфер в память. Но тратить больше минуты чтобы буферизовать 160К данных локально ?

[Palych]

А если уменьшить размер данных в 2, 10, 1000 раз - задержка пропадает?
CPU занят в это время?
Может это антивирус проявляет бдительность?

[shadow7256]

Если уменьшить размер данных задержка пропадает конечно. Чем меньше данных, меньше задержка.

Как только посылаю большой пакет из Фиддлера то в списке процессов вижу что резко подтягивается msvsmon.exe (жрет порядка 12-15 процентов проца). Как только управление доходит до контроллера то msvsmon.exe "успокаивается".

[mynameiszb]

У нас для ASP.Net ставили эксперименты по передачи больших данных - по 100-200 мг. В итоге - перетряхнули все возможные варианты и поняли, что придется некий свой буферизатор писать, чтобы сливать с сервера маленькими кусками с буферизацией. Все остальное "штатное" - падает в произвольных местах.

[shadow7256]

У нас для ASP.Net ставили эксперименты по передачи больших данных - по 100-200 мг. В итоге - перетряхнули все возможные варианты и поняли, что придется некий свой буферизатор писать, чтобы сливать с сервера маленькими кусками с буферизацией. Все остальное "штатное" - падает в произвольных местах.

походу что то подобное и нам надо будет походу (( Если бы TCP был как транспорт для endpoint то там можно выставить ReceiveMode = Streamed, но для HTTP это не канает

[Boriskin]

Мы для похожих задач пользуем стандартный https и libCURL, но у нас на обоих концах свои собственные компоненты в купе с OS specific инфраструктурой. Катали файлы до пары гигабайт, все пучком.

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

[shadow7256]

Не совсем понял про передачу файлов. Ситуация такая. Есть класс и метод в WEB API который принимает объект этого класса:

Code: Select all

[Serializable]
public class Person
{
     public string Firstname {get;set;}
     public byte [] Image {get;set;}
}

[HttpPost]
public void ImportPerson (Person person)
{
}

я из Фиддлера составляю запрос и посылаю XML версию этого объекта в теле. Ну что то типа:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<Person>
   <Firstname>Vasya</Firstname>
   <Image>asdf79a8s79asdf987asd9879asdf</Image>
</Person>

так вот когда данные в массиве Image небольшие то все быстро.. а если там 160КВ байтов то перед тем как управление перейдет в ImportPerson занимает больше минуты

[Boriskin]

Да, немного не о том подумал.
Судя по такой дикой задержке проблемы на сервисе - либо клинит при буфферизации (типа чего то ждет для выплевывания данных наружу), либо просто банальный сетевой таймаут где-то, там как раз имхо 30 секунд по умолчанию, если ничего не подшаманивать.