Я использую поток от HttpWebRequest.GetResponse().GetResponseStream()
для чтения данных из API потокового Интернета. Я использую Begin
/EndRead
в потоке с буфером в 65 Кбайт. Я могу видеть, что данные возвращаются в следующей схеме:HttpWebResponse Чтение потока в неровных фрагментах
16383 bytes read.
1 bytes read.
16383 bytes read.
1 bytes read.
16383 bytes read.
1 bytes read.
etc...
Очевидно, что 1 байт читает ввести много неэффективности в процессе, и размер буфера я обеспечиваю достаточно большой, чтобы вместить 16384 байт или больше. Есть ли что-нибудь, что я могу сделать в качестве клиента для улучшения этого или просто до сервера, как он передает данные мне?
Читатель код в основном:
var buffer = new byte[65536];
using (var stream = response.GetResponseStream()) {
while (true) {
var bytesRead = await AsyncRead(stream.BeginRead, stream.EndRead, buffer);
Console.WriteLine($"{bytesRead} bytes read.");
// do something with the bytes
}
}
где AsyncRead просто вызывает BeginRead(buffer, 0, buffer.Length, callback, null)
, то EndRead
в обратном вызове и возвращает значение, возвращаемое EndRead
.
BTW это на .NET 4.0, нет HttpClient.
Я не уверен, что 1 байт значительно снижает эффективность, так как http-соединение должно оставаться открытым, а передача данных, вероятно, намного медленнее, чем накладные расходы процессора, чтобы читать этот байт. Тем не менее, это странное поведение. Можете ли вы разместить соответствующие фрагменты кода читателя? – Stefan
@Stefan, конечно, это на самом деле F # с использованием другой асинхронной реализации, но я перевел. В асинхронном коде ничего особенного не происходит, он просто передает параметры и возвращает значения as-is. – Asik
Дикие догадки: сжатие или шифрование является виновником. Попробуйте отключить (или включить) компрессию на 'HttpWebRequest'. Аналогично, посмотрите, одинаково ли поведение на «http» и «https». Я считаю, что TLS отправляет данные в куски размером 2^14 байтов (т. Е. 16384 байта). –