On 18.01.2013 22:09, Михаил Монашёв wrote:

>>> Возможно стоит сделать что-то вроде онлайн-сервиса по улучшению
>>> конфига: человек закачивает свой конфиг, выбирает свою операционку,
>>> параметры железа, настройки ОС и получает в ответ: здесь
>>> proxy_cache_lock on; можно прописать и сократить нагрузку на
>>> бэкенд, тут if хорошо бы через map переписать, тут backlog можно
>>> увеличить, чтобы всплески нагрузки лучше обслуживать и т.д.

>> закачивать конфиги на какой-то левый сайт вряд ли кто-то станет...

> Так я и предлагаю сие на nginx.com сделать, как альтернативу твоим
> вполне обоснованным предложениям. Тем более, если сам вебсервер не
> посчитали левым, то и его сайт тоже таким не посчитают. Т.е. юзер
> закачивает конфиг, отвечает на разные вопросы, потом ему предлагают
> где чего и зачем можно в конфиге добавить/изменить, он осознанно
> добавляет/изменяет и получает новый конфиг, который обязуется
> сохранить старый конфиг на всякий случай и хорошенько протестировать
> новый перед работой.

обычно у пользователей на машинах "конфиг nginx" - это понятие
растяжимое на десятки и сотни файлов. основной конфиг - nginx.conf
в который потом включаются файлы с фрагментами для отдельных сайтов

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

обычно скрипты запускаемые на локальной машине удобнее.
хотя бы потому что им не надо будет вручную рассказывать какая
конфигурация машины и какой тип нагрузки (это можно взять из логов)

и как потом монетизировать этот сервис - обвешать его баннерами?

>>> Такой сервис с одной стороны привлёк бы к nginx.com много
>>> вебмастеров, особенно неаглоязычных и нерусскоязычных, т.е. не
>>> имеющих сложившихся сообществ, с другой - конвертировал бы их в
>>> клиентов .

>> вообще-то, такой веб-сервис уже есть, http://forum.nginx.org/

> Вы предлагаете всё перечитывать или постить публично свой конфиг с
> вопросом: "Что тут можно улучшить?"

я не предлагаю, но видел такое неоднократно.
возможно причина этого в не совсем понятной и неидеальной документации.

>>> У Петра Зайцева есть похожая тулза по генерации размеров буферов для
>>> mysql-я.

>> это не на сайте, это отдельные скрипты:

>> http://mysqltuner.com/

>> https://launchpad.net/mysql-tuning-primer

>> плюс похожая функциональность встроена в http://www.phpmyadmin.net/

> Разнообразие предлагаемого сервиса косвенно говорит о востребованности
> такого оптимизатора конфига и для nginx-а. Тем более в мускуле шибко
> не натюнишь, там параметров десятка два всего в самом сложном случае.

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

> А в nginx-е есть огромное непаханное поле.

параметров больше, но они разнесени по модулям и почти ортогональны.
основные проблемы с IfIsEvil и нигде не документированным порядком
отработки модулей - какой на какой фазе, и какой раньше другого -
это все определяется часто экспериментально или вопросами в рассылке.

хотя, для наиболее часто используемых вариантов - могут быть просто
примеры документации, которые можно использовать как best practices.
пока что единственное исключение из этого правила -
это описание директивы try_files:

location / {
try_files /system/maintenance.html
$uri $uri/index.html $uri.html
@mongrel;
}

- на самом деле, это пример, как делать ни в коем случае нельзя.
потому что при наличии файла /system/maintenance.html он будет
отдаваться клиентам и поисковым машинам с кодом 200, чем будут
введены в заблуждение все поисковые машины - они это проиндексируют
вместо содержимого сайта и сайт фактически пропадет из поисковиков.

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru