По поводу скорости не скажу, чисто визуально выбрал бы первый вариант из двух предложенных.

А в идеале использовал бы селектор в вызове parents
el.parents('.container')
el.parents('li')


В той же статье, ссылку на которую дал bekbulatov было решение, но его оттуда удалили в пользу передачи request как параметра.

Можно посмотреть в предыдущую версию. Там используется Middleware для глобального доступа к объекту user, но переделать на request будет не сложно.

Использовать стоит не когда «не хочется всегда передавать это объект в качестве аргумента», а когда такой возможности просто нет.

И не забывайте что код может быть вызван не только из view'хи, но и скажем с management-комманды или консоли.

В свое время использовали Siege-тест чтобы проверить разные возможные конфигурации

Тут надо учитывать особенность питона и в частности GIL, так что задачи требующии процессорного времени не паралеляться с помощью потоков, даже при наличии нескольких ЦП. С другой стороны для задач требующих ввода/вывода потоки дают свой прирост, к тому же поток потребляет меньше памяти, чем целиком процесс.

Если ваша программа не полагается на однопоточность, то нет смысла иметь количество процессов значительно превышающих количество ЦП/ядер. Идеальней будет использовать гибрид, количество процессов под количество ЦП, количество потоков… ну тут зависит больше от того, сколько памяти. У нас на разных проектах это обычно 5-25 потоков.

Коллективный интеллект пытался породить ее здесь — djangopackages.com/ Проверяю его и гугл перед тем как что-то делать. А «пытался» потому что частенько в гугле находятся apps которые более reusable, чем представленные на том сайте.

Что же касается меня

• Во все свои проекты сразу добавляю South
  
• Для авторизации через соц сети — django-social-auth
  
• Есть проект со всякими мелкими утилитами, django-annoying