Przy zapisie dostaje błąd NoMethodError (undefined method `%’ for nil:NilClass): czyli obiekt nie ma jeszcze id.
Czy użycie http://github.com/netguru/paperclip-extended.git jest konieczne i pomoże. Nie chciałbym obciążać aplikacji pluginami z których korzystam tylko w niewielkiej czesci. Inny pomysł to dodanie w before_create do modelu pola bucket_id i tam losowo liczba 0…3. Jakieś inne pomysły ?
no nie, bo wtedy sciezka do obrazka przy odczycie tez by byla losowa, czyli czasami by sie pokazał Paperclip nie zapisuje sobie nigdzie sciezki do obrazka tylko dynamicznie generują ją na podstawie :path i :bucket (dla S3)
radarek; z tego co gdzieś wyczytałem przegladarka może równocześnie przetwarzać 2-4 requestów z danej subdomeny. W moim serwisie bedzie sporo obrazków w jednym widoku dlatego powinno to teoretycznie dać kopa (każdy bucket to inna subdomena)
Ok, teraz rozumiem (nie zmapowałem sobie w głowie, że bucket można przełożyć na domenę).
[quote=Artur79]witam
Jakieś inne pomysły ?[/quote]
Tak. Zastanów się lepiej czy takie rozdzielenie nie zrealizować na innym poziomie. Otóż pliki ładujesz sobie tak jak do tej pory - 1 bucket. Natomiast stawiasz sobie 1 serwer do obsługi plików statycznych, do których podpinasz sobie swoje domeny images1.example.com, images2.example.com, images3.example.com itp. (ostatnio czytałem, że więcej niż 2 hosty nie dają już żadnego przyspieszenia). Na tym serwerze stawiasz sobie nginxa, który robi jako proxy cache do s3 (google: s3 proxy cache nginx).
W aplikacji musisz sobie za każdym razem losować subdomeny.
Dodatkowy profit? Mniejsze rachunki za s3 (oczywiście trzeba doliczyć serwer obsługujący obrazki, ale spokojnie wystarczy najtańsza maszynka np. w hetznerze by obsłużyć tysiące req/s).
Jeśli Ci zależy, żeby to zrobić szybko i bez bólu to bierz ten plugin i działaj (albo zobacz jak oni to zrobili i wyciągnij z niego tylko tą zmianę).
Losowanie subdomen w plikacji, możesz zrobić prościej i automagicznie: podpinasz domeny images{0,1,2,3}.domain.com pod serwer plików statycznych i w pliku config/production.rb dopisujesz:
Tylko, że z tego co wiem nie jesteś w stanie tego podpiąć pod buckety w s3 bo domena jest mapowana do hosta (czyli obrazek serwowany z adresu images1.example.com będzie szukany w buckecie /images1.example.com na s3.
przykładowy zastosowanie z opisu pluginu paperclip-extended:
:bucket => lambda do |attachment|
i = attachment.instance.id % 4
"bucket_#{i}"
end
zwraca błąd: tried to create Proc object without a block
Po zmianie na
Niestety zarówno z pluginem jak i bez dostaję błąd przy próbie zapisu
czyli id nie jest jeszcze ustalone w momencie próby ustawienia bucketa. Plugin jest z 2008 więc możliwe że zarówno w Railsach jak i w Paperclipie od tego czasu sporo się zmieniło.
Pytanko apropo samego paperclipa, czy jest sens posiadania dalej w bazie kolumny image_file_name jeśli nazwy i tak ustawiam przy zapisie thumb.jpg itd… Domyślam się że inne kolumny jak image_content_type czy image_file_size mogą być do czegoś uzywane
Radarek spodobał mi się Twój pomysł. Pracujemy razem z Arturem przy projekcie tak więc podpytam troszkę.
Sama nazwa proxy cache i to co google wypluwa wskazują, że obrazy będą pobierane z tego serwera pośredniego, o ile wcześniej obsłużył on już taki request?
Jeśli tak to:
Podoba mi się w tym rozwiązaniu to, że wszystko trzymamy w jednym buckecie i łatwo można dodawać / zmieniać subdomeny.
Nie podoba mi się to, że trzeba poświęcić czas i finanse na konfigurowanie dodatkowego serwera (tam także transfery będą zjadane, a to dlatego S3 jest wykorzystywane).
Być może są inne zalety, których nie widzę? Uwagi na ten temat będą bardzo dla nas cenne, gdyż chcemy tą kwestię dobrze rozwiązać przed odpaleniem.
Idealnym rozwiązaniem byłby jakiś router, który obszedłby ograniczenia ‘jedna subdomena=jeden bucket’ a jednocześnie przeglądarka widziałaby requesty dla różnych subdomen - bez potrzeby utrzymywania osobnej maszyny.
Proxy cache to server siedzący pomiędzy klientem, a jakimś backendowym serwerem (w tym wypadku s3). Dla klienta nie jest istotne to, że backend istnieje. Łączy się z serwerem proxy i pyta o jakiś zasób (plik). Jeśli plik o który pyta jest na serwerze proxy to ten plik jest mu odsyłany, jeśli nie ma to proxy pobiera go z backendu (tutaj nasze s3) i odpowiednio keszuje (jeśli pliki które pobiera nie mogą być keszowane przynajmniej na pewien czas to zastosowanie proxy cache mija się z celem).
[quote=Snafu]Jeśli tak to:
Podoba mi się w tym rozwiązaniu to, że wszystko trzymamy w jednym buckecie i łatwo można dodawać / zmieniać subdomeny.[/quote]
Zgadza się. Ponieważ na serwerze proxy możesz postawić dowolny serwer (nginx) albo dedykowane narzędzie (varnish/squid) to możesz też dokonać rewritu urli.
Serwer trzeba skonfigurować - to fakt. Ja znając tylko temat w teorii byłem w stanie poczytać i skonfigurować nginx w ciągu 1 dnia roboczego. Jak na “administratora” z doskosu chyba nie tak źle :). Co do transferu to właśnie koszta Ci zmaleją (zwłaszcza jeśli mówimy tu o s3, które liczy zarówno za transfer jak i requesty). Dlaczego? Dlatego, że jeśli odpowiednio będziesz keszować obrazki (wystarczy podejść do tematu na zasadzie: unikalny obrazek - unikalny adres uri) to proxy pobierze z s3 tylko raz obrazek. Zatem stawiając instancję na ec2 jesteś w stanie obniżyć rachunki o koszt requestów (oczywiście płacisz dodatkowo za instancję, ale ta najtańsza za 80$ jest w stanie obsłużyć na luzie tysiące requestów na sek/700Mbit ruchu wychodzącego).
Minusem waszego podejścia (różne subdomeny) jest to, że jeden obrazek może mieć kilka adresów. Wtedy transfer Wam odpowiednio wzrośnie. No chyba, że na sztywno przydzielacie subdomenę do obrazka to wtedy nie ma tego problemu.
Dodatkową zaletą jest także fakt, że gdyby z jakiegoś powodu server proxy padł to możecie zmienić w aplikacji opcję, która mówi czy generowane adresy mają być do hosta proxy cache czy też bezpośrednio na s3.
Dla nas (AdTaily) to były przede wszystkim koszta. Dzięki zastosowaniu proxy cache (1 mała instancja na ec2) nasze koszta amazonowe zmalały o jakieś 60% (serwujemy bardzo dużo małych (5-20kb) plików, więc koszta requestów na s3 były spore).
Możesz spokojnie na początku postawić ten serwer na tej samej maszynie co aplikacja. Taki statyczny ruch zjada bardzo mało cpu (oczywiście mówię tu o nginx albo varnishu, o apache należy zapomnieć).
Dzięki wielkie za informacje. Myślę, że temat został wyczerpany więc pozostaje przemyśleć i podjąć decyzję.
Do kwestii opłat za requesty nie przykładaliśmy aż tak uwagi (marginalizowaliśmy je), ale faktycznie jeśli tak dokładni to przeliczyć mogą być znaczące.
Na razie będzie zatem jeden bucket i w miarę rozkręcania (a nadzieje są ) zaczniemy stosować ten proxy - przypiszemy subdomeny do obrazków naturalnie tracąc przez chwilę cachowanie u tych co już nas odwiedzili (obrazki będą u nich musiały na nowo się wczytać z nowych adresów).
Paperclip nie zapisuje sobie nigdzie sciezki do obrazka tylko dynamicznie generują ją na podstawie :path i :bucket (dla S3)