Перевірка зворотних посилань на сторінку через API та чесне кешування
Наш індекс оновлюється раз на місяць, тому більшість запитів можна обслуговувати з пам’яті. Рецепт кешування, який економить кредити, не показуючи користувачам застарілі дані.
Редакційна команда AlfaLinks ·
Правило
Кешувати до наступного оновлення індексу, а не фіксовану кількість годин
Оскільки дані змінюються приблизно раз на місяць, годинний TTL не дає жодної користі, лише додаткові витрати. Ключ, прив’язаний до місяця, дає однакову відповідь протягом усього місяця й інвалідується одним рухом.
Ключ: дія + домен + параметри + місяць індексу
TTL: до кінця місяця плюс один день на похибку
Ніколи не кешуйте відповіді про помилки
Чому короткий TTL — це просто пожертва на баланс кредитів
Команди, які вперше працюють із даними посилань, часто копіюють звички з трекерів позицій. Перша звичка: годинний кеш, бо позиції змінюються. Графи посилань майже не змінюються.
Запит backlinks коштує 2 кредити, або $0.0002. Це здається незначною сумою, доки список переглядів не запускає 50 таких запитів на завантаження сторінки в 400 активних робочих просторах, повторюючи їх щогодини для однакових відповідей.
Наведені нижче розрахунки — це приклад, а не вимірювання трафіку конкретної компанії. Припустімо 400 робочих просторів, 20 переглядів домену кожен на день, 2 кредити за перегляд і 1-годинний кеш, який спрацьовує лише в п’ятому випадку. Більшість за все одно звертається до API. З місячним ключем той самий трафік звертатиметься до API лише один раз на домен і місяць, тому різниця є головною метою цього рецепту.
Інструментам пошуку ключових слів потрібні більш свіжі дані, і для них великі комплексні рішення залишаються кращим вибором. Для контексту посилань місячна свіжість — це продукт.
TTL залежно від дії
Рекомендовано, а не обов’язково. Усі дії зчитують той самий місячний індекс.
Дія
Кредити
Рекомендований TTL
Чому
огляд, статистика
0
До кінця місяця
Безкоштовно, але ваш сервер все одно економить затримку
bulk_dr
1
До кінця місяця
Вся таблиця клієнтів одним запитом
refdomains, backlinks
2
До кінця місяця, залежно від параметра сторінки
Включіть page, per, sort у ключ
anchors, toppages
2
До кінця місяця
Стабільний між оновленнями
search, keyword
3
7 днів
Рідко повторювані, дешево пропустити кешування
Приклад запиту: розігрів кешу для таблиці клієнтів
Викликайте bulk_dr один раз для кожного клієнта, а не для кожного рядка. До 2000 доменів поміщаються в одне тіло POST-запиту і коштують один кредит.
bash
curl -X POST "https://alfalinks.net/api.php?action=bulk_dr&key=sk_live_..." \
-d "domains=stripe.com,notion.so,linear.app,figma.com,vercel.com"
# billed once, whatever the row count
Побудова кешу за п’ять кроків
Кожен крок має одну задачу. Пропустите один — і помилка проявиться пізніше, зазвичай у вигляді рахунка.
01
Оберіть ключ
Використовуйте дію, домен, параметри пагінації та сортування, а також місяць індексу. Не включайте те, що користувач може змінити без зміни відповіді, наприклад колір відображення або назву вкладки.
02
Збережіть розібрану відповідь
Зберігайте декодований JSON із прапорцем ok та даними, а не сирі байти. Пізніше перегляд зможе відновити всю таблицю з пам’яті без другого запиту.
03
Інвалідація в кінці місяця
Встановіть термін дії на кінець місяця індексу плюс день на похибку з правила вище. Використовуйте одне правило для всіх дій, щоб логіка жила в одній функції, а не в п’яти місцях.
04
Логуйте баланс при кожному запиті
Зчитуйте об’єкт _credits у кожній аутентифікованій відповіді та записуйте залишок балансу у власний лог. Повільне зниження цього значення часто є першим знаком того, що ключ кешу неправильний.
05
Слідкуйте за частотою попадань у кеш
Відстежуйте, як часто перегляд обслуговується з кешу. Низька частота означає, що ключ занадто специфічний або що користувачі відкривають новий домен кожного візиту. Обидва висновки корисні при плануванні бюджету.
Чи є застарілі дані вибором продукту чи багом?
Показник посилань може бути місячної давності і все ще бути правильним для індексу, з якого він отриманий. Справжнє питання в тому, чи вказує на це ваш інтерфейс. Більшість тикетів підтримки щодо старих чисел — це проблеми з мітками. Мітки зазвичай їх виправляють.
Надайте кожному показнику місяць індексу. Показуйте його користувачам. Як тільки вони бачать дату, число перестає виглядати як зламаний потік, і цей маленький рядок робить більше, ніж будь-який коротший TTL.
Як старим має бути показник посилань, щоб вважатися застарілим?
Наш індекс оновлюється приблизно раз на місяць, тому показник, закешований першого числа, описує той самий індекс, що й показник, закешований останнього числа. Нічого в відповіді не змінюється всередині місяця. Проблеми починаються, коли користувач очікує побачити посилання з вчорашнього дня, і тоді виправленням є чітка мітка, як описано в мітках рейтингу.
Чи потрібен кеш для безкоштовних запитів огляду?
Дія огляду коштує нуль кредитів, тому кеш тут захищає швидкість, а не баланс. Ваш сервер все одно платить за кожне коло запиту, і сторінка, яка відкривається п’ятдесят разів на хвилину, це відчує. Зберігайте й безкоштовні відповіді з тим самим місячним ключем, і сторінка залишатиметься швидкою, а ваш проксі — тихим. Примітки про публічний пошук пояснюють ту саму ідею для відвідувачів.
Чи має свіже посилання обходити кеш?
Зазвичай ні. Обхід коштує кредити за відповідь, яка ймовірно ідентична закешованій. Якщо клієнт наполягає, поясніть місяць індексу та запропонуйте одне ручне оновлення на робочий простір на місяць, а не кнопку, яку будь-хто може натискати в циклі.
Захист від лавини запитів та інші дрібниці
Одиночний політ: якщо десять користувачів відкривають той самий домен, зробіть один зовнішній запит і поділіться обіцянкою (promise).
Розігривайте кеш першого числа фоновим завданням, а не о 9 ранку, коли приходять користувачі.
Зберігайте _credits.remaining у відповіді та встановіть сповіщення нижче порогу, який ви оберете.
Кешуйте негативний результат «домен не знайдено» на день, а не на місяць.
Відображайте вік кешу в інтерфейсі, щоб підтримка могла відповісти на питання «коли це було отримано?».
Чому кеш перемагає скрапінг для перевірки посилань
Команди, яким потрібно масово перевіряти зворотні посилання на сторінки, часто починають зі скриптів, які безпосередньо опитують пошукові системи. Ці скрипти зависають. Вони здаються дешевими в перший день, тому команди зберігають їх значно довше, ніж слід. Кеш перед стабільним API зазвичай є дешевшим рішенням із меншою кількістю компонентів, які потрібно супроводжувати.
Різниця проявляється в інженерних годинах більше, ніж у першому рахунку. Зробіть кеш нудним, і більшість цих годин просто не станеться.
Чому саморобні перевірки посилань постійно зависають?
Пошукові системи обмежують автоматизовані запити, тому скрипт, який чисто працює для п’яти URL, може зависнути на п’ятдесяти тисячах. Повторні спроби, пули проксі та випадкові затримки додають витрат, яких не видно в рядку кредитів, і вони ламаються без попередження, коли ціль змінює відповіді.
Як зробити довге фонове завдання перезапускабельним?
Записуйте кожен завершений домен у кеш по мірі виконання. Якщо завдання зупиниться посередині, перезапуск пропустить усі домени, для яких вже є збережена відповідь, і продовжить з того місця, де зупинився. Нічого не буде оплачено двічі за той самий місяць, бо ключ уже містить відповідь.
Запускайте завдання рівномірним темпом, а не одним сплеском. Рознесення запитів у часі робить логи читабельними та полегшує пояснення будь-яких змін у використанні кредитів.
Скільки коштує список із 22 000 URL із кешем?
Припустімо, вам потрібно перевірити 22 000 посилальних URL для одного клієнта. Багато з них мають спільний домен, тому спочатку зробіть дедуплікацію до доменів. Ці 22 000 посилань можуть зменшитися до кількох тисяч унікальних доменів, і один запит bulk_dr приймає до 2000 з них за один кредит. Зберігайте кожен результат за доменом і місяцем, і список перестає бути завданням на рівні URL. Тримайте арифметику в короткій нотатці поруч із завданням, щоб наступна людина могла запустити його з іншим розміром списку. Число з показаним розрахунком довіряти простіше, ніж сума саме по собі.
Де це пов’язано
Кеш є проміжним шаром у налаштуванні лічильника. Коли він працює, вартість на користувача стає передбачуваною, і ви можете цінувати план навколо неї за допомогою порівняння по користувача. Короткі сторінки заслуговують на чіткий кінець. Ця його має.
Питання про кеш, які ми бачимо в code review
Чи має кеш жити також у браузері?
Короткий кеш у браузері допомагає навігації кнопкою «Назад», але справжню економію забезпечує спільний кеш на сервері. Зберігайте клієнтські дані лише кілька хвилин, інакше користувачі на різних машинах бачитимуть різні числа для одного й того ж домену в той самий день.
Що робити, якщо клієнт каже, що нове посилання відсутнє?
Перевірте місяць індексу, показаний у вашому UI. Якщо посилання було додано після останнього оновлення, воно з’явиться після наступного. Пропонуйте примітку, а не повернення коштів, бо нічого не зламано.
Чи можу я обійти кеш на вимогу?
Можете, але кожен обхід коштує кредити за відповідь, яка ймовірно ідентична. Пропонуйте його лише адміністраторам і обмежуйте частоту на робочий простір, щоб уникнути випадкових циклів.
Пагінація та ключ кешу
Пагінація вразить кожного хоча б раз. Включайте її в ключ.
Дії backlinks та refdomains повертають до 1000 рядків за запит, з page та per від 10 до 5000, а глибока пагінація обмежена 50 000 рядків, тому ключ без цих параметрів обслуговуватиме першу сторінку для кожного запиту.
Сортування також має бути в ключі. Користувач, який перемикається з спадного DR на алфавітний, очікує інший список, і кеш має задовольнити це без нового зовнішнього запиту, коли повний набір уже збережено.
Швидкий тест ловить більшість помилок ключа. Запитайте другу сторінку, змініть сортування, потім перевірте, чи відрізняється закешована друга сторінка від закешованої першої. Якщо ні, ключ не містить параметра. Знайдено рано — це коштує хвилини. Клієнт цього не побачить. Запускайте тест знову перед кожним релізом, бо нова опція сортування — це звичайна причина поломки ключа. Впишіть це в чек-лист релізів.
Плануйте кнопку експорту окремо: одне фонове завдання, один збережений файл і одне сповіщення, коли він готовий.
