# Re: Небольшая DDoS-атака на 51t.ru
51t (lenina,1) → zhuk@ – 06:04:41 2014-08-22
да, lim=all рабоает медленновато для больших эх, и напрягать систему - запросто.
> В связи с этим у меня вопрос: если запустить несколько несколько bottle.py параллельно, не будет ли гонок по доступу к ресурсам?
они уже есть, из-за фетчеров. до них вообще почти все данные держались напрямую в памяти, и доступ к ним был мгновенно. после - практически всё это было отключено на тот случай, если упрёмся в лимиты. раз упёрлись - надо опять данные лимитировать, и или:
1. делать демона, который раз в n-минут обновляет состояние (понятия не имею, как это делается)
2. запустать фетчер изнутри сервера (проблемный вариант)
3. как-то фетчером сообщать, что данные обновлены (я вообще изначально хотел сделать url типа /update, и чтобы его фетчер дёргал, но, наверное, есть и другие пути) [если вот тут как-то по-умному придумать - будет хорошо]
второй путь - это много ботлепуев. это делается через gunicorn. но тогда, опять же, надо смотреть, какие данные НЕ ПЕРЕДАЮТСЯ в рамках процесса. python мне тем и хорошо, что я могу, в отличие от php, легко делать глобалы и не дёргаться по пустякам. мне не нравится вариант "много ботлепуев" именно из-за того, что нельзя делать простое кэширование многих данных
третий вариант, что называется, в лоб - многопоточность через gevent. просто поставь py-gevent, и я её могу хоть щас включить, раз время подошло.
а вообще, простой в несколько секунд - это не страшно. ты для сравнения irk38.tk помониторь, и посмотри, как он отдаётся... или представь дозвон до нода на 1200 без коррекции ошибок :) читать логи мониторинга - только себя пугать на каждый чих :)
51t (lenina,1) → zhuk@ – 06:04:41 2014-08-22
да, lim=all рабоает медленновато для больших эх, и напрягать систему - запросто.
> В связи с этим у меня вопрос: если запустить несколько несколько bottle.py параллельно, не будет ли гонок по доступу к ресурсам?
они уже есть, из-за фетчеров. до них вообще почти все данные держались напрямую в памяти, и доступ к ним был мгновенно. после - практически всё это было отключено на тот случай, если упрёмся в лимиты. раз упёрлись - надо опять данные лимитировать, и или:
1. делать демона, который раз в n-минут обновляет состояние (понятия не имею, как это делается)
2. запустать фетчер изнутри сервера (проблемный вариант)
3. как-то фетчером сообщать, что данные обновлены (я вообще изначально хотел сделать url типа /update, и чтобы его фетчер дёргал, но, наверное, есть и другие пути) [если вот тут как-то по-умному придумать - будет хорошо]
второй путь - это много ботлепуев. это делается через gunicorn. но тогда, опять же, надо смотреть, какие данные НЕ ПЕРЕДАЮТСЯ в рамках процесса. python мне тем и хорошо, что я могу, в отличие от php, легко делать глобалы и не дёргаться по пустякам. мне не нравится вариант "много ботлепуев" именно из-за того, что нельзя делать простое кэширование многих данных
третий вариант, что называется, в лоб - многопоточность через gevent. просто поставь py-gevent, и я её могу хоть щас включить, раз время подошло.
а вообще, простой в несколько секунд - это не страшно. ты для сравнения irk38.tk помониторь, и посмотри, как он отдаётся... или представь дозвон до нода на 1200 без коррекции ошибок :) читать логи мониторинга - только себя пугать на каждый чих :)