Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Cykliczne pobieranie danych
jsmp
post
Post #1





Grupa: Zarejestrowani
Postów: 20
Pomógł: 1
Dołączył: 25.01.2009

Ostrzeżenie: (0%)
-----


Zastanawiam się jak wygląda realizacja takiego zadania, jak codzienne zdalne zasysysanie danych z pewnego API. O ile CRON i jedna sprawdzana dana wydaje się prosta, jak zrealizować projekt dla dynamicznego zbioru danych przechowywanych w bazie?

Np. W bazie mam listę adresów WWW , które stanowią warunek dla API. Zapytanie API dla danego www zwraca pewne wartości (np. ilość backlinks). Nie jestem przekonany, czy zapytania odnośnie kilku adresów jednocześnie nie wydłużą czasu reakcji API co może skończyć się bug'ami.

Teoretycznie można by co minutę odpalać skrypt CRONem, i sprawdzać pojedyńczą daną API (wtedy mam 3600 slotów) w ciągu doby. Jednak czy to optymalne?

Ten post edytował jsmp 2.03.2014, 16:43:36


--------------------
WebSEM.pl - Jak promować stronę internetową? - marketing internetowy i nie tylko...
Go to the top of the page
+Quote Post
 
Start new topic
Odpowiedzi (1 - 7)
jaslanin
post
Post #2





Grupa: Zarejestrowani
Postów: 511
Pomógł: 143
Dołączył: 13.03.2010
Skąd: Jasło

Ostrzeżenie: (0%)
-----


http://gearman.org/
http://stackoverflow.com/questions/1039792...on-with-gearman

jak nie możesz takich narzędzi użyć to sprawa się komplikuje
jedną z opcji jest zrobienie takiego myku że:
masz n cronów które wykonują skrypt wykonywania zadań
skrypt wykonywania zadania realizuje zadania które są w kolejce, a które nie są przetwarzane
plus do tego logowanie, ponowne wykonywanie niezrealizowanych zawieszonych itd.
ilość cronów zależy jakie obciążenie one generują, lepiej nie przesadzać z iloscią by nie zawiesić ale to trzeba przetestować jakie zasoby są konsumowane, wtedy liczba slotów to 3600*n

są też inne opcje, dodatki które to realizują poszukaj na frazę: php parallel

Ten post edytował jaslanin 2.03.2014, 18:22:19


--------------------
Good luck and happy PHP'ing
Go to the top of the page
+Quote Post
elmaciaso
post
Post #3





Grupa: Zarejestrowani
Postów: 8
Pomógł: 0
Dołączył: 9.02.2015

Ostrzeżenie: (0%)
-----


Witam.

Mam podobny problem z założyciel tematu.

Celem jest synchronizacja lokalnej bazy z bazą serwisu z ofertami za pomocą udostępnianego przez nich API.
Synchronizacja będzie się odbywać w CRON'ie. Problemem okazują się limity - limit 25 zapytań na minutę do API oraz limit jednej minuty wykonywania sryptu w CRON'ie.

Proces synchronizacji będzie polegał na:
- wysłaniu do API zapytania o listę usuniętych ofert
- wysłaniu do API zapytania o listę zakończonych ofert
- wysłaniu do API zapytania o listę uaktualnionych/dodanych od ostatniej synchronizacji ofert ( właściwie to od ostatnio zsynchronizowanego wpisu)
- dla każdego z powyższej listy:
- wysłanie do API zapytania o szczegóły oferty i zapisanie ich w lokalnej bazie

Kolejnym problemem są tutaj zdjęcia ofert. Każde ogłoszenie może mieć nawet 20 zdjęć, przy czym podobno powinienem każde zdjęcie pobierać osobno poprzez API i również zapisywać lokalnie. Tyle że każde takie pobranie zdjęcia to 1 zapytanie do API, dlatego przy ogłoszeniu z 20 zdjęciami miałbym 24 zapytania. To by znaczyło, że podczas jednego działania CRON'a zsynchronizowałbym tylko jedno ogłoszenie.

Dodatkowo dla mniejszej ilości zdjęć musiałbym ustawiać opóźnienie w działaniu kolejnych zapisów, żeby nie przekroczyć limitu zapytań do API.

Czy jest jakieś sensowne rozwiązanie tego problemu synchronizacji?


P.S. Jedno pytanie które może w dużym stopniu mi zaoszczędzi zapytań do API. Pobierając szczegóły dla każdego ogłoszenia, otrzymuję listę jego zdjęć, a dokładnie ID zdjęcia, po którym powinienem odpowiednią funkcją API pobierać zdjęcie. Zdjęcie to jest jednak dostępne do wyświetlania po ID, tzn podając na stronie URL http://img.jakisserwis.pl/zdjecie/<ID>, mogę wyświetlać je bezpośrednio z bazy serwisu z ogłoszeniami. Czy takie wyświetlenie zdjęcia poprzez podanie URL w atrybucie src jest traktowane jako zapytanie do API? Jeśli nie to nie musiałbym pobierać każdego zdjęcia a jedynie zapisywać ich ID.

Będę wdzięczny za każdą pomoc i miłe przywitanie (to mój 1 post smile.gif
Go to the top of the page
+Quote Post
Pyton_000
post
Post #4





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


Ad fotek to nie, jeżeli możesz je odpalić z przeglądarki to jest to normalny request.

Ad samego API, to niestety musisz trzymać się limitów i ograniczyć ich ilość jeżeli to możiwe (np. wywalając te fotki tak jak napisałeś)
Go to the top of the page
+Quote Post
elmaciaso
post
Post #5





Grupa: Zarejestrowani
Postów: 8
Pomógł: 0
Dołączył: 9.02.2015

Ostrzeżenie: (0%)
-----


Właśnie tak mi się wydawało odnośnie zdjęć, ale gdy zapytałem o to kogoś od tego API to powiedział że jest to traktowane jako zapytanie. Co może być powodem takiej odpowiedzi? Chęć ograniczenia ruchu spowodowanego takim wyświetlaniem zdjęć?
Nie pobieranie ich ograniczyłoby liczbę zapytań do 1 dla każdego ogłoszenia i znacznie ułatwiłoby mi pracę.

Zastanawiające było dla mnie tylko to że podając adres zdjęcia nie podaje konkretnej ścieżki np "../zdjecie/3232323.jpg" tylko adres "../zdjecie/3232323". Mimo to kierujemy się subdomeną img. a nie api. jak do zapytań.

Ten post edytował elmaciaso 9.02.2015, 12:54:20
Go to the top of the page
+Quote Post
Pyton_000
post
Post #6





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


W sumie mogą jeszcze mieć jakieś ograniczenie request/IP Spróbuj wywołać się kilkadziesiąt razy i sprawdź to będziesz wiedział czy limit obowiązuje czy nie.
Go to the top of the page
+Quote Post
elmaciaso
post
Post #7





Grupa: Zarejestrowani
Postów: 8
Pomógł: 0
Dołączył: 9.02.2015

Ostrzeżenie: (0%)
-----


Odświeżyłem kilkanaście razy z rzędu stronę na której są wyświetlane 3 zdjęcia i przy kolejnych odświeżeniach nie widzę różnicy. Jak by się objawiało takie zablokowanie poprzez request IP?
Go to the top of the page
+Quote Post
Pyton_000
post
Post #8





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


zapewne jakimś błędem.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 20.08.2025 - 19:50