inkvizitor68sl
0
Если спрашивать в один поток — то никаких проблем не возникает.
Возможно, «в один поток» укладывается в лимиты. Я делал что-то в духе for i in ...; do whois $i; done, ничего не отстреливало.
inkvizitor68sl
0
" This version of the whois client tries to guess the right server to ask for the specified object. If no guess can be made it will con‐
nect to whois.networksolutions.com for NIC handles or whois.arin.net for IPv4 addresses and network names.
"

Но вообще там почти для каждой зоны зашиты свои сервера, они почти все без лимитов. Вот примерный список — https://hastebin.com/umufudadow.coffeescript
inkvizitor68sl
+1
Не имеет, весь реестр легко простукивается whois-ом за полдня (если в один поток).
Вот всяческие whois-сервисы — да, имеют.
inkvizitor68sl
+1
Интересно, почему они здесь используют фразу ограничен? Запрещен же.
Но cjdns и i2p, получается, можно использовать.
inkvizitor68sl
+2
Дык это.

apt-get install gnome-session-flashback
inkvizitor68sl
+1
Вы как-то очень интересно по диагонали читаете. Давайте я вам по порядку объясню.

1) Сервер с 32G RAM (и каким-то там процессором из разряда «обычных») стоит дешевле виртуалки в azure с 1.75G RAM. Как в аренду, так и если его купить и поставить в стойку (из расчета, что он будет использоваться 3-4+ года).
2) Железка с 32G ram справлялась с пиковой нагрузкой (в аж целых 80 RPS, да), а виртуалка в azure за бОльшие (или примерно те же) деньги, судя по статье — нет.
3) Сравнивать абсолютные значения RPS старенькой CMS на php и свежего оптимизированного под конкретный проект кода — мягко говоря, некорректно.
4) сервера c 32G сейчас являются игрушкой для стажеров, а не «монстром» в IT-компаниях. Возможно, в мире махрового ынтерпрайза это не так. Повторюсь, RAM сама по себе не стоит ничего. Каких-то денег стоят серьёзные процессоры, но его там нет и не было (e5540, что ли или похожий).
5) в действительно высоконагруженных проектах на данный момент закупаются/арендуются сервера с 256G+ RAM (при условии наличия соответствующих процессоров в ноде). Сервера со 128G отправляются в девелопмент или вроде того, а сервера с 32G уже года 3 как распродаются такими проектами за бесценок (потому что утилизация стоит приличных денег).
6) что добавлять железо нужно было в MR — я как раз не говорил. Про это почему-то в статье говорят (почему — думаю, юристы разбираться будут, кто и что кому сообщил. Сами владельцы проекта не в курсе, что у них, оказывается, что-то раньше падало).
7) Даже если и добавлять железо — то менять процессор, а не память.

Впрочем, посыл «Это инженерное решение?» вы зря так саркастично употребили. Многие проблемы забрасываются железом ровно потому, что так дешевле. За зарплату хорошего разработчика можно амортизировать/арендовать 20-30 хороших железок. А за удивившие вас 32G памяти в сервере можно разве что один раз в паб вдвоём-втроём хороший сходить.
inkvizitor68sl
–2
Что именно?
32 гигабайта памяти стоят сейчас 10-12 тысяч. А арендовать сервер с 32G можно на 35 EUR. В ходу сейчас сервера с 256-512G памяти.
inkvizitor68sl
0
ftp://mirror.yandex.ru/debian/ не закроется (как и ftp на любых других «общедистрибутивных» зеркалах).
inkvizitor68sl
–1
" что-то в районе 80 rps. А вообще нагрузка в день конкурса держалась в промежутке 10-20 rps. "
с 2016 цифры. Вряд ли в этом году больше.
inkvizitor68sl
–2
> Именно такого решения и ждали заказчики?
Нет, они ждали новомодных словечек в своём проекте и получили то, что хотели — Ажур при том же количестве ресурсов на бумаге медленнее железа.

