Potrzebuje wysłać http, kluczem jest aby to byl mozliwie najszybszy strzał włącznie z deserializacją response do obiektu. Znacie biblioteki, które bylyby w tym wyjątkowo dobre?
Czego użyc do serializacji/deserializacji, Kryo ? Czy netty daje tutaj duży zysk? W moim rozumieniu to jest nio wiec przy jednym strzale, bądź strzałach które muszą iść po sobie, nie ma to znaczenia, czy dobrze mysle ?
0
0
Najlepszy sposób na szybki HTTP to nie używać HTTP (po pierwsze, ze ma znaczne koszty / strzał)
Komunikować się np Apache Thriftem
jedynym bezspornym argumentem za HTTP jest jego powszechność i przenośność (no dobra, ręczne debugowanie) - bawiąc się z serializacją, przesyłąjąc binaria (w body - w nagłówkach tekstowo) i tak to wykluczasz.
1
Trochę z drugiej strony (ale bindowanie jsona też się pojawia):
0
@AnyKtokolwiek: Nie mam kontroli nad tym. Musi to byc po Http.
Sprawdze jackson streaming api. Czy po stronie bibliteki http da sie tutaj cos strasznie optymalizowac? Wiekszosc opoznien to bedzie i tak siec
3
Czy po stronie bibliteki http da sie tutaj cos strasznie optymalizowac?
No możesz walić gołym socketem zawsze, przynajmniej dla HTTP. Nie jest to jakoś specjalnie złożone, ale nie wiem czy warto.
2
Nie sądzę żeby wybór klienta HTTP miał większe znaczenie przy performance, bardziej skupiłbym się na:
- upewnieniu się że komunikacja odbywa się z
Connection: keep-alive, tzn. reużywane są połączenia TCP dla kolejnych requestów (nawiązywanie połączenia jest najbardziej kosztowne). - ogarnięciu ile równoległych połączeń TCP serwer jest w stanie tolerować, większość porządnych klientów HTTP wspiera konfigurację connection poola
- skonfigurowaniu opcji samych połączeń TCP (być może ustawienie takich rzeczy jak rozmiar buforów socketa będzie miało jakiś wpływ)
- wydajnym przyjmowaniu response body (w miarę możliwości użycie parsera strumieniującego (Jackson wspiera takie parsowanie dla JSON, dla XML może być prymitywny SAX/Stax) - generanie unikać ładowania wszystkiego do pamięci i konwertowania do obiektów bo jest to kosztowne
- utrzymywać thread pool o rozmiarze równym connection pool i robić synchroniczne IO - takie biblioteki jak Netty są pod NIO i oferują dużą skalowalność ale asynchroniczność oznacza context switching i dodatkowy koszt
Tak jak @Shalom powiedział, możesz spróbować własnego prymitywnego klienta HTTP jeśli komunikacja jest naprawdę prosta (brak proxy, redirect, chunked encoding, multipart) i wtedy olewasz większość headerów (ale także security checków typu maksymalny rozmiar headera - trzeba uważać) ale nie spodziewałbym się jakichś spektakularnych zysków a trochę dłubania jest.