да, lim=all рабоает медленновато для больших эх, и напрягать систему - запросто.

> В связи с этим у меня вопрос: если запустить несколько несколько bottle.py параллельно, не будет ли гонок по доступу к ресурсам?

они уже есть, из-за фетчеров. до них вообще почти все данные держались напрямую в памяти, и доступ к ним был мгновенно. после - практически всё это было отключено на тот случай, если упрёмся в лимиты. раз упёрлись - надо опять данные лимитировать, и или:

1. делать демона, который раз в n-минут обновляет состояние (понятия не имею, как это делается)

2. запустать фетчер изнутри сервера (проблемный вариант)

3. как-то фетчером сообщать, что данные обновлены (я вообще изначально хотел сделать url типа /update, и чтобы его фетчер дёргал, но, наверное, есть и другие пути) [если вот тут как-то по-умному придумать - будет хорошо]

второй путь - это много ботлепуев. это делается через gunicorn. но тогда, опять же, надо смотреть, какие данные НЕ ПЕРЕДАЮТСЯ в рамках процесса. python мне тем и хорошо, что я могу, в отличие от php, легко делать глобалы и не дёргаться по пустякам. мне не нравится вариант "много ботлепуев" именно из-за того, что нельзя делать простое кэширование многих данных

третий вариант, что называется, в лоб - многопоточность через gevent. просто поставь py-gevent, и я её могу хоть щас включить, раз время подошло.

а вообще, простой в несколько секунд - это не страшно. ты для сравнения irk38.tk помониторь, и посмотри, как он отдаётся... или представь дозвон до нода на 1200 без коррекции ошибок :) читать логи мониторинга - только себя пугать на каждый чих :)