> Добавить железку… :)
Не добавить, а заменить. Вы же пишете — «Добавление железа в сервер перестало приносить пользу. ». Никто его туда никогда не добавлял, не планировал, а самое главное — не задумывался об этом, ибо не нужно. Ну а я, в свою очередь, утверждаю, что замена железа на более производительное принесла бы огромную пользу к нафиг никому не нужным цифрам в лице теоретического максимума rps.

> Жду цитату из статьи и готов взять свои слова
Например вот — «Во время конкурса пользователи постоянно жаловались, что страницы медленно открываются, отдают 500-ошибку и не работает голосование».
Или вот — «якобы держал нагрузку».

> Текущая стоимость в 3 раза дешевле,
Хватит врать, серьёзно. В полтора раза дороже ваша S1 в месяц, чем то, что использовалось.

Давайте немного в цифрах. Самый-самый пик запросов в php в 2016м в течении секунды — что-то в районе 80 rps. А вообще нагрузка в день конкурса держалась в промежутке 10-20 rps. Обе цифры выглядят меньше 150, не? Или у меня проблемы с математикой на уровне второго класса?
Пятисоток там тоже в 2016м не было.

> заказчик забрал у вас контракт не потому что всё было круто
Мы можем поговорить про корпоративные за*бы, наверное, но не стоит. А то мы сейчас будем выяснять, у кого из корпов кончились деньги. Переписывать проект нужно было, опять делать это на php было глупым вариантом в 2017м. Так что молодцы, что переписали на современных технологиях и наконец-то задумались об оптимизации фронта.

Но вот утверждать, что оно «плохо работало раньше и падало во время конкурса» — это наглое враньё. Оно работало как работало, во время конкурса и в обычные дни — да, не очень шустро из-за кода и верстки родом из 2008го, но ничуть не медленее, чем обычно. И несмотря на необходимость переписать всё к чертям, старое решение прожило достаточно долго для такого уровня проекта и имело хороший запас по мощности и возможности расти по цифрам дальше.
inkvizitor68sl
+6
> Во время конкурса пользователи постоянно жаловались, что страницы медленно открываются, отдают 500-ошибку и не работает голосование. Были попытки «разогнать» сайт, но они закончились неудачно.

> Сайт хостился на выделенном сервере. Добавление железа в сервер перестало приносить пользу. Когда заказчик провел нагрузочное тестирование, сайт упал на 150 запросах в секунду.

Ребят, вы вконец охренели со своим пиаром. Миссрашка жила последние 3-4 года на обычной железке с 32G RAM и никто никогда не жаловался на «500 и не работает голосование». И железа туда никто никогда добавлять не пытался — один черт, никогда близкой к 150 RPS цифры там реальной нагрузки не было. И да, если «старую архитектуру» залили бы нормальной железкой — то держала бы она и 300, и 500 RPS (после некоторой настройки), эти цифры покрывают необходимый запас ещё на много лет вперед.

Вот что переписали это дерьмо мамонта — это вы молодцы, правильно сделали, без нового кода там делать нечего было. Но вот утверждать, что ваши соседи по индустрии лаптями едят — это вы зря. Мир тесен.
inkvizitor68sl
–2
https://overload.yandex.net/ + yandex.tank

И «предыстория» в статье — враньё.
inkvizitor68sl
+4
Да оставили бы просто ссылку на https://www.commandlinefu.com/commands/browse
inkvizitor68sl
0
Кстати да, astra хороша.
(в основном, правда, потому, что это почти голый дебиан с замененными картинками).
inkvizitor68sl
+2
Ну проблема начинается с того, что dmarc придумали несколько компаний, они его внедрили и на этом всё закончилось.
Про SPF и DKIM пишут на каждом углу, в каждом мануале, у каждого «mail related» сервиса в документации. А про dmarc пишут примерно нигде. Сам с удивлением впервые читал про dmarc в январе этого года.
inkvizitor68sl
0
sshuttle поудобнее будет.
inkvizitor68sl
+4
Как будто в условном asus-шайтан-500-машина с безопасностью из коробки всё хорошо.

