Procházejte URL backlink checker bez mezer nebo nekonečných smyček
Řádky na volání, stránky na dotaz a tvrdý strop na 50 000. Zde je smyčka, která respektuje všechna tři pravidla a řekne vám, kdy přestat.
Na jedno volání se vrátí až 1 000 řádků. Každé volání se účtuje jednou, bez ohledu na počet řádků. Hluboké stránkování je omezeno na 50 000 řádků, což je 50 volání po 1 000 řádcích.
Proč třídění předchází stránkování
Stránkování přes netříděný seznam je způsobem, jakým se objevují duplicity. Vždy posílejte sort a order společně s page a per, aby stránka 3 znamenala na každém požadavku v běhu totéž.
Stáhnutí refdomains stojí 2 kredity na volání, takže 50 volání vyjde na 100 kreditů, tedy jeden cent. I ten nejhorší případ je levný; skutečným nákladem je smyčka, která nekončí.
Výběr sloupce pro třídění
Podle kterého sloupce třídit, závisí na otázce. Třídění od největšího je obvyklou volbou pro audity, protože strop pak odřízne dlouhý ocas místo části, na které vám záleží.
Třiďte podle pole, které pro vaši otázku nic neznamená, a strop může odstranit řádky, které jste chtěli. Stáhněte si deset řádků podle každého kandidáta na třídění a podívejte se, který řez přežije strop.
Zapište volání do zprávy, aby další osoba věděla, proč strop klesl tam, kde klesl.
Záznamy, které se během běhu přesouvají
Data se během běhu neposouvají, pokud měsíční rebuild nedorazí uprostřed něj. Málo časté, ale reálné. Noční úloha, která zasahuje do prvního dne v měsíci, může vrátit jednu stránku ze starého indexu a další z nového, takže si do logu zapište čas zahájení a porovnejte.
Zapište čas zahájení na začátek logu a číslo stránky na každý řádek. Pak nesrovnalost ve výstupu ukáže na časování, nikoliv na chybu v parsování.
Pokud je úloha naplánovaná, vyhněte se času zahájení těsně před pravděpodobným rebuildem. Vaše logy ukazují rebuild jako posun v celkových počtech mezi dvěma běhy, které se jinak shodují, takže udržujte celkové počty v každém řádku logu.
Běh, který překračuje rebuild, není automaticky špatný. Je pouze nekonzistentní, takže tyto běhy v logu označte a při významu pro report znovu spusťte postižený řez.
Smyčka stránkování, která končí
TypeScript pro worker Node 20. Končí na první krátké stránce, na stropu nebo na jakémkoli ok, které není true.
const BASE = "https://seomasters.dev/api.php";
const CAP = 50_000;
const PER = 1000;
export async function pullAll(domain: string, key: string) {
const rows: unknown[] = [];
for (let page = 1; rows.length < CAP; page++) {
const u = new URL(BASE);
u.search = new URLSearchParams({
action: "refdomains", q: domain,
page: String(page), per: String(PER),
sort: "dr", order: "desc",
}).toString();
const res = await fetch(u, { headers: { Authorization: `Bearer ${key}` } });
if (res.status === 401 || res.status === 402) throw new Error(`stop: HTTP ${res.status}`);
const body = await res.json();
if (!body.ok) throw new Error(JSON.stringify(body).slice(0, 300));
const chunk = findRows(body); // see note below
rows.push(...chunk);
if (chunk.length < PER) break; // short page means we are done
}
return rows;
}Řešení problémů s během stránkování
| Co vidíte | Pravděpodobná příčina | Co dělat |
|---|---|---|
| Stránka 51 se vrátí prázdná nebo s chybou | Dostali jste se na strop 50 000 | Zúžte pomocí jiné akce nebo jiného sort, pak sloučte podle id |
| Stejná doména na dvou stránkách | Netříděný dotaz nebo rebuild indexu uprostřed běhu | Pošlete sort a order; deduplikujte podle klíče domény |
| Méně řádků než celkový počet v dashboardu | Celkový počet je pro celý graf, stáhnutí je omezeno | V UI zobrazte "top 50 000" |
| Smyčka nikdy nekončí | Kontrola podmínek pouze rows.length | Přerušte na krátké stránce, jak je uvedeno výše |
| Vyšší účet, než se očekávalo | Opakování při každém kódu mimo 200 | Opakujte pouze síťové chyby, viz errors |
Čtení řádků bez hádání názvů polí
Pomocná funkce findRows výše je záměrně ponechána otevřená. Proveďte jedno skutečné volání, podívejte se na JSON a napište accessor podle toho, co vidíte, nikoliv podle toho, co sliboval tutoriál.
Pro levnějšího bratra této úlohy, hodnocení mnoha domén najednou bez jakéhokoli stránkování, si přečtěte bulk DR script.
Zmrazte jednu odpověď jako fixture
Pak ji zmrazte testem. Uložte jednu odpověď jako soubor fixture a assertněte na počtu řádků a klíčích prvního řádku, aby budoucí změna selhala v CI a ne v grafu zákazníka.
Udržujte fixture ve version control vedle testu, aby recenzent viděl tvar, který kód očekává, aniž by něco spouštěl.
Když API později přidá pole, diff fixture vám řekne, zda váš accessor to zaznamenal nebo to tiše ignoroval.
Pojmenujte fixture podle dotazu, ze kterého pochází, například akce, domény a sort. Soubor nazvaný response1.json řekne dalšímu čtenáriu o tom, co dokazuje, málo.
Spočítejte uložené řádky
Porovnejte uložené řádky s celkovým počtem, který smyčka nahlásila. Mezera znamená, že stránka byla vynechána, a opakování znamená, že stránka byla stažena dvakrát a upsertnuta do jednoho řádku.
Spusťte tuto kontrolu po každém testovacím tahu, nejen po prvním. Posun v počtu je obvykle prvním příznakem změněného sort nebo rebuildu uprostřed běhu.
Udržujte počet v stejném řádku logu jako číslo stránky, aby šly číst společně na první pohled.
Rozdělení práce nad strop
Některé otázky přesáhnou strop. Pro seznamy nad stropem rozdělte problém místo tvrdšího stránkování. Stáhněte top 50 000 podle jednoho sort, pak se zeptejte jiných akcí na heavy hitters, protože ty také stojí 2 kredity a odpovídají na jiné otázky. Tvrdším stránkováním se nikdy nedostanete přes oříznutí.
Stáhněte top 50 000 podle jednoho sort
Vezměte strop jako fakt API. Stáhněte top 50 000 řádků podle jednoho sort, uložte je a označte výsledek jako top slice v jakémkoli reportu.
Dashboard, který ukazuje omezený počet jako plný celkový počet, klame lidi, kteří ho čtou. Označení nic nestojí a url backlink checker report s ním zní upřímněji.
Rozhodněte velikost řezu před během a zapište ji do záhlaví reportu, aby číslo nikdy nevypadalo větší, než je. Řádek záhlaví nic nestojí a čtenář, který později najde chybějící řádek, vám bude vděčný.
Zeptejte se heavy hitters na jinou otázku
anchors a toppages odpovídají na jiné otázky, například který anchor text dominuje nebo které stránky přitahují odkazy. Pro doménu za stropem mohou tyto odpovědi být důležitější než další stránka stejného seznamu.
Udržujte jejich výsledky v samostatných tabulkách, klíčovaných podle domény, aby pozdější stáhnutí stejné domény mohla nahradit bez dotyku s řádky top slice.
Každá další akce stojí své vlastní kredity, takže ji oceňte před během, ne po příchodu účtu.
Krátký seznam nejtěžších domén, stažený jednou měsíčně, často poskytuje užitečnější kontext než delší seznam stahovaný každou noc.
Sloučení podle klíče domény
Když se dva tahy překrývají, sloučte je podle klíče domény a udržujte novější timestamp. Sloučení pak nikdy nezávisí na tom, který tah skončil první.
Logujte, který tah vyhrál každý řádek. Pokud se číslo mezi dvěma reporty hýbe, tenhle log řekne, zda se změnil index nebo merge.
Udržujte merge v jedné funkci s testem, protože je to jediné místo, kde se setkávají dva tahy.
Obnovení po pádu
Pády se stávají. Deploy restartuje workera, notebook usne, VPN spadne a smyčka zemře na stránce 31 z 50.
Uložte stránku po každém volání
Udržujte poslední dokončené číslo stránky po každém volání. Restartujte z toho čísla plus jedna, ne od začátku, a zaplatíte za 2 kredity na stránku místo znovuplacení celého tahu.
Uložte ji po parsování odpovědi, ne předtím. Stránku, kterou se nepodařilo přečíst, by měla být stažena znovu a uložené číslo stránky musí vždy znamenat řádky, které máte.
Uložení, které se děje jednou za minutu místo jednou na volání, zanechává okno, kde pád může zopakovat výdaj kreditů. Udržujte zápis malý, aby byl levný dělat při každém volání.
Logujte také, jak dlouho trvá každé uložení a jak dlouho každé volání. Uložení, které se rovná volání, ukazuje na storage layer, a to stojí za opravu před tím, než smyčka poroste.
Upsert podle klíče domény
Udržujte idempotentní zápis. Upsert každý řádek podle jeho klíče domény, takže stránka stažená dvakrát zanechá jeden řádek, ne dva.
Použijte stejný klíč na každé write path, včetně ručního repair skriptu. Dvě write path s dvěma klíči jsou způsobem, jakým duplicity přežijí resume.
Repair skript se často píše ve spěchu po selhání běhu. To je chvíle, kdy se vloudí druhý klíč, takže ho zkontrolujte stejně pečlivě jako hlavní smyčku.
Odmítněte resume, když se změnil sort
Logujte sort a order společně s číslem stránky. Pokud někdo změní sort mezi pádem a restartem, uložené číslo stránky už neznamená stejný řez. Odmítněte resume a začněte čistě.
Uložte malý resume záznam se sort, order, stránkou a časem. Smyčka nejdříve čte tenhle záznam a odmítne pokračovat, pokud se žádné pole již neshoduje s požadavkem, který chystá udělat.
Odmítnuté resume není selhání. Je to smyčka, která říká, že uložená stránka už neznamená stejné řádky, a začít čistě je levnější chyba.
Spouštění smyčky v produkci
- 1
Začněte s malou doménou
Spusťte smyčku proti doméně s několika stovkami řádků, aby se spustilo krátké-page stop a sledovali jste, jak funguje exit path.
- 2
Zkontrolujte jednu stránku okem
Otevřete jednu uloženou odpověď a potvrďte, že accessor stále čte řádky. Nedůvěřujte parsu, který jste neviděli.
- 3
Udržte limity v config
Dejte strop a velikost stránky do jednoho config souboru, aby se změna objevila v review a nebyla skrytá uvnitř funkce.
- 4
Logujte důvod, proč smyčka skončila
Zaznamenejte, zda běh skončil na krátké stránce, na stropu nebo na chybě. Tyto tři konce znamenají různé věci pro toho, kdo log čte.
