2012-02-24 16 views
5

Umieszczę dużą liczbę małych elementów w S3 przy użyciu REST API. Średnia ładowność wynosi ~ 10 bajtów. wszystkoAmazon S3: maksymalna liczba żądań PUT na sekundę

Pozycje idą do jednego wiadra, i randomizacji nazwy (czyli nie ma porządku leksykograficznym)

Od EC2, udało mi stopę 4-500 na sekundę. Używam puli wątków 96 wątków, z 64 połączeń TCP.

Od czasu do czasu otrzymuję HTTP 500, ale nie otrzymałem jeszcze 503 - oznacza to, że klient spowalnia tempo żądań.

Czy ktoś wie, co mogę realistycznie osiągnąć? Wiem, że rura między EC2 i S3 może zarządzać przepustowością 20 MB/s, więc mam nadzieję, że zrobię trochę lepiej.

Odpowiedz

1

Nie powinno być niespodzianką, że widzisz słabe wyniki przy użyciu usługi REST w celu przesłania takich małych ładunków.

Sposobem na lepsze jest zrestrukturyzowanie natury protokołu lub pamięci masowej, aby nie nałożyć na nią dominujących kosztów transakcji.

Rzeczywiście, rozmiar potoku jest nieistotny dla twojego pytania, ponieważ wypełniasz go całkowicie kosztem HTTP; na przykład, jeśli możesz podwoić przepustowość połączenia, możesz wysłać dwa razy więcej bezużytecznego narzutu, nie zmieniając w żaden sposób użytecznych danych.

+1

Zdaję sobie sprawę, że większość przesyłanych danych to informacje HTTP. Nie mam kontroli nad protokołem; S3 to tylko REST i HTTP. Niestety nie ma funkcji wsadowej do S3 i ze względu na charakter mojej aplikacji; pakowanie małych kawałków danych w duże nie jest wykonalne. – user756079

+0

Czy istnieje powód, dla którego nie umieszczasz tych rzeczy w SimpleDB, który obsługuje operacje wsadowe wsadowe? Czy muszą być dostępne przez HTTP bezpośrednio? – Daan

+0

@ user756079 - Wiem, że nie masz kontroli nad protokołem transportowym, ale masz kontrolę nad tym, co wysyłasz przez ten kanał. Ponieważ istnieje czynnik, którego nie możesz zmienić, musisz pracować z tym, co możesz, co oznacza ponowne przemyślenie treści (i rozmiaru) twojego ładunku. – msw