Микротики в линейке hAP AC повернулись лицом к клиенту и их _нужно_ советовать покупать всем домашним пользователям. И да, quick setup там теперь выполняет свою задачу, так что проблем с настройкой у среднего человека не возникнет.
inkvizitor68sl
0
5 лет объясняю, ага.
inkvizitor68sl
+8
Примерно так же, как засилье рынка телефонами-лопатами, которому, почему-то, примерно никто не рад.
inkvizitor68sl
+10
7 — бред полнейший.
Вы как-нибудь на досуге маме своей объясните, что вон та картинка — это возврат на главную страницу. Мне проще было рассказать, что нужно нажать ctrl+l, стереть всё лишнее и нажать enter, чем объяснять, какой бред в голове у UI-ников творится.
inkvizitor68sl
+1
> Помимо локального режима, схожего по функционалу с xargs, он имеет возможность выполнения программ через SSH на нескольких серверах.
Ого. Однозначно плюсов вам. Я даже не догадался такое поискать, хотя и parallel активно использую.

> так как один из целевых хостов будет перегружен.
А у него вроде есть параметр maxla? Или via ssh он не работает?
inkvizitor68sl
0
https://www.opennet.ru/tips/3007_linux_remote_install_ssh_init_busybox_mount.shtml
Вы сегодня сговорились все =)
inkvizitor68sl
0
С главное нет, да, потому что это сайт их компании, а не одного только движка.
inkvizitor68sl
+1
Дык ента. https://open.vanillaforums.com/
inkvizitor68sl
0
Отсутствие кавычек и {} в примере под названием «одной переменной присваиваем значение другой» создаёт очень опасную ситуацию в виде тонн говнокода на баше и всяческих сказок вида «этого на баше нельзя, это на баше писать плохо» и прочей чуши.
inkvizitor68sl
+3
В _примере_ это всегда критично.
В своём коде пишите как хотите.
inkvizitor68sl
0
var1=$1
var2=$2


Дальше читать не стал.

var1="${1}"
var2="${2}"


inkvizitor68sl
+1
https://tools.ietf.org/html/rfc2644, section 3, например.
inkvizitor68sl
0
> я использовал на клиентах
Всем по*й, как ты настроил «клиенты». Маршрутизацией сети 46.4.205.64/29 занимается вышестоящее железо. А в RFC написано дропать пакеты с src 46.4.205.64 для сети 46.4.205.64/29.

Ну а вешать broadcast адрес на интерфейс — это вообще много ума иметь надо.
inkvizitor68sl
–1
Угу, осталось теперь рассказать как-то всему интернету, что на адресе сети и на broadcast-адресе у вас хост, а не то, что там должно быть по стандартам.
И если с адресом сети попроще (в nix-ах как-то относительно подзабили на то, что этот адрес особенный), то вот с машиной на broadcast жить будет весело, ага.
inkvizitor68sl
0
Чистый WP может (без учета резолва и tls-хендшейка) TTFB за 70-80ms.
Какие-то унылые цифры на шаредах…
inkvizitor68sl
+3
|sarcasm| Угу, трижды запрещали.|/sarcasm|
// пользователь PyICQt висящий в онлайне
inkvizitor68sl
+1
Справедливости ради, в UK, например, всё _намного_ хуже с подобного уровня распространенности сайтами =)

Вообще есть не так много стран, где нормально умеют делать сайты и Россия среди них. А вся эта история с МТС — следствие работы нескольких десятков поколений разработчиков, разных отделов, городов и тд, и тп. А менеджеры там не смотрят за тем, чтобы «всё вместе работало». К менеджерам пришли, сказали «сделайте Х», ко вторым пришли сказали «вон те делают Х, запустите у себя». А между собой такие менеджеры зачастую даже не пытаются пообщаться, просто рисуют задача разрабам (которым тоже наплевать).
inkvizitor68sl
+3
Да даже если так.
inkvizitor68sl
+6
> Mail.Ru Group
Ого. А вы всё продолжаете и продолжаете отмываться %)
inkvizitor68sl
0
Проблема, думаю, не в разработчиках, а в менеджерах, у которых сроки, желание позвать разрабов на бесконечные встречи и прочие чудные идеи.