semenov, картинку вижу. а где слова ?
тут вообще ничего не понял.
хорошо, с терминологией определились.
Обсуждение началось с вашего заявления о равноценности mpm_event и nginx на фронтенде. Только это утверждение я оспариваю.
ну вот и подождем.
semenov, это что?
если тебе нужна маска для проверки твоей бесполезной идеи - нарисуй сам надпись auto.ru . совмести с прозрачностью 50% с типичным фото (должны быть разные области от темных до светлых)
а потом в фотошопе попробуй найти последовательность действий, которая даст исходное изображение.
Если получится в фотошопе без применения ручной ретуши и копирования, то значит и закодировать такое плевое дело.
Наложение знака есть НЕОБРАТИМОЕ попиксельное смешение двух картинок.
Все эти рассуждения верны разве что при наложении лого с прозрачностью 50% на черный фон. Но там обычное фото, а не черный фон.
если пиксель белый (255,255,255) то при наложении белого лого, он остается белым (255,255,255) и непонятно как произвести обратное преобразование. Сколько не "вычитай" будет только темнее и хуже. Белый - это предельно плохой случай, черный - предельно хороший для этого алгоритма с вычитанием яркости. Все остальные цвета - тоже плохие в разной степени.
Ну а зачем nginx нужно больше для активных соединений ? Все остальное это буферы. Их размер скромный и конечный. А вот апач в данной ситуации понаплодит переменных во всех своих модулях просто потому что модули написаны для традиционной модели.
Тут "стандартный" не в смысле ограниченности некоторых программистов стандартами, а в том смысле, что эта модель не является изобретением Сысоева лично. Просто одна из известных моделей обработки, особенно выгодная при обслуживании большого числа сетевых соединений.
но при операциях с сокетам и файлами нужно копаться в структурах данных ядра, так что происходит.
Да вы вон лучше какому-нибудь любимому клиенту фронтенд c nginx на апач смените и проверите на практике. Наверняка, такие найдутся.
Желательно проект побольше. С несколькими физическими бекендами.
нет речь шла о общем расходе памяти. все потоки apache против всех потоков nginx (из которых спокойно можно оставить один ). активные потоки имеют свои локальные переменные и их в сервере общего назначения много.
прикладной программист на своем уровне абстракции может и не понять о чем речь. речь о переключении контекстов процессора. сохранение регистров cpu и прочих состояний потока, для того чтобы cpu мог оставить один поток и обрабатывать другой. при этом при переключении локальные данные потока начинают вылетать из кеша процессора.
Если потоков много, а ядер процессоров мало, переключение контекстов обязательно возникает. Чем больше потоков тем более выражены негативные эффекты. Отсюда и советы сделать число воркеров nginx равное числу ядер.
Более того, переключение контекстов происходит каждый раз и при вызове фунций ОС. Эффективные приложения пытаются минимизировать и число вызовов ОС тоже. Например, пытаются запихнуть в один вызов максимально много данных. Тут очень к месту приходятся специальные вызовы ОС : select, epoll, фильтры httpready и т.д.
В апаче, как в сервере общего назначения для прикладных программистов, этого всего нет и не будет.
А в nginx, в свою очередь, никогда не возникнет mod_php.
Это все стандартная модель работы серверов описанная в литературе. Не обязательно читать код nginx, чтобы понимать как и почему он эффективно работает. Так же работают lighttpd, squid, varnish и менее известные программы.
Да, в последовательном порядке. Однако, благодаря использованию неблокируемых функций ввода-вывода даже при больших io_wait потоки nginx не тормозятся.
И это не то, что называется AIO в nginx. Использование AIO еще больше сокращает необходимость в системных вызовах.
Использование sendfile вообще исключает переключение контекстов во время отправки файла по сети, так как ядро полностью берет на себя все связанные с отправкой функции.
Ms-Dred, а почему именно screen ?
можно просто зациклить в bash. goto 1 и все.
теоретически при очень большой нагрузке oom-killer может остановить даже bash. тогда еще можно в /etc/inittab вписать скриптик
проще прикинуть хотя бы расходы памяти. они сокращаются до вышеназванных 2.5 мб на 10000 + фиксированной объем на одного worker. И больше никаких расходов нет.
Посчитать эффект от принципиального несоздания потоков по сравнению с их созданием и поддержкой сложно. Но он точно есть.
В промежутках между состояниями keep-alive, фронтенд не может быстро отправить ответ клиенту и освободиться. Все время отправки файла поток в апаче занимает и память и ресурсы ОС. Потоков много и CPU постоянно занимается переключением контекстов. mpm_event устраняет только лишь фазу keep-alive ожидания потоком клиента.
В nginx в принципе такого не возникает. Если конечному автомату нечего делать в данном соединении, он обрабатывает следующее не переключая контекст процесса.
полна фигня. эти параметры в данном случае ничем не помогут тс ввиду малозначительности влияния описанных процессов на кеширование содержимого файлов. Объем памяти занимаемый приложениями и структурой ФС слишком маленький.
другие параметры есть?
хотелось бы повысить эффективность кеша, о чем в вопросе и было написано, а не изменить его размер на 1%.
нет. я свою часть нашел. теперь вы найдите.
для меня сравнительная эффективность модели сервера "конечный-автомат без потоков" как в nginx, при обслуживании многих клиентов очевидна.
