Я как раз пробовал и не писал, что нельзя сопоставлять названия ip в этом случае. Но это получается список, который к тому же, надо помнить, и если хостов больше десятка, это уже проблема.
Селектор в виде дерева с категориями, и возможно и большей вложенностью, из которого можно выбрать, куда удобнее чем писать user@myhost. Ну и такая штука масштабируется на сотню хостов совершенно спокойно, у меня примерно столько, и я не путаюсь.
Валентин Когда хостов не несколько, а много, решает выбор из списка, желательно не из плоского. Запоминать массу названий вместо ip, решение, но так себе... Вообще, есть софтина, которая это умеет через curses, я правда не пользовался уже лет сто и не помню, как она называется, но всё равно это не так удобно.
+1 за то, что это не очень-то полезно, но только, если это не сильно навороченная железка, для которой есть замена с той же версией фирмвари, если что.
Т.е. большинство простеньких хардварных рейдов не имеют заметных плюсов перед mdadm, а минусы есть.
Не то, чтобы это так уж удобно как десктопный/мобильный клиент, с сохранёнными сессиями в виде дерева, вкладками и.т.п. Вариант, в целом, рабочий, хотя назвать его более интересным, явное преувеличение.
Проблема, очень вероятно, в не очень корректном переносе конфигурации приложения в nginx, а про mod_security "отписка" автора софта у которого нет желания углубляться в проблему, или просто один из пунктов его чеклиста поиска соответствующей проблемы...
Но можно подождать, что нам напишет автор вопроса, про конфигурацию его сервера, есть-ли там апач, и.т.п.
Ок. Но крайне мало вероятно, что он у автора вопроса магически оказался - его нет в репозиториях, надо собирать руками, он ещё не релизнулся и.т.п.
Вообще у nginx есть ещё NAXSI, если уж всё вспоминать, но опять же, вероятность того, что он сконфигурирован ничтожна.
Во-первых, модули вам не используемые, но собранные не мешают - это совершенно не годный аргумент.
По поводу "стандартного вида" - вам не хватало какого-то модуля? Его случайно нет, в виде отдельного пакета, в том же репозитории? А если нет, его было не собрать как внешний? Nginx это теперь умеет - он больше не монолитен. И это было бы более разумной в целом идеей...
Собирая его самостоятельно из исходников, как и любой другой софт в пакетном дистрибутиве, вы создаёте себе лишние сложности в виде необходимости каждый раз пересобирать этот софт при обновлении, по меньшей мере. И это может быть и удобно, в случае разработки, но в долгосрочной перспективе это ведёт обычно к отсутствию или, как минимум, не своевременности обновлений, или необходимости тратить заметно больше времени на обслуживание, и следить за куда большим спектром софта, чтобы своевременно обновляться, в случае выхода заплаток безопасности, например...
А каким образом вы собираетесь назначать новый uid? Его не получится поддерживать одновременно уникальным и соответствующим порядку timepub просто отдельными запросами(даже если он будет разреженным) - придётся массово переколбашивать его у множества записей для изменения порядка же. А без соответствия эта операция просто бесполезна.
По поводу больших данных - не выводят много данных таким методом. Никто не будет просто листать бесконечную ленту. Т.е. они не бесконечны, на самом деле. И закладываться на то, что когда-нибудь надо вывести будет 100500 элементов в таком списке совершенно не разумно, а на разумных количествах ваш подход это бессмысленная оптимизация, которую и не сделать будет так просто, как вы думаете, к тому же.
Даже если у вас и будет в базе очень много записей, и какой-то пользователь будет уж очень упёрт, раньше браузер к него ляжет от размера страницы, чем mysql, тот же, от запросов с лимитом, если уж на то пошло...
Ну и если это ему действительно нужно зачем-то окажется, то это будет означать, что у вас интерфейс как-то не так спроектирован. =)
На просторах сети пишут очень много, в частности бреда, и почти всегда, просто не упоминают границы применимости советов. Надо понимать правильно, и думать, что в действительности будет работать, а что нет в вашем случае, а не тупо следовать написанному кем-то. Эта оптимизация действительно очень важна, когда данных много, и когда нет возможности кешировать результаты выборки. В вашем же случае, это вполне нормально можно использовать.
Зачем вам limit 1000,1040? Нужен limit 1000,40. К тому же, пребор 1000 записей, это не так уж проблемно - это совсем мало данных, а сотнями тысяч и тем более милионами строк, никто не будет скролить ваш список, если вообще там есть столько. Мало того, эти запросы можно же кешировать, если у вас нагрузка велика.
server {
listen 80;
server_name trilliant.host;
if ($host = trilliant.host) {
return 301 https://$host$request_uri;
}
return 404;
}
Вот это всё зачем вам? У вас нет тут https нигде. Или в первой секции server надо написать listen 443 ssl; и добавить ключи. Да и редирект надо не так делать - и условие не нужно и 404 вообще лишнее тут.
Andrey Виртуалка за $5-10/мес вполне потянет по объёму хранилища все ваши текущие проекты. И позволит развернуть удобное для работы окружение с отладкой, профайлером и прочими полезностями.
Если для вас такая сумма за хостинг велика, вы занимаетесь не тем, вероятно.
Афанасий Захаров Возможно, если у него явно и постоянно завышено напряжение, например.
Но вообще, нужна нагрузка хотя бы, и крайне желателен осциллограф, чтобы посмотреть пульсации.
Селектор в виде дерева с категориями, и возможно и большей вложенностью, из которого можно выбрать, куда удобнее чем писать user@myhost. Ну и такая штука масштабируется на сотню хостов совершенно спокойно, у меня примерно столько, и я не путаюсь.