@SalatProduction Не уверен, что правильно понимаю Ваш вопрос - как именно лимитировать каунты? Ведь в подзапросе он считает всё, Вы хотите считать только часть? Ну, можно в подзапрос загнать условие WHERE. Кстати, подзапрос можно же вообще вытащить из этого запроса и гонять отдельно - это не будет хуже работать.
Да, сделать два запроса - это пока что лучший вариант. Когда он перестанет быть лучшим, скажем, из-за нагрузки на диск, лучшим вариантом станет хранить пользовательские данные не в трех таблицах, а в одной и сериализовать информацию о новостях и торрентах в какой-нибудь JSON.
@vlad_was_here 13-й mint должен довольно сильно отличаться от 17-го. MySQL, скорее всего, не отличается - MySQL вообще довольно давно стабилизировался и сильно не меняется. Apache, скорее всего, тоже, хотя я не помню, чем в Ubuntu соответствуют 13 и 17 mint - мог и перешагнуть через мажорную версию апач, хотя вряд ли. А вот PHP, скорее всего, уже другой. Прямой перенос конфигов и файлов может и не сработать, но начать можно с него - только нужно поставить все необходимые пакеты сначала.
@powerthrash Я подозреваю, если написать туда любую другую программу, которая не является шеллом - результат будет таким же. Если написать просто набор букв и цифр - результат будет таким же. Но вот если программно заводить пользователей, указывая в качестве шелла что-то, чего нет в /etc/shells - может получиться не очень хорошо. И редхэтовский стандарт - это именно /sbin/nologin.
@bk0011m если у пользователя вместо шелла стоит /sbin/nologin в /etc/passwd, то подбирать пароль можно сколько угодно - доступа к локальной системе это не даст.
А как шансы на то, что поломают связаны с виртуальностью пользователей? Чем вектора атаки в случае, если пользователи виртуальны, отличается от векторов атаки, если пользователи невиртуальны, но им запрещен логин в консоль?
А как из этого следует, что шифровать данные не надо? "Утюг, паяльник, etc" - тут можно пароль от чего угодно вспомнить, даже от тех вещей, от которых никогда и не знал его. Признаться в убийстве Кеннеди и все вот это вот.
Нет, вот как раз для nginx логи в сислоге - это не очень обычно. nginx по умолчанию не ведет логи в сислог, более того, до этого года он вообще туда их не мог вести.
@evnuh Я по умолчанию предполагаю, что коллега умеет использовать профайлер и пользоваться результатами профайлинга, то есть, знает, о чем спрашивает. Если же не умеет - ну вот оно, самое время научиться. Я же не могу за него его код отпрофайлить - у меня его нет.
@0neS Тащемта, когда нам стало не хватать скорости, с которой pure PHP protobuf разборщик работает - мы его просто заменили на модуль на C и боттлнек вообще пропал. Где было 80% времени - стало меньше процента, а работы было на два часа.
Да, селери подойдет, мои коллеги, разрабатывающие веб-приложение на питоне, именно его и используют. Будет ли плохой производительность? Я сильно сомневаюсь, что Вы упретесь в производительность сетевого взаимодействия. Если все это на одной машине - точно не упретесь. Если все это в одной гигабитной сети - не упретесь довольно долго (сложно прогнозировать, не зная деталей бизнеса и приложения).
