Optymalny rozmiar bufora dla strumienia odpowiedzi HttpWebResponse

Question

Jaki jest optymalny rozmiar bufora do użycia ze strumieniem z HttpWebResponse.GetResponseStream()?

Przykłady online różnią się od 256b do nawet 5Kb. Co daje? Myślę, że rozmiary buforów mogą być sytuacyjne. Jeśli tak, jakie są sytuacje, aby użyć jakiego rodzaju rozmiaru bufora?

Dzięki.

Answer 1

Naprawdę, nie ma to większego znaczenia.

Oczywiście, jeśli używasz naprawdę małych buforów, być może będziesz musiał wykonać kilka dodatkowych wywołań przez warstwy, aby uzyskać bajty (chociaż strumień prawdopodobnie przynajmniej buforuje - nie wiem, co to jest wartości domyślne to). I na pewno, jeśli użyjesz naprawdę dużych buforów, zmarnujesz trochę pamięci i wprowadzisz fragmentację. Ponieważ oczywiście robisz tutaj IO, za każdym razem, gdy zyskasz przez ulepszenie buforów, będzie to zdominowane przez czas IO.

Zgodnie z ogólną zasadą, używam potęgi dwóch od 2048 (2k) do 8192 (8k). Tylko upewnij się, że wiesz, co robisz, jeśli użyjesz bufora równego lub większego niż 85 000 bajtów (to jest wtedy "large object" and subject to different GC rules).

W rzeczywistości ważniejszy niż rozmiar bufora jest czas jego przechowywania. W przypadku obiektów spoza sterty dużych obiektów, GC jest bardzo dobry w radzeniu sobie z bardzo krótkotrwałymi obiektami (zbiory Gen 0 są szybkie) lub obiektami bardzo długowiecznymi (Gen 2). Obiekty, które żyją wystarczająco długo, aby dostać się do Gen 1 lub 2 zanim zostaną uwolnione, są względnie droższe, a zwykle o wiele bardziej warte są twoje czasy, niż martwienie się o to, jak duży jest bufor.

Ostatnia uwaga: jeśli uważasz, że masz problem z wydajnością ze względu na rozmiar używanych buforów, test to. Jest mało prawdopodobne, ale kto wie, może masz dziwną zbieżność wersji systemu operacyjnego, sprzętu sieciowego i wydania sterowników, która ma dziwny problem z buforami o pewnej wielkości.

Answer 2

Moje anegdotyczne doświadczenie polega na tym, że naprawdę zależy od tego, co robisz, ale zazwyczaj wszystko w zakresie 1024-4096 bajtów (1-4 kB, czyli dwie potęgi) dałoby mi porównywalną wydajność (4KB to "najlepszy" numer, jaki widziałem).

Zasadniczo potrzebujesz bufora wystarczająco dużego, abyś nie musiał niepotrzebnie odczytywać danych ze strumienia, ale nie tak dużych, że zmniejszysz zwroty. Jeśli twój bufor jest zbyt duży (~ MBs), zwiększysz ilość pamięci podręcznej w pamięci, co może zacząć zmniejszać wydajność. Oczywiście jest to bardzo różne w zależności od rzeczywistego H/W (prędkość magistrali, rozmiar pamięci podręcznej, itp.), Ale wydaje mi się, że bufor 4 MB był wolniejszy niż bufor 4KB (oba przypadki miały długi czas życia, więc GC nie było problem).

Jak zauważa Jonathan, przetestuj swoją obecną implementację przed próbą przedwczesnej optymalizacji.

Answer 3

Właściwie to mam problem, gdy rozmiar bufora jest za mały. Przetestowałem to i ZWERYFIKOWAłem, że rozmiar bufora nie powinien być ustawiony na małą wartość. W moim przykładzie ustawiłem go na 2048, a pobieranie staje się BARDZO SLOW w porównaniu do Firefoxa (Firefox jest bez segmentacji pobierania, tak samo jak moje).

I po ustawieniu go na duży rozmiar 409600, pobieranie jest DUŻO SZYBSZY, myślę, że dodatkowe połączenie będzie kosztować narzut lub takie, które spowalnia pobieranie. Być może na poziomie sieci bufor przekracza Twój rozmiar bufora, więc TCP musi poprosić o ponowne wysłanie paczki? (Tylko przypuszczenie, ponieważ nie wiem jak działa TCP), jednak mały rozmiar bufora zdecydowanie spowalnia moje pobieranie. Przetestowałem go, uruchamiając domyślne pobieranie Firefoxa (bez dodawania i segmenetacji) i używając mojej klasy, oba są zdecydowanie zbyt różne.

Teraz jest znacznie szybszy, za każdym razem, gdy się zapętli, odczyta około 200000 bajtów (200Kb), ponieważ połączenie tutaj jest ciche, ale po uruchomieniu dwóch wątków będzie znacznie wolniej, prawdopodobnie trzeba będzie udostępnić kolejny wątek.