я вот все жду когда этот ботнет либо в паблик утечет, либо просто к нам приедет, любопытно

К нам - это куда?

в смысле настроить через морду параметры так, чтобы автоматические фоточки переписывали память процесса по чуть-чуть

ну на кого-нибудь из клиентов

а еще имея ссш на эту поделку можно было редактировав файлик первода вызвать сегфолты тоже...

я, конечно, тоже согласен, что тезис "есть неподверженные этому веб-сервера" не совсем верен

Если настройками можно получить эффект при котором для эффективной атаки нужны совершенно неразумные ресурсы - сервер и правда не уязвим.

Если настройками можно получить эффект при котором для эффективной атаки нужны совершенно неразумные ресурсы - сервер и правда не уязвим.

"на практике достаточно устойчив".

:)

Если настройками можно получить эффект при котором для эффективной атаки нужны совершенно неразумные ресурсы - сервер и правда не уязвим.

А если взять несколько таких серверов... Ух

А то так можно дойти до обсуждения что "если атакующий имеет 2 млрд адресов, то он вас задосит"

А то так можно дойти до обсуждения что "если атакующий имеет 2 млрд адресов, то он вас задосит"

ipv6 никто не отменял

/photo_debilnih_ptic

/photo_debilnih_ptic

А то так можно дойти до обсуждения что "если атакующий имеет 2 млрд адресов, то он вас задосит"

Все дойдет до сервиса глобального обнаружения ддос в этих ваших интернетах

ipv6 никто не отменял

Это теория

Все дойдет до сервиса глобального обнаружения ддос в этих ваших интернетах

Угу

Хотя, с v6 тоже все просто: ты видишь что паразитный трафик льется из какой-то конкретной подсети и просто фильтруешь ее.

Мне одному кажется, что проблему ддоса надо решать на уровне магистрали?

Мне одному кажется, что проблему ддоса надо решать на уровне магистрали?

это всем кажется, но не все магистрали умеют это решать

ky

как относишься к заббиксу?

я его не юзаю

ты настоящий?

Я неплох

неп лох?

а вот настоящий бы его юзал :(

про Apache, nginx и прочие вещи - я вижу, что вы тут спорите, но не до конца очевиден ответ на вопрос выше) с позиции перфекциониста, что лучше для нагруженного пхп проекта на Symfony/Laravel? php-fpm + nginx или что-то другое? (напомню, речь не идёт о статике, статика отдельно на другом домене и другом сервере и вообще CDN)

php-fpm+nginx всё равно будет лучшей связкой как ни крути или же есть другие решения лучше? (чтобы было не 2 контейнера, а 1)

Мне одному кажется, что проблему ддоса надо решать на уровне магистрали?

далеко не все можно пофильтровать на уровне магистрали. Ну и магистральщики не будут заниматься анализом траффика твоего приложения.

дались тебе эти контейнеры )

ставь стандартную связку и все будет хорошо

php-fpm+nginx всё равно будет лучшей связкой как ни крути или же есть другие решения лучше? (чтобы было не 2 контейнера, а 1)

объедини nginx + php-fpm в один контейнер, не?

от затейник

ставь стандартную связку и все будет хорошо

так контейнеры это уже стандарт практически

нет, я к тому что ты хочешь один контейнер вместо двух

но речь тут о другом)

ну это просто чтобы красивее было))

так красиво все

мне почему-то кажется, что когда нет задач раздачи статики, то nginx тут без толку

для развлечения покэшируй ответы пхп :)

он нужен чтобы php-fpm подружить с https/2

не более того

ну вот, юникс вей. каждый софт делает то что должен, один процессит пхп, второй терминирует ссл и чо там еще нужно

просто мне казалось , что тот факт, что там это общение php-fpm и nginx едёт через 9000 порт какой-то, это всё замедляет, и что быстрее было бы, если бы была один единый сервер, который бы умел и php и http/2, что, например, uWSGI с php-плагином может потягаться тут со связкой nginx+php-fpm... думал, может, кто-то тесты нормальные проводил

да не сильно быстрее

тем более оно локально все гоняет

Огонь)

Оказывается, Twitch активно использует PostgreSQL - более 125 хостов только под него. В своем блоге они опубликовали историю того как они масштабируют postgres на несколько регионов в Амазоне. https://blog.twitch.tv/how-twitch-uses-postgresql-c34aa9e56f58 #twitch #postgresql #postgres #amazon #aws

Оказывается, Twitch активно использует PostgreSQL - более 125 хостов только под него. В своем блоге они опубликовали историю того как они масштабируют postgres на несколько регионов в Амазоне. https://blog.twitch.tv/how-twitch-uses-postgresql-c34aa9e56f58 #twitch #postgresql #postgres #amazon #aws

👍

Вот еще интересное, но на 4 часа просмотра

Яндекс опубликовал серию докладов о своей инфраструктуре: Краткое содержание: https://youtu.be/9ANuWEZqCUg?t=592 - Рассказ про Яндексовый MapReduce https://youtu.be/9ANuWEZqCUg?t=4454 - Рассказ про декларативный язык для MapReduce (и не только) https://youtu.be/9ANuWEZqCUg?t=9401 - Рассказ про ClickHouse (теперь уже OpenSource база данных для различных задач в области Real-Time аналитики) https://youtu.be/9ANuWEZqCUg?t=13555 - Storage в Яндексе (на примере архитектуры Яндекс.Диска). #Yandex #ClickHouse #Infrastructure #Storage #MapReduce

"TL;DR" нету для видео?

я первые два онлайн смотрел, там нельзя tl;dr сделать )

"TL;DR" нету для видео?

увы, не для всех можно.

про кликхаус - если интересует аналитика то стоит к нему присмотреться - он быстр и масштабируем.

плюсую. я для маленькой подделки юзаю в проекте

потому что там C++, с ассемблерными вставками и всякое такое.

ну там много всего )

сама БД колоночная

ну да

только дописывание и чтение

А что тест aphyr говорит про click house?

колоночная БД со сжатием, очень сильно оптимизированная под чтение.

А что тест aphyr говорит про click house?

нет теста - ничего не говорит

Плохо 😔

плохо не плохо, а опенсорс и бесплатно = гуд

моя табличка на 50 млн строк с лайк запросами в мускуле умирала, я успевал кофе сварить в гейзерной кофеварке. в кликхаусе за пару секунд

Плохо 😔

база молодая, а чувак один тест делает от 3 до 12 недель только

так что может через полгоода чо-нить будет

если ему кто-нибудь ее подсунет

рано или поздно, будет, ага

(т.е. база недавно в опенсорсе)

Не пробовал в постгрес записать с gin индексом?

Не пробовал в постгрес записать с gin индексом?

оно под задачи аналитики быстрее постгреса будет

не успел, переезжать с мускуля на посгрес в работающем приложении. где фичи наращиваются — трудновато

потому что оптимизация под аналитику

и да, оно будет точно быстрее

Это Константину было. Про мускуль

тем не менее. колоночная БД в разы шустрее для аналитики, чем реляция

как минимум пощупать стоит :D