Temat: Propozycja wydajnego rozwiązania

Witam.

Zastanawia mnie pewien problem i ciekaw jestem czy ktoś ma propozycję WYDAJNEGO rozwiązania.

Chodzi mi o licznik odświeżeń skryptu na stronach (odporny na odświeżanie). Załóżmy, że na określonej liczbie stron (500) mam swój skrypt X oraz posiadam bazę danych z:

- tabela 1 z polami: WEBSITE_ID, COUNTER,
- tabela 2 z polami: IP, TIME.

Za każdym razem, gdy ktoś wejdzie na określoną stronę (WEBSITE_ID) nasze pole COUNTER zwiększa się o +1 pod warunkiem, że określone IP nie wystąpiło w ostatniej godzinie (pole TIME).

Teoretycznie proste i skuteczne rozwiązanie do zliczania wyświetleń mojego kodu na wielu stronach internetowych.

Co jednak w przypadku dużego ruchu na wielu serwisach? Czy spowodowany tym ruch i ilość zapytań do bazy nie "rozwalą" jej? Ma ktoś może bardziej wydajny pomysł? Czy wykorzystanie innego języka niż PHP (Python?) może w tym wypadku się opłacać?

Jestem ciekaw Waszych propozycji i z góry dziękuję za konstruktywne wypowiedzi.

Pozdrawiam.Piotr Parzentny edytował(a) ten post dnia 24.10.09 o godzinie 12:09

Temat: Propozycja wydajnego rozwiązania

Piotr Parzentny:
Zastanawia mnie pewien problem i ciekaw jestem czy ktoś ma propozycję WYDAJNEGO rozwiązania.

Chodzi mi o licznik odświeżeń skryptu na stronach (odporny na odświeżanie).

Jak bardzo ma być odporny i jak bardzo wydajny? Możesz po prostu otworzyć sesję i sprawdzać czy istnieje przed zapisem do bazy. Ale wtedy użytkownik może wyrzucić ciasteczka. Możesz też połączyć obydwie blokady, bo wtedy jak jest sesja to nawet nie sprawdzasz bazy, a jak nie ma to sprawdzasz najpierw ip i znowu sesję zakładasz. Szczególnie dobre, jeśli sesji używasz już do czegoś innego.

Załóżmy, że na określonej liczbie stron (500) mam swój skrypt X oraz posiadam bazę danych z:

- tabela 1 z polami: WEBSITE_ID, COUNTER,
- tabela 2 z polami: IP, TIME.
Za każdym razem, gdy ktoś wejdzie na określoną stronę (WEBSITE_ID) nasze pole COUNTER zwiększa się o +1 pod warunkiem, że określone IP nie wystąpiło w ostatniej godzinie (pole TIME).

Jeśli tabela 2 jest zindeksowana wg. IP a tabela 1 wg. WEBSITE_ID, to będzie szybkie oczywiście.

Tylko po co to robić tak naprawdę ;) Counter to kiepska statystyka czegokolwiek - nie lepiej założyć konto na google-analytics np.?

PS. Twój counter nie jest precyzyjny. Tabela 2 powinna też mieć WEBSITE_ID. Bo inaczej jeśli ktoś wejdzie z 1.2.3.4 na abc.com, a potem na def.com w ciągu kilku min, to na def.com nie zostanie policzony.

Temat: Propozycja wydajnego rozwiązania

Stanisław Pitucha:
Jak bardzo ma być odporny i jak bardzo wydajny? Możesz po prostu
otworzyć sesję i sprawdzać czy istnieje przed zapisem do bazy.
Ale wtedy użytkownik może wyrzucić ciasteczka. Możesz też połączyć obydwie blokady, bo wtedy jak jest sesja to nawet nie
sprawdzasz bazy, a jak nie ma to sprawdzasz najpierw ip i znowu
sesję zakładasz. Szczególnie dobre, jeśli sesji używasz już do czegoś innego.

Odporny naturalnie, ale przede wszystkim wydajny! Załóżmy, że mam 500 serwisów, a każdy ma 50.000 odświeżeń to daje mi 9,6 requestów na sekundę! Sporo.

Jeśli tabela 2 jest zindeksowana wg. IP a tabela 1 wg. WEBSITE_ID, to będzie szybkie oczywiście.

Jak bardzo? Do jakiej granicy? Jak to sprawdzić?

Tylko po co to robić tak naprawdę ;) Counter to kiepska statystyka czegokolwiek - nie lepiej założyć konto na google-analytics np.?

Też o tym myślałem! Pytanie tylko o dokładność tych danych i dostęp. Te narzędzie jest darmowe do komercyjnego zastosowania? Poza tym wydaje mi się, że counter tutaj może się sprawdzić. Ja nie chcę mierzyć oglądalności samego serwisu tylko wywołania mojego skryptu na stronce. Może na jakimś przykładzie: webmasterzy dodają do swoich stronek kawałek kodu, który pobiera zmojego serwera załóżmy kurs Euro/PLN :) Chcę zliczyć ile razy na poszczególnych serwisach ludzie widzieli te moje dane indywidualnie (UU) oraz ogólnie ile było wyświetleń. Tylko tyle. Problem moim zdaniem to ta olbrzymia ilość wywołań do bazy. Muszę sprawdzić czy IP w bazie, porównać z aktualnym IP usera ogladającego i później ewentualnie dodać wartość +1 do pola COUNTER. Jak to zrobić najwydajniej? Czy skrypt obsługujący to w Pythonie będzie dużo bardziej wydajny od tego w PHP (przy podobnych założeniach algorytmicznych)?

PS. Twój counter nie jest precyzyjny. Tabela 2 powinna też mieć
WEBSITE_ID. Bo inaczej jeśli ktoś wejdzie z 1.2.3.4 na abc.com, > a potem na def.com w ciągu kilku min, to na def.com nie zostanie
policzony.

Zgadza się. Chodziło mi tylko o nakreślenie jakoś ogólnie problemu do dyskusji, a nie o przedstawienie konkretnej budowy bazy ;)

Dzięki za odpowiedź w dyskusji.

Temat: Propozycja wydajnego rozwiązania

access logi.

Temat: Propozycja wydajnego rozwiązania

Piotr Parzentny:

Jeśli tabela 2 jest zindeksowana wg. IP a tabela 1 wg. WEBSITE_ID, to będzie szybkie oczywiście.

Jak bardzo? Do jakiej granicy? Jak to sprawdzić?

Jak będziesz wycinał codziennie stare IP z bazy, to prędzej padną same skrypty (tzn. wydajność apache, czy jaki tam masz serwer) niż dostęp do bazy - do takiej granicy ;)
google: benchmark + AB, albo siege

Poza tym wydaje mi się, że counter tutaj może się sprawdzić. Ja nie chcę mierzyć oglądalności samego serwisu tylko wywołania mojego skryptu na stronce.

To czemu chcesz to robić po raz drugi w skrypcie, jeśli prawdopodobnie masz wszystkie dane jakie potrzebujesz w logach serwera? (ip, czas, url)

Temat: Propozycja wydajnego rozwiązania

Stanisław Pitucha:
To czemu chcesz to robić po raz drugi w skrypcie, jeśli prawdopodobnie masz wszystkie dane jakie potrzebujesz w logach
serwera? (ip, czas, url)

O tym nie pomyślałem! Dalej jednak interesuje mnie kwestia różnic językowych. Czy zabawa z takimi logami będzie dużo bardziej wydajna w innych językach niż PHP? Znacie może też jakieś klasy do obsługi logów? Żebym przypadkiem na nowo koła nie wymyślał :)

Temat: Propozycja wydajnego rozwiązania

Piotr Parzentny:

Żebym przypadkiem na nowo koła nie wymyślał :)

http://awstats.sourceforge.net/

Temat: Propozycja wydajnego rozwiązania

A gdyby tak od czasu do czasu z każdego tego serwisu pobierać info z access logów?

* Your server must log web access in a log file you can read.
* You must be able to run perl scripts (.pl files) from command > line and/or as CGI

Pytanie czy każdy hosting/serwis takie logi ma włączone i da mi do nich dostęp? Pewnie się mylę i jest to niemożliwe. Uświadomcie mnie :) Jestem z tego tematu zielony i nigdy nie miałem z tym styczności.

Z góry dzięki za info i cierpliwość.

Temat: Propozycja wydajnego rozwiązania

Ja osobiście bym napisał własny parser "access logów" najlepiej w C, program ten by parsował logi i dodawał wyniki do bazy danych. Wywołanie programu dodał bym do crona na jakąś nocną godzinę. Wadą tego rozwiązania jest to że byś musiał odczekać jeden dzień na dane.
No i ostatni kwestia to taka że serwer na serwerze byś musiał mieć szerokie uprawnienia , lub server VPS.
Pozdrawiam

Temat: Propozycja wydajnego rozwiązania

Piotr Parzentny:
A gdyby tak od czasu do czasu z każdego tego serwisu pobierać info z access logów?

Jezeli wywolywany jest (jakkolwiek) skrypt na Twoim serwerze, to w Twoich access logach bedzie zapisywane jego wywolanie.
Logi ludzikow innych beda mialy jedynie wywolanie ich stron - a co za tym idzie, wszystko ;-) A z tego wynika to, ze musialbys zapisac sobie na jakich stronach jest Twoj skrypt, oraz napisac rzeczywiscie wlasny parser ktory wyluskal by z nich tylko te strony o ktore Ci chodzi. Chociaz mysle, ze awstats moze zliczac tylko wskazane odnosniki do stron.

Pytanie czy każdy hosting/serwis takie logi ma włączone i da mi do nich dostęp? Pewnie się mylę i jest to niemożliwe. Uświadomcie mnie :) Jestem z tego tematu zielony i nigdy nie miałem z tym styczności.

Z góry dzięki za info i cierpliwość.

Jezeli nie ma dostepu do logow na hostingu, to zazwyczaj oni sami odpalaja cos takiego jak awstats i daja do tego dostep w panelu.
A jak nie, to po prostu pogadaj z adminami ;-)

A co do parsowania, to nie ma co wymyslac kola.
Ustawic powinienes jakos moc, aby logi sie zapisywaly konkretnie do skryptu Twojego jednego. Np. udostepnic go pod konkretna inna domena (subdomena). I bedziesz mial logi tylko dla tego jednego skryptu.
Oczywiscie wszystko zalezy od adminow z hostingu ktory masz.Piotr Baranowski edytował(a) ten post dnia 25.10.09 o godzinie 12:46

Temat: Propozycja wydajnego rozwiązania

Dzięki za informacje. Serwer to nie problem - minimum jakiś VPS lub dedyk. Nie powinno być problemów. Z tego co piszecie to rozwiązanie z odczytem logów na serwerach tych stron odpada - bo różne to będą hostingi, admini i uprawnienia. Także odpada. Analiza logów u mnie wystarcza i bardzo ta idea mi się podoba!

Ustawic powinienes jakos moc, aby logi sie zapisywaly konkretnie

do skryptu Twojego jednego. Np. udostepnic go pod konkretna inna

domena (subdomena). I bedziesz mial logi tylko dla tego jednego
skryptu.

Super pomysł. Pod względem przejrzystości i wydajności wydaje się mieć to sens.

Wywołanie programu dodał bym do crona na jakąś nocną godzinę.
Wadą tego rozwiązania jest to że byś musiał odczekać jeden dzień na dane.

Dla mnie to akurat jest zaleta :) O coś takiego mi chodzi. Nawet mogę sobie pozwolić na odczyty co kilka dni.

Ja osobiście bym napisał własny parser "access logów" najlepiej
w C, program ten by parsował logi i dodawał wyniki do bazy danych.

No właśnie to odpada, ale wydaje mi się że dostępne darmowe oprogramowanie do parsowania logów i wyciągnięcia potem tych danych do bazy/php wystarczą. Parsery te (C/perl itp) na pewno są solidne i wydajne. Tutaj pewnie problemu nie będzie. Co jednak z wydajnością serwera i samym tworzeniem się access logów? Do jakiego stopnia mogę tutaj wykorzystać Apache? Jaki jest pułap tutaj wydajności? To pewnie temat na inne forum, ale może ktoś coś mi podpowie w tym temacie. Samo korzystanie z AB Apache to chyba nie szczyt możliwości.

Pozdrawiam.Piotr Parzentny edytował(a) ten post dnia 25.10.09 o godzinie 14:25

Temat: Propozycja wydajnego rozwiązania

Ja nie chcę mierzyć oglądalności samego serwisu tylko wywołania mojego skryptu na stronce. Może na jakimś przykładzie: webmasterzy dodają do swoich stronek kawałek kodu, który pobiera zmojego serwera załóżmy kurs Euro/PLN :) Chcę zliczyć ile razy na poszczególnych serwisach ludzie widzieli te moje dane indywidualnie (UU) oraz ogólnie ile było wyświetleń. Tylko tyle.

Google Analytics obsługuje takie statystyki. Nie ma sensu wymyślać tego na nowo. Już samo założenie opierania się o adres IP jest niepoprawne.

Temat: Propozycja wydajnego rozwiązania

Też właśnie wydawało mi się to za proste :) Pewnie dużym problemem jest tutaj np. NAT i wspólne adresy IP. Pytanie jak więc ta kwestia jest rozwiązana w Google Analytics? Z obserwacji ludzi na innym forum jednak okazuje się, że dane z GA dość mocno odbiegają od ich logów serwerowych. Tak więc nie jest to narzędzie idealne? Nigdy tego nie stosowałem więc wasze obiektywne opinie są tutaj dla mnie bardzo cenne.

Pozdrawiam i dziękuję za zainteresowanie tematem oraz pomoc.

Temat: Propozycja wydajnego rozwiązania

Piotr Parzentny:
Też właśnie wydawało mi się to za proste :) Pewnie dużym problemem jest tutaj np. NAT i wspólne adresy IP. Pytanie jak więc ta kwestia jest rozwiązana w Google Analytics? Z obserwacji ludzi na innym forum jednak okazuje się, że dane z GA dość mocno odbiegają od ich logów serwerowych. Tak więc nie jest to narzędzie idealne? Nigdy tego nie stosowałem więc wasze obiektywne opinie są tutaj dla mnie bardzo cenne.

Pozdrawiam i dziękuję za zainteresowanie tematem oraz pomoc.

Pytanie na czym Ci dokladnie zalezy? :-)

GA jest bardziej biznesowe. Zlicza mase rzeczy, ktore oni i tak zliczali na potrzeby AdWords i AdSense, wiec udostepnili to ludziom jako fajny produkt. Zupelnie darmowy rowniez do uzytku komercyjnego.
Ale to sluzy bardziej do analizy strony pod wzgledem grup docelowych, popularnosci poszczegolnych jej elementow itp.
Mozna dodawac rozne filtry, szmery bajery - ale zastosowanie zostanie jedno.

Jezeli chcesz miec po prostu czysta informacje ile razy ktos uzyl Twojego skryptu - to awstats z logow styka. On nie wrzuca tego do bazy, on wypluwa plik html'owy w ktorym sa te wszystkie dane ktore mozesz sobie ogladac i juz.

Z drugiej strony o wiele latwiej podpiac GA, bo jezeli wypluwasz komus HTMLa, to na koncu tego HTMLa dodajesz wygenerowany kod z GA i juz.

W GA masz takie dane jak: liczba odslon, liczbe unikatowych userow, liczbe odslon w jednej sesji usera.
Skad wejscia na ta strone sa (dane z google'a wyszukiwarki), liczbe odnosnikow bezposrednich do Twojego skryptu oraz strony z ktorych ktos na nie wszedl.Piotr Baranowski edytował(a) ten post dnia 25.10.09 o godzinie 15:24

Temat: Propozycja wydajnego rozwiązania

Skoro i tu i tu mogę zbadać ilość odsłon i UU to moje kolejne pytanie: czy te wartości ZAWSZE będą takie same korzystając z tych dwóch różnych metod(GA i access logi)? co jest dokładniejsze?

Pytanie na czym Ci dokladnie zalezy? :-)

Na tym, że jeśli 1000 różnych webmasterów zechce zainstalować mój widget, który pokazywać będzie powiedzmy zdjęcie mojej twarzy ;) na swoich stronach (nie wiem na jakich bo będą pobierać sobie kod z mojego serwisu ci którzy sobie tego zażyczą).

Ważna jest wydajność, żeby przy konkretnym rozwiązaniu i posiadaniu 1000 serwisów o oglądalności powiedzmy >100k UU/miesiąc każdy nic mi się nie rozsypało.

Teraz na stronie http://xxx.pl pojawi się załóżmy ten widget z moją twarzą to ja w swojej bazie po prostu chcę informację ile razy pojawił się on na tej stronie i ilu różnym ludziom (UU). Nie potrzebuję tych statystyk live! Powiedzmy, że dzisiaj chcę wiedzieć ile było wyświetleń w okresie 1-15 października. Tylko tyle. Dla każdego z tych 1000 serwisów oczywiście oddzielnie!

Może hybryda tych dwóch przedstawionych w rozmowie rozwiązań da mi szersze informacje? Z czasem mogą mi się przydać te bardziej biznesowe informacje jak np. kraje ludzi ogladających dany serwis, czas przebywania na stronie z widgetem itp.

Czy istnieje jakieś darmowe do zastosowań komercyjnych narzędzie będące konkurencją dla GA? Wiem, że jest Alexa tylko ona pewnie nie uwzględni niszowych stron polskich (a takie to głównie będą).

Pozdrawiam.Piotr Parzentny edytował(a) ten post dnia 25.10.09 o godzinie 19:23

Temat: Propozycja wydajnego rozwiązania

GA (Google Analytics) działa po stronie klienta czyli przeglądarki jest to kod javascript który się odwołuje do serwerów google. Związku z czym napewno nie obciąży twojego serwera co najwyżej może spowodować że dłużej będzie się komuś strona ładowała ale to po stronie klienta. Analiza logów jak by nie było będzie się dokonywała po stronie twojego serwera co obciązy system.
Ja osobiście używam GA, ale nie umieściłbym chyba kodu na stronie gdzie by było inne GA niż moje.
W instalacji jest napisane żeby kod GA umieścić przed końcem /body.
Ciekawe jak to jest jak jest kilka GA :).
Acces Log daje najlepsze rozeznanie we wszystkim, ale jak doinstalujesz sobie by rzucało dodatkowe dane do logów to może się odbić na wydajności.
Osobiście jak robiłem dla dużych obciążeń to rozbijałem ruch na kilka serwerów i po problemie.
P.S.
Jak coś pomieszałem w temacie to przepraszam, bo tylko pobieżnie przeczytałem historie. Mam nadzieję że jakoś pomogłem jak nie to sorrki :)

Temat: Propozycja wydajnego rozwiązania

Tomasz B.:
GA (Google Analytics) działa po stronie klienta czyli przeglądarki jest to kod javascript który się odwołuje do serwerów google. Związku z czym napewno nie obciąży twojego serwera co najwyżej może spowodować że dłużej będzie się komuś strona ładowała ale to po stronie klienta.

I to by mi się już nie podobało. Idealnie by było pobierać dane samemu z GA dla innych stron bez umieszczania przez nich tego kodu JS na stronie. Tylko to pewnie nie jest możliwe :)

Acces Log daje najlepsze rozeznanie we wszystkim, ale jak doinstalujesz sobie by rzucało dodatkowe dane do logów to może
się odbić na wydajności.
Osobiście jak robiłem dla dużych obciążeń to rozbijałem ruch na kilka serwerów i po problemie.

Dla mnie dane do logów, które chcę uzyskać/wyliczyć to tak jak pisałem: ilość wyświetleń, UU. To podstawa. Z reszty mogę zrezygnować. Możesz coś więcej oświecić mnie w temacie tego rozbicia obciążenia na kilka serwerów?

Temat: Propozycja wydajnego rozwiązania

Hej najlepiej rozdzielać takie obciążenie na poziomie serwerowym najbardziej wydajne. Jak to działa to tak na szybko http://linux.gda.pl/spotkania/sp_24/klastry.pdf . Można też napisać własne rozwiązanie w zależności od rodzaju aplikacji.
Ja bym osobiście rozwiązał ten problem tak, co prawda nie wiem co masz za aplikacje, dlatego poda, dwa warianty.
1) Twój skrypt wyświetla na stronach klientów jakies krótkie informacje (np notowanie giełdowe).
Dajesz skrypt w postaci <code>"<iframe src="www.twoja_domena/skrypt.php"></code>
W skryp.php umieszczasz GA i po problemie
2) Twój skryp wystawia dane w postaci binarki lub xml, dane są parsowane po stronie klienta
wtedy access log i bedzie git jak by sie coś muliło rozbić na serwery

Temat: Propozycja wydajnego rozwiązania

Bardzo dziękuje wszystkim za pomoc. Myślę, że sytuacja jest już dość jasna. Teraz pora na dokumentację, kodowanie i testowanie ;) Jak uda mi się coś stworzyć to podzielę się odczuciami i wynikami.

Pozdrawiam.

Temat: Propozycja wydajnego rozwiązania

Tomasz B.:
1) Twój skrypt wyświetla na stronach klientów jakies krótkie informacje (np notowanie giełdowe).
Dajesz skrypt w postaci <code>"<iframe

> src="www.twoja_domena/skrypt.php"></code>

W skryp.php umieszczasz GA i po problemie
2) Twój skryp wystawia dane w postaci binarki lub xml, dane są parsowane po stronie klienta
wtedy access log i bedzie git jak by sie coś muliło rozbić na serwery

A ja sie moge pod tymi propozycjami podpisac.
Jezeli wrzucasz kod swoj w iframe, to jest to osobna strona wczytywana od Ciebie, wiec mozesz tam wkleic JSowy kod GA przed </body> i bedzie to traktowane jako osobna strona, wiec zadnych boli z konfliktem nie bedzie.

Jezeli udostepniasz XMLa, Binarki, obrazki i inne bajery ktore nie sa strona HTML to pozostaja Ci jedynie logi serwera ktore parsujesz awstatsem.

A co do roznic miedzy danymi - to ta, sa one i beda. Poniewaz logi nie zawieraja takich pelnych danych jakie zebrac potrafi GA.
No i poniewaz inne sa zalozenia GA a inne np. awstats'a (ktorego tez mozna odpowiednio skonfigurowac - np. ile czasu to jest jedna sesja).
GA daje wyniki na pewno bardziej rzetelne - ale odpadaja ludzie ktorzy maja wylaczony JS (znikomy odsetek ludzi tak naprawde).

Aha.
A jak bys chcial sam sobie te logi parsowac to polecam Perl'a ;-) on od tego jest koniem pociagowym.Piotr Baranowski edytował(a) ten post dnia 26.10.09 o godzinie 00:10