А, обнаружил. Почему-то первым выбран «Мобильный интернет»…
Введите как на хабре счетчик по каждому из вариантов —
Услуги: Мобильный интернет(0), Мобильная связь(2)
И показывать «по умолчанию» надо непустой список.
4. Собственно, если вы каждый раз об этом спросите — так не требуйте этих прав изначально. Просите их прямо со стороны fb в момент когда это понадобится.
5. Собственно, вы эти все данные берёте в момент авторизации (п.1) — зачем вам нужен п.5 — не раскрыто.
Пытаюсь авторизоваться через лицокнигу, и наблюдаю форменный звезделец:
gToday is requesting permission to do the following:
1. Access my basic information (Includes name, profile picture, gender, networks, user ID, list of friends, and any other information I've made public.)
2. Access my profile information (Birthday)
3. Send me email (gToday may email me directly at {email})·
— ладно, я могу понять.
4. Post to Facebook as me (gToday may post status messages, notes, photos, and videos on my behalf)
5. Access my data any time (gToday may access my data when I'm not using the application)
А вот это нафига?!
Так я и пишу — если nginx, то мы получим тормоза а не ошибку для простых пользователей.
Пришло 200 клиентов, запросило страницу. 8 из них получило ответ через 0.05. 8 следующих получило через 0.1… 200й клиент получил страницу через секунду.
А теперь пришло 1000 клиентов. Время ожидания стало 5 секунд. Простой пользователь, который придёт сюда уже будет недоволен и слиняет.
А теперь работает 2к ботов. 10 секунд — уже никуда не годится и народ распугает напрочь.
А rate control, группировку запросов по ip, и прочие радости делают не заранее, а когда появляется потребность. Глупо заранее тюнить сайт с посещаемостью в 20 уников чтоб держал 20кк.
Любой сайт с динамикой «ляжет» от детского доса — так или иначе.
Простая арифметика: генерация страницы занимает 0.05 секунды, 8 ядер => 160 страниц враз максимум.
Так что поток в 200 запросов одновременных «забьёт» так, что пользователи будут ощущать жесткие тормоза по нескольку секунд и больше если стоит nginx впереди, или получать timeout если не стоит.
Да он нужен просто чтоб чуть срезать скорость роста атаки. Если его нет — никакой проблемы.
Как я ответил в привате вопрошавшему, «забивается» не iptables, а conntrack.
Поэтому либо raw таблица и резать сразу в raw/PREROUTING (прямо по IP, без порта); либо просто выгрузить conntrack из ядра, чтобы фильтрация шла stateless. Она летает и с сотнями тысяч правил справляется вполне бойко.
Помню, сколько-то лет назад был патч на iptables, меняющий логику работы с цепочек на матрицу, так там оно работало с сотнями тысяч правил на довольно дохлом железе. Правда, возможности чуть более куцые были. Где он сейчас и живёт ли еще — не знаю… Для меня хватает стандартной поставки дебиана + tarpit когда не влом скомпилять через m-a
Тогда как «локальная» копия just works.
Введите как на хабре счетчик по каждому из вариантов —
Услуги: Мобильный интернет(0), Мобильная связь(2)
И показывать «по умолчанию» надо непустой список.
5. Собственно, вы эти все данные берёте в момент авторизации (п.1) — зачем вам нужен п.5 — не раскрыто.
gToday is requesting permission to do the following:
1. Access my basic information (Includes name, profile picture, gender, networks, user ID, list of friends, and any other information I've made public.)
2. Access my profile information (Birthday)
3. Send me email (gToday may email me directly at {email})·
— ладно, я могу понять.
4. Post to Facebook as me (gToday may post status messages, notes, photos, and videos on my behalf)
5. Access my data any time (gToday may access my data when I'm not using the application)
А вот это нафига?!
Linux kernel source tree
480.5 KB | 415 forks | 3393 watchers | last activity about 5 hours ago
Пришло 200 клиентов, запросило страницу. 8 из них получило ответ через 0.05. 8 следующих получило через 0.1… 200й клиент получил страницу через секунду.
А теперь пришло 1000 клиентов. Время ожидания стало 5 секунд. Простой пользователь, который придёт сюда уже будет недоволен и слиняет.
А теперь работает 2к ботов. 10 секунд — уже никуда не годится и народ распугает напрочь.
А rate control, группировку запросов по ip, и прочие радости делают не заранее, а когда появляется потребность. Глупо заранее тюнить сайт с посещаемостью в 20 уников чтоб держал 20кк.
Простая арифметика: генерация страницы занимает 0.05 секунды, 8 ядер => 160 страниц враз максимум.
Так что поток в 200 запросов одновременных «забьёт» так, что пользователи будут ощущать жесткие тормоза по нескольку секунд и больше если стоит nginx впереди, или получать timeout если не стоит.
Как я ответил в привате вопрошавшему, «забивается» не iptables, а conntrack.
Поэтому либо raw таблица и резать сразу в raw/PREROUTING (прямо по IP, без порта); либо просто выгрузить conntrack из ядра, чтобы фильтрация шла stateless. Она летает и с сотнями тысяч правил справляется вполне бойко.
Помню, сколько-то лет назад был патч на iptables, меняющий логику работы с цепочек на матрицу, так там оно работало с сотнями тысяч правил на довольно дохлом железе. Правда, возможности чуть более куцые были. Где он сейчас и живёт ли еще — не знаю… Для меня хватает стандартной поставки дебиана + tarpit когда не влом скомпилять через m-a