Facebook Crawler Bot Crashing Site

Czy Facebook zaimplementował jakiegoś robota sieciowego? W ciągu ostatnich kilku dni moja witryna uległa kilkukrotnym awariom, poważnie przeciążona przez IP, które odnalazłem na Facebooku.Facebook Crawler Bot Crashing Site

Próbowałem googling around, ale nie można znaleźć żadnych ostatecznych zasobów dotyczących kontroli robota na Facebooku robota przez robots.txt. Jest odniesienie, dodając następujące:

User-agent: facebookexternalhit/1,1 niska opóźnienia: 5

User-Agent: facebookexternalhit/1,0 niska opóźnienia: 5

User-Agent : facebookexternalhit/* Opóźnienie indeksowania: 5

Nie mogę jednak znaleźć żadnego konkretnego odniesienia do tego, czy bot na Facebooku respektuje plik robots.txt. Według starszych źródeł Facebook "nie indeksuje Twojej witryny". Jest to jednak całkowicie nieprawdziwe, ponieważ moje dzienniki serwera pokazały, że indeksują moją witrynę z kilkunastu adresów IP z zakresu 69.171.237.0/24 i 69.171.229.115/24 z szybkością wielu stron na sekundę.

I nie mogę znaleźć żadnej literatury na ten temat. Podejrzewam, że jest to coś nowego, co FB właśnie zaimplementował w ciągu ostatnich kilku dni, ponieważ mój serwer nigdy wcześniej nie ulegał awarii.

Czy ktoś może doradzić?

Źródło

2012-10-14 Andy

Tak, ostatnio coś się zmieniło, ponieważ po raz pierwszy zaczęło awaryjnie działać w ciągu ośmiu lat, które już minęły. Podobno "aktualizują swoją otwartą kartę". Patrząc jednak na nasze strony, które prosi (bardzo stare, niewyraźne strony), zastanawiam się, czy legalny bot wykonuje javascript i uruchamia podobne przyciski, uruchamiając aktualizację FB OpenGraph. To tylko przeczucie ... – Stickley

Podobne pytania: http://stackoverflow.com/questions/11521798/excessive-traffic-from-facebookexternalhit-bot?lq=1 i http://stackoverflow.com/questions/7716531/ facebook-and-crawl-delay-in-robots-txt? lq = 1 – Stickley

Dziękujemy za sugestie i referencje, Hank. W związku z wydarzeniem moja strona była przytłoczona dziesiątkami wejść na sekundę, przez kilka godzin 8 lub 9 listopada. Ale tym razem - to nie był Facebook, ale Amazon. Nagle zaczęło się masowo przeglądać ogromną liczbę linków w witrynie, ale nie wydaje się, aby istniały jakieś oczywiste wzorce - niektóre strony, do których można uzyskać dostęp, są niejasnymi/starymi stronami, a niektóre są najnowszymi. Ciekawe, czy odświeżają własną bazę danych wyszukiwarki. – Andy

Bez względu na to, co wymyślił Facebook, zdecydowanie musisz naprawić swój serwer, ponieważ możliwe jest awarie z zewnętrznymi żądaniami.

Również tylko pierwsze trafienie w Google facebookexternalhit: http://www.facebook.com/externalhit_uatext.php

Źródło

2012-10-14 08:43:54 Serge

Dzięki. Sprawdziłem stronę FB uatext, chociaż nie oferowała niczego szczególnego. Strony, które zawieszają mój serwer, pochodzą z sekcji blogów Wordpress zawierającej kilka tysięcy wpisów. Niestety, silnik nie jest wystarczająco wydajny, nawet po zainstalowaniu wszystkich usprawnień i quickcache, a jedynym sposobem, jaki mógłbym myśleć o szybkiej naprawie, jest wdrożenie opóźnienia indeksowania robots.txt, ale nie wiem, czy FB je respektuje. Nie miałem problemów z indeksowaniem Google, ponieważ jest on rozpowszechniany w ciągu dnia. FB rzuca się na mnóstwo stron za jednym razem i zabija serwer. – Andy

Mam jeszcze jeden powód, dla którego nie lubię FB :) – Serge

Widzieliśmy takie samo zachowanie w tym samym czasie (w połowie października) - powodzi wniosków Facebooku, które spowodowały w kolejce żądań i powolność w całym systemie. Na początku było to co 90 minut; w ciągu kilku dni zwiększyło się to z częstotliwością i zostało losowo rozdzielone.

Żądania okazały się niezgodne z plikiem robots.txt, więc musieliśmy wymyślić inne rozwiązanie. W końcu ustawiliśmy nginx, aby przekazywał wszystkie żądania z użytkownikiem Facebook na dedykowaną parę serwerów zaplecza. Jeśli używaliśmy nginx> v0.9.6 mogliśmy zrobić ładny regex na to, ale nie byliśmy, więc użyliśmy mapowanie wzdłuż linii

map $http_user_agent $fb_backend_http { 
      "facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php)" 
        127.0.0.1:80; 
    }

Ten pracował dobrze dla nas; w ciągu kilku tygodni, kiedy byliśmy wbijani, podział na partycje powodował duży ruch z dala od reszty systemu.

Wygląda na to, że w dużej mierze już nam ucichło - widzimy tylko sporadyczne skoki.

Na pytanie dlaczego tak się stało, nadal nie jestem pewien - nie wydaje się być podobny incydent w kwietniu, która została nadana błędu http://developers.facebook.com/bugs/409818929057013/ ale nie jestem świadomy niczego podobnego niedawno.

Źródło

2012-11-02 15:43:10 annaken

Dziękuję za udostępnienie. Używam Apache - mam nadzieję, że mają podobne podejście do ponownego mapowania żądań przez użytkownika-agenta. Zakładam jednak, że mam kolejny dobry serwer do odciążenia tych dynamicznych wejść, ponieważ nie są to statyczne strony, bo inaczej będę musiał całkowicie odrzucić żądania i mam nadzieję, że FB nie uważa mojej witryny za nieważną. Podobnie do tego, co zaobserwowałeś, incydent wkrótce się skończył. Może to być jakaś bzdurna procedura FB - ale z pewnością jest to zła praktyka, aby nie respektować pliku robots.txt. – Andy

Jak wspomniano w in this similar question on facebook and Crawl-delay, Facebook nie uważa się za bota, a nawet nie prosi o plik robots.txt, a tym bardziej nie zwraca uwagi na jego treść.

Możesz wdrożyć własny kod ograniczenia stawki, jak pokazano w podobnym linku pytanie.Chodzi o to, aby po prostu zwrócić kod http 503, gdy serwer przekroczył pojemność lub został zalewany przez konkretnego klienta użytkownika.

Wygląda na to, że osoby pracujące dla wielkich firm technologicznych nie rozumieją "poprawić pamięć podręczną" to coś, co małe firmy nie mają do zaoferowania. Skupiamy się na obsłudze naszych klientów, którzy faktycznie płacą pieniądze i nie mają czasu, aby odeprzeć szalejące boty internetowe od "przyjaznych" firm.

Źródło

2012-11-09 16:56:49 Stickley

Facebook Crawler Bot Crashing Site

Odpowiedz

Powiązane problemy