3. Это я чего-то решил, что это конфигурационный файл. А это просто лог. Сорри.
4. Ага, я это умудрился пропустить.
6. Можно и так. Кстати, неплохо было бы сделать это решение generic, то есть изобразить некий API, которому передается соответствие обработчиков таскам, количество воркеров, а остальное он сам делает. И другой generic API, который позволит таски создавать.
Каким эмпирическим путем можно подобрать правильное количество воркеров в пуле?
Путем тестирования на заранее определенном наборе фидов, приближенном к реальности настолько, насколько это возможно.
Остается только ввести перелинковку данных чтобы картинка знала к какому документу она принадлежит, документ знал к какому фиду, а фид к категории.
Это решается при создании таска. Фид, создавая таски для документов будет просто передавать себя или свой id как параметр таска.
Таймауты пришлось делать декоратором т.к. повесить таймаут на выполнение одной задачи штатными средствами кажется не представляется возможным. hmm
Выглядит страшно :). Моя практика показывает, что когда в питоновом коде нечто выглядит сложно, то это либо спроектировано, либо реализовано неверно. Можете объяснить в чем проблема, которую вы решили таким способом?
Идея думаю по крайней мере спорная
согласен, убедили. Но в текущей реализации меня смущает одна вещь. pool.join будет ждать пока все воркеры не завершаться, насколько я понимаю. Это не позволит достичь оптимальной загрузки канала. Нужно опускаться ниже, реализовывая создание и запуск Greenlet-ов самостоятельно. Это поможет не ждать, пока весь пул воркеров освободится, а сделать так, чтобы задачи подбирались не пачками, как сейчас, а сразу. Впрочем это можно и отложить на потом, поскольку лучшее - враг хорошего.