witam
chciałbym zliczać i wyświetlać dla użytkowników unikalne wizyty, nie dla wszystkich odwiedzanych stron w serwisie ale dla dwóch wybranych akcji z dwóch kontrolerów. Prosiłbym o jakieś porady jak to najzgrabniej rozwiązać i nie obciążać za bardzo aplikacji. Nie musi być to aktualizowane na bieżąco, moga być spokojnie opóżnienia, chodzi o samą skale odwiedzin a nie dokładne liczby ? Rack a może coś innego ?
To może po prostu Google Analytics?
ale ja chcę to użytkownikowi wyświetlać normalnie w widoku
Proszę:
http://code.google.com/intl/en/apis/analytics/docs/gdata/gdataDeveloperGuide.html
http://www.embeddedanalytics.com/
Coś o jak najmniejszym koszcie włożenia. 
Na myśl przychodzi mi Redis lub Mongo. To pierwsze jest o tyle fajne, że może być w całości pamięci (raz na jakiś czas backend zbiera całość i zapisuje już do “normalnej” bazy) i operacje inkrementacji czy dołożenia do listy są obywatelami pierwszej klasy w Redisie. To drugie jest o tyle fajne, że można robić zapis nieblokujący, bez czekania na potwierdzenie (czyli o szybkości jaką ma socket.write, znaczy rewelacyjnej).
Jeżeli nie musisz mieć wyników real time, to ja bym użył google analytics + API. Jeżeli muszą być real time, to kusząco brzmi to co Tomash napisał. Z wykorzystaniem redisa lub mongo powinno być szybko i w miarę prosto.
W razie czego do google analytics najprościej jest użyć Garba: http://www.viget.com/extend/introducing-garb-access-the-google-analytics-data-export-api-with-ruby/ (poprawcie mnie jeżeli coś nowszego i fajniejszego wyszło)
dzięki za porady, może wyżej nie wyjaśniłem dokładnie, chodziło mi tylko o ilość wizyt, nie o jakies zaawansowane staty
No i w GA to sobie jesteś w stanie liczyć. Nie musisz stawiać żadnych serwerów, odpalać procesów itp. Przez API co jakiś czas możesz pobierać sobie te wartości, które Cię interesują.
i tak będę używał w serwisie GA więc może to być dobry wybór. Widział bym to w ten sposób że odpalam powiedzmy cronem co 10-30 minut zadanie rake, ono za pomocą tego gema http://github.com/vigetlabs/garb łączy sie z GA i odpytuje o ilosc wizyt dla danej strony (strona to rekord w danym modelu, np user profile, mam w bazie permalink wiec url to nie problem) i wtedy w bazie w polu views_count wpisuje aktualną wartośc. Nie zmuli bazy taka ilosc updejtów jednoczenie, jesli np było by to np pare tysięcy wierszy ? A co myślicie o użyciu tego żeby wyświellic ilu użytkowników przegląda aktualnie daną stronę ?
Jeśli potrzebujesz w miarę te dane realtime to jednak GA odpada, gdyż dane pojawiają się tam z opóźnieniem 24-48h. Zasugerowałem Ci to narzędzie bo myślałem, że potrzebujesz to jako statystyczny wgląd.
Update kilku tysięcy rekordów na w miarę dobrej maszynie to pikuś.
My w firmie w programach afiliackich nazywamy to hitami. Afiliat ma swoj landing page. Taki landing page moze byc w wielu produktach np. (nasze) GetResponse, ClickMeeting, … i tamta strona - produkt rzuca posta do systemu afiliackiego: taki user, taka strona, taki czas - jebs. Raz na jakis czas rake task agreguje te hity do innej tabeli i wyswietla afiliatowi w panelu. Zwykly POST, zapis do MySQL i potem przeoranie danych. Dziala bez bawienia sie w redisy i mongo. BTW w mongodb jest increment, ktory fajnie dziala z takim use casem. Jeśli nie będziesz mial fefdyriardów odsłon to czemu czemu nie zapisywac takich odslon u siebie w bazie?
24h to może jednak być trochę za rzadko 
Jeśli u siebie to poprostu osobna tabela views i tam pole na ip, ponieważ pasuje żeby to było unikalne, wtedy przy wrzucaniu do views sprawdzam czy już jest coś dla danego ip starsze niz powiedzmy doba. Potem co pare minut rake task z crona który to sumuje i wrzuca np do Users.profile_views, Page.page_views itp. W jaki najmniej obciążający serwis sposób popychać te dane do views ? Jakiś middleware czy może coś w tle (żeby nie czekać z wyświetleniem strony aż sprawdzi czy już było ip i zapis do views) ? Używam delayed_job do poczty ale do czegoś takiego to byłaby raczej za duża armata.
Wolałbym własnie u siebie bazie, narazie te staty będą może dla 2-3 ścieżek. Pytanie tylko co by było szybsze. Opcja pierwsza to podczas wejscia na daną ścieżkę INSERT do tabeli views, czas, która ścieżka i IP. Czy też może jakies middleware która sprawdza czy jest już wpis dla danej ścieżki i IP i dopiero jak nie ma to dodaje. Dla obu wersji rake task co pare minut który sumuje ilość wejść i updejtuje pole Model.views_count.
Podejrzewam że zwykłe increment_counter mogło by powodować przekłamania lub coś przymulać gdyby w danym momencie wchodziłoby wiele osób na daną ścieżke.
Coś jak tutaj to dobry przykład tylko u mnie raczej IP niż sesja http://charlesmaxwood.com/rails-metal-example-7-tracking-analytics/ Nie rozumiem tylko czemu tam jest 404 zwracane, skoro powinniśmy przekazać request do kolejnej warstwy.
Kolejne pytanie czym się różni i jakie są korzyści używania Rails Metal od zwykłych zadań rack middleware ?
Premature optimisation. KISS.
Może być dużo wejść dla danej pozycji, dlatego nie sądze żeby to było prematur optimisation. Ktoś wchodzi na podstrone, sprawdzane jest w tabeli views czy jest już jego ip dla danej strony, jeśli nie ma to dodawane to jest do tej tabeli i w głównej tabeli modelu jest updejtowany licznik, tak że to już są 3 zapytania przy każdym wejściu a ktoś może łazić tam i spowrotem Inna opcja czy coś takiego można by zrobić np w tle spawn, workling albo delayed_job ? Najlepiej chyba żeby jakis prosty skrypt chodził w tle i do niego wysyłać potrzebne dane. Czym najlepiej to ugryźć ?
No to może liczniki dla ścieżek trzymać w memcachedi przepisywać do tabeli w bazie danych zadaniem cronowym np. co godzinę.
co godzinę jednak troche mało, nie musi to być na żywo ale chciałbym żeby opóźnienie było jak najmniejsze, najlepiej od kilkunastu sekund do minuty. Żeby jednak ktoś kto wejdzie na rzadko odwiedzaną podstrone widział jak wróci efekt w ilości odwiedzin
Artur79 to zrzucaj to do DelayedJoba.
też o tym myslałem, używam go do maili, zaniepokoia mnie tylko wzmianka w tym wywiadzie http://rubysfera.pl/2010/6/wywiad-z-damianem-legawcem-gametrade-pl/ że dj może zamulić, niestety nie sprecyzowano dlaczego i co konkretnie. Wydawało mi się ze delayed job to bardziej do zadań wywoływanych czasami ale długich a to moje zlicznie to jest krótko ale bardzo często Akurat te 2 widoki gdzie będzie się to odbywać są kluczowe w serwisie
Dlatego mówiłem o memcached - co może być szybszego od pamięci? Baza danych też powinna dać radę - jak zrobisz prostą tabelę url-licznik wizyt. Ile masz tych wizyt na sekundę? Jakie masz serwery? Jeśli mówimy o wydajności daj nam chociaż jakieś dane szacunkowe. Mówienie o wydajności kodu bardziej rozbudowanego niż zadanie ze SPOJa bez znajomości środowiska, w którym będzie uruchamiany, IMHO naprawdę mija się z celem.
Delayed job naprawdę nie do tego służy.