Mam pewną aplikację, która wyszukuje odpowiednie folder z plikami i tworzy "resta", który udostępnia te pliki w "jsonie" w postaci tablicy bajtów. Problem jest z wydajnością, jak tych plików jest bardzo dużo np.(1000). Jak by to można było usprawnić. Pobierać tylko np. 100 plików po dacie. Za pomoc z góry dziękuję
0
0
A może 2 serwisy:
- Zwracający metadane, tj. informacje o plikach (URLe do plików)
- Zwracający pojedynczy plik (albo grupę plików)
Klient pobiera metadane, a później interesujący go plik (albo pliki, w ilości nie większej niż N plików jednocześnie).
0
Micheal napisał(a):
Mam pewną aplikację, która wyszukuje odpowiednie folder z plikami i tworzy "resta", który udostępnia te pliki w "jsonie" w postaci tablicy bajtów. Problem jest z wydajnością, jak tych plików jest bardzo dużo np.(1000). Jak by to można było usprawnić. Pobierać tylko np. 100 plików po dacie. Za pomoc z góry dziękuję
Trudno mi wyobrazić sobie normalnego konsumenta JSON z binarną zawartością plików. Nie będzie to JavaScript /przeglądarka ... Co jest klientem?
-
Musi być JSON? Duża sympatią darzę Apache Thrift, testowałem konkuretnta Google ProtoBuf. Generalnie binarny . Zysk w dwóch (trzech) głównych miejscach, brak algorytmu konwersji, mniejsza objętość w sieci (trzeci to GC)
-
Co do REST. Ortodoksyjny REST transmituje stan danych (jeden stan w jednej operacji, server jest bezstanowy), ale nie (powinno) się robić "metod biznesowych". Dobre stare "Remote Procedure Call" nie jest złe, tam niczego nie udajemy, mamy nawiązaną sesję itd.. (RPC w szerokim sensie - w tym Thrift). Twój server i tak ma stan, jak plik zaistniał (i potwierdziłeś to), to nie można udawać, ze go nie ma. Moda na REST/JSON nie jest jedyną religią - a tam gdzie jest to obiektywnie uzasadnione ma nieco inne okoliczności niż u Ciebie
3 i podstawowe, masz jakoś obiektywnie zmierzone, gdzie jest obciążenie? W CPU, sieci itd ???