Предлагаете пытаться объяснить не админам как устроен worker nginx? Поверьте, я прекрасно знаю почти все блокирующие операции для workera, прекрасно знаю какие из них починят в 1.0, прекрасно знаю ситуации, когда стоит использовать 24 процесса.
Что-то Вы странное говорите, наверно, у Вас весьма слабые знания о работе и разработке nginx. Блокировки там уже убраны отовсюду, откуда можно (сетевой aio, дисковый aio, даже написан свой thread-safe strerror_r()). А главное нововведение версии 1.0 будет появление фиксированного внутреннего API для модулей и документации по нему.
Хотя, мне интересно услышать Вашу трактовку и о том, какие блокировки когда починят (желательно, со ссылками на рассылку/конференции).
Я не могу придумать ни одной ситуации, когда нужно использовать 24 процесса. Могу придумать ситуацию, когда нужно использовать 4 процесса, и могу придумать ситуацию, когда нужно использовать 240 процессов. Но не между :( Можете просветить и по этому поводу?
По тех.части: Виртуальный хостинг очень и очень сложная штука. Нужно быть умелым во многих направлениях.
Например наш инженер собирает ядра по три-четыре штуки за ночь. Потому что когда ставишь, то получает "немного не тот результат, что хотел" и потому сразу когда собирается, то собирается несколько комплектов. Вы соберете несколько ядер за ночь? Нужно уметь находить технологии в интернете (это тоже трудоемко). Нужно уметь прогнозировать проблемы (на стадии 100 сайтов у Вас одни проблемы, на стадии 700 - совершенно другие. На стадии 1500 - третьи). Вы должны заранеее просчитать их и быть готовыми. Нужен опыт у другого провайдера, прежде чем строить что-то свое. Нужен стрессоустойчивый саппорт, потому что иногда тесты нужно проводить на боевых машинах (не возможно создать такую же разнообразную нагрузку на тестовых) - а это взрыв тикетки.
Просто любопытно - вы ребутите сервера по три раза за ночь, или используете какие-нибудь ksplice?
а на mpm-itk сработает?
Уязвимость какого рода? Прочитать конфиги/файлы пользователей или remote root или local root?
Или пропишите в крон дёрганье главной страницы раз в минуту :)
Boris A Dolgov, Ну почему же... Воркер на поток?
Разве что для image-filter-модуля.
Предлагаете пытаться объяснить не админам как устроен worker nginx? Поверьте, я прекрасно знаю почти все блокирующие операции для workera, прекрасно знаю какие из них починят в 1.0, прекрасно знаю ситуации, когда стоит использовать 24 процесса.
Что-то Вы странное говорите, наверно, у Вас весьма слабые знания о работе и разработке nginx. Блокировки там уже убраны отовсюду, откуда можно (сетевой aio, дисковый aio, даже написан свой thread-safe strerror_r()). А главное нововведение версии 1.0 будет появление фиксированного внутреннего API для модулей и документации по нему.
Хотя, мне интересно услышать Вашу трактовку и о том, какие блокировки когда починят (желательно, со ссылками на рассылку/конференции).
Я не могу придумать ни одной ситуации, когда нужно использовать 24 процесса. Могу придумать ситуацию, когда нужно использовать 4 процесса, и могу придумать ситуацию, когда нужно использовать 240 процессов. Но не между :( Можете просветить и по этому поводу?
>> Есть такой не-апаче...
>Есть. Но раздавая файлы на скорости 100 мбит он кушает значительно больше 128 мб VIRT.
Тюнингуйте буферы и количество клиентов :)
madoff, с лозунгом "контролировать систему должен root, а не панель"
Тем не менее, пользователи уверены, что контролировать систему должна панель.
Просто EasyApache не просто так писали.
myhand, вы уже научились раздавать статику, забивая ею 100 мбитный канал, тратя на это 96-128 мб VIRT ?
Есть такой не-апаче...
Фу, сколько мусора на се
По тех.части:
Виртуальный хостинг очень и очень сложная штука. Нужно быть умелым во многих направлениях.
Например наш инженер собирает ядра по три-четыре штуки за ночь. Потому что когда ставишь, то получает "немного не тот результат, что хотел" и потому сразу когда собирается, то собирается несколько комплектов. Вы соберете несколько ядер за ночь? Нужно уметь находить технологии в интернете (это тоже трудоемко). Нужно уметь прогнозировать проблемы (на стадии 100 сайтов у Вас одни проблемы, на стадии 700 - совершенно другие. На стадии 1500 - третьи). Вы должны заранеее просчитать их и быть готовыми. Нужен опыт у другого провайдера, прежде чем строить что-то свое. Нужен стрессоустойчивый саппорт, потому что иногда тесты нужно проводить на боевых машинах (не возможно создать такую же разнообразную нагрузку на тестовых) - а это взрыв тикетки.
Просто любопытно - вы ребутите сервера по три раза за ночь, или используете какие-нибудь ksplice?
По Москве, говорят, сейчас вообще опасно ходить :)