Спасибо) Самое смешное, что это рекурсивно — за самим алертом тоже нужен глаз. Обошёлся минимумом: open_fds / max_fds, чтобы не строить мониторинг над мониторингом.
Хорошая придирка — формулировка в лиде размыта, признаю. 47 мс — это не «страница открылась в браузере», а полный round-trip HTTPS-запроса до получения 200 OK + HTML-тела от сервера (DNS + TCP + TLS + GET + response). Без рендеринга JS, CSS, картинок, шрифтов и трекеров — это голый ответ от RBC, а не page load. Из Москвы probe-агент получает HTML за 47 мс, из Новосибирска — 594 мс. Это transport + server-side latency, а не «всё что видит пользователь».
На главной у RBC реально много сторонних скриптов и трекеров — поэтому в браузере страница тяжёлая отовсюду, тут вы правы. Главный поинт статьи в другом: разница 47 vs 594 — это компонент, который из Москвы никаким серверным мониторингом из одной точки не видно, а у пользователя в Сибири она конвертируется в дополнительные сотни миллисекунд на каждом xhr/fetch к бэкенду. На фронтенд-аде это сверху, и две задержки усиливают друг друга в восприятии страницы.
Гео распределение планирую. Может думаю РБ добавить как источник необременённый РКН. По тарифным планам в будущем я вижу что текущие планы трогать ненадо. Можно будет добавить новый функционал для новых тарифных планов. Но не в ближайшем будущем.
Именно так — прокси лежат из-за нового DPI по TLS-фингерпринту клиента (описано в статье). Ваше решение с промежуточным сервером в РФ — один из рабочих вариантов. В telemt issue #617 обсуждают фрагментацию пакетов как ещё один workaround. Когда Telegram обновит TLS-параметры клиента — MTProxy должны ожить. Мониторинг как раз помогает видеть, какие серверы подняли голову после очередного раунда.
Stealth-патчи — это гонка вооружений, которую мониторинг-сервис проиграет в долгую. Думаю тут стоит в такого рода проверках настраивать Cloudflare чтоб не вредничал.
О, интересная мысль. Сейчас частично можно закрыть через keyword-проверку в HTTP-мониторе (ищет текст в body — можно ловить пропажу H1 или смену title) и PageSpeed (Lighthouse скоры). Но полноценного SEO-чека с hreflang, дублями и заголовками безопасности — нет, честно. Идея хорошая, записал. По сути это отдельный тип проверки, который парсит HTML и валидирует мета-теги. Спасибо за наводку.
Мне хочется сделать немножко но лучше. Вот обрати внимание на мелочи - логин в сервис же удобно через гугл например делать в пару кликов. А не переключатся на почтовый ящик и искать в спаме нужное письмо
Ага, и подлее всего, что метрика «оптимизации» при этом зелёная — пул честно пишет «соединение переиспользовано», просто таких пулов 120.
Спасибо) Самое смешное, что это рекурсивно — за самим алертом тоже нужен глаз. Обошёлся минимумом:
open_fds / max_fds, чтобы не строить мониторинг над мониторингом.А что у тебя за канал?
А вот это интересная инфа
Я понял, за строгие нравы здесь отвечаешь ты
Сейчас есть 2 тарифа. Free и Pro. Чтоб получить Pro тариф надо найти один баг и отписать мне.
Хорошая придирка — формулировка в лиде размыта, признаю. 47 мс — это не «страница открылась в браузере», а полный round-trip HTTPS-запроса до получения 200 OK + HTML-тела от сервера (DNS + TCP + TLS + GET + response). Без рендеринга JS, CSS, картинок,
шрифтов и трекеров — это голый ответ от RBC, а не page load. Из Москвы probe-агент получает HTML за 47 мс, из Новосибирска — 594 мс. Это transport + server-side latency, а не «всё что видит пользователь».
На главной у RBC реально много сторонних скриптов и трекеров — поэтому в браузере страница тяжёлая отовсюду, тут вы правы. Главный поинт статьи в другом: разница 47 vs 594 — это компонент, который из Москвы никаким серверным мониторингом из одной
точки не видно, а у пользователя в Сибири она конвертируется в дополнительные сотни миллисекунд на каждом xhr/fetch к бэкенду. На фронтенд-аде это сверху, и две задержки усиливают друг друга в восприятии страницы.
Я чувствовал что к карте будут вопросы)
Гео распределение планирую. Может думаю РБ добавить как источник необременённый РКН. По тарифным планам в будущем я вижу что текущие планы трогать ненадо. Можно будет добавить новый функционал для новых тарифных планов. Но не в ближайшем будущем.
Благодарю. Сам не ожидал что статья так взлетит.
робот Вертер постарается для тебя в следущий раз получше!)
Общение - золото)
Именно так — прокси лежат из-за нового DPI по TLS-фингерпринту клиента (описано в статье). Ваше решение с промежуточным сервером в РФ — один из рабочих вариантов. В telemt issue #617 обсуждают фрагментацию пакетов как ещё один workaround. Когда Telegram обновит TLS-параметры клиента — MTProxy должны ожить. Мониторинг как раз помогает видеть, какие серверы подняли голову после очередного раунда.
Да и стоимость на конечном потребители всегда. На нас.
Ты с фабрики ботов? Где у вас офис?)
Хорошее замечание. Прорабатываем тему внедрения
FYI: если агент не умеет выбирать из 126 инструментов — это проблема агента, а не количества. Наши 126 — это покрытие, а не спам :)
Stealth-патчи — это гонка вооружений, которую мониторинг-сервис проиграет в долгую. Думаю тут стоит в такого рода проверках настраивать Cloudflare чтоб не вредничал.
О, интересная мысль. Сейчас частично можно закрыть через keyword-проверку в HTTP-мониторе (ищет текст в body — можно ловить пропажу H1 или смену title) и PageSpeed (Lighthouse скоры). Но полноценного SEO-чека с hreflang, дублями и заголовками безопасности — нет, честно. Идея хорошая, записал. По сути это отдельный тип проверки, который парсит HTML и валидирует мета-теги. Спасибо за наводку.
Мне хочется сделать немножко но лучше. Вот обрати внимание на мелочи - логин в сервис же удобно через гугл например делать в пару кликов. А не переключатся на почтовый ящик и искать в спаме нужное письмо