В конце концов возьми да поставь два пакета.
Давно уже. Я не фантазирую "вообще" - а рассказываю как действительно можно сделать.
заявил, что давно уже поставил два пакета.
myhand: Что, nginx переплюнул даже RewriteMap с тьюринг-полным обработчиком? А как такое может быть, извините пожалуйста?
Ну скажем, быстро не нашел готового рецепта. Тупо удобнее на обычном императивном языке программирования изобразить условную логику.
И зачем мне изучать как это сделать на неудобном ресурсопотребляющем apache, если я уже знаю как это сделать в nginx.
На самом деле мне нужно в некоторых случаях исправить заголовки ответа бекенда,а не URL. В mod_headers по-моему логика ограничена .
Нужно было модифицировать часть заголовка, если он явно неправильный. Например, вместо "Content-type: image/gif; Charset=UTF-8", сделать "Content-type: image/gif". Даже не представляю что там в mod_headers нужно выдумать. Можешь, конечно, выдумать из интереса.
И это реальный пример из жизни. Просто приложение на бекенде слишком сложное, чтобы разумно было искать почему оно выдает такие заголовки.
madoff, в качестве фронтэнда только одна конфигурация ради того самого http/1.1 на прокси и с крайне низкой нагрузкой.
зато есть примеры где никакой rewriterule в apache не помог, в отличие от lua в nginx.
myhand: Ну, панелька - просто средство для управления конфигурацией. Почему повесить один и тот же бинарник на разные порты с разными конфигами - это "извращение", а повесить разные бинарники - нет.
Да потому что так сложилось. Извращение - это все то то, чего не использует целевая аудитория ispmanager.
Ты не целевая аудитория, поэтому с твоя точка зрения не имеет голоса.
myhand: Повторяю, они уже стоят у вас
но пакетов то нет. ты не мог поставить два пакета одновременно. наврал.
apt-get install apache2-mpm-event
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
apache2-mpm-worker
The following NEW packages will be installed:
apache2-mpm-event
Совершенно точно нельзя поставить два пакета mpm одновременно.
Панель вообще должна минимально извращаться чтобы не запутать администратора. Текущее решение ispmanager просто ставит два пакета, все красивенько и традиционно работает.
Симлинки способны запутать. Все остальное точно было бы хуже.
Ну не подумали они про myhand. Что теперь, называть их глупыми ? Просто остальным так удобнее.
myhand: Вопчем, читай /usr/share/doc/apache2.2-common/ - много нового для себя найдешь.
Почитал. В принципе интересно, но ввиду наличия nginx теперь уже вряд-ли пригодится.
madoff: Не стоит отвечать за world
в world, те кто не знают про nginx, в качестве замены используют lighttpd, squid, varnish. Т.е. НЕ apache. По крайней мере lighttpd и varnish специально созданы для тех, кого апач не удовлетворял.
Та же фигня в остальных пакетах mpm. Вроде, конфликтует с любым другим пакетом предоставляющим apache2-mpm.
В конце концов возьми да поставь два пакета.
myhand: 2) "Управлять апачами" - можно потом точно также, как ты сейчас управляешь nginx+апачем. Разница только в том, что у тебя установлено два разных сервиса, с разными конфигами. А у меня - один (бинарник один, набор модулей общий), просто запущены несколько копий его с разными настройками (здесь такой mpm подключу и модули, там сякой).
В общем, народ этого давно ждал.
думаешь, кому-то интересно что там у тебя? разговор был так вообще о ландшафте. Спустя годы распространения nginx, mpm event уже нужен только любителям всякого ентерпрайза для нестандартных модулей апача.
myhand: Вы хоть раз сами проверяли что практически дает эта раздача статики, в сравнении с простым проксированием?
А кто их делал ? Я не помню в старом треде о сравнительной эффективности nginx и apache mpm event никаких тестов. Мне, кстати, преимущества nginx очевидны без тестов просто исходя из архитектуры приложений.
myhand:
а в других случаях использование nginx+apache само по себе не очень-то актуально
Это только потешные хлопцы из ispmanager по-умолчанию такой "оптимизированный" конфиг предлагают.
Тут не было речи о тебе. Оно актуально вообще. Это решение в ispmanager не возникло на пустом месте. Рынок потребовал - они реализовали. Одно твое оригинальное мнение ничего уже не изменит.
Зачем вообще вносить смуту ? Два разных апача попортят стройную систему из двух пакетов и каталогов с настройками apache и nginx. Как этими двумя апачами потом управлять? Как поставить в том же дебиане mpm-event, если пакет конфликтует с другими mpm ?
Тут же все в довольно узком для mysql применении обсуждается. Обычные сайты и движки. Можно обобщить и сказать, что 50% - это уже достаточно хорошо и смысла гнать дальше нет. Почему желателен кеш минимального удовлетворяющего размера, надеюсь, уже ясно. Я прекрасно осознаю, что можно и ошибиться со специфичным движком, но, на мой взгляд, это грубое правило работает.
query_cache_size=1024M - перебор в большинстве случаев. не похоже что вы подобрали это значение как оптимальное экспериментально.
general_log_file = /tmp/general-mysql-log - а что вы делаете с этими данными из этого файла потом? если это просто результат гугления, то отключайте. Сервер ведь пишет в файл все запросы и нагружает диск.
---------- Добавлено в 18:33 ---------- Предыдущее сообщение было в 18:31 ----------
Vin_cent: проблемы на данном этапе решены. Или нет?
так вы все еще сами не определились есть ли проблемы или нет?
если все пользователи довольны тем как открывается сайт - проблем нет.
ну вот же наврал
В конце концов возьми да поставь два пакета.
Давно уже. Я не фантазирую "вообще" - а рассказываю как действительно можно сделать.
заявил, что давно уже поставил два пакета.
Что, nginx переплюнул даже RewriteMap с тьюринг-полным обработчиком? А как такое может быть, извините пожалуйста?
Ну скажем, быстро не нашел готового рецепта. Тупо удобнее на обычном императивном языке программирования изобразить условную логику.
И зачем мне изучать как это сделать на неудобном ресурсопотребляющем apache, если я уже знаю как это сделать в nginx.
На самом деле мне нужно в некоторых случаях исправить заголовки ответа бекенда,а не URL. В mod_headers по-моему логика ограничена .
Нужно было модифицировать часть заголовка, если он явно неправильный. Например, вместо "Content-type: image/gif; Charset=UTF-8", сделать "Content-type: image/gif". Даже не представляю что там в mod_headers нужно выдумать. Можешь, конечно, выдумать из интереса.
И это реальный пример из жизни. Просто приложение на бекенде слишком сложное, чтобы разумно было искать почему оно выдает такие заголовки.
madoff, в качестве фронтэнда только одна конфигурация ради того самого http/1.1 на прокси и с крайне низкой нагрузкой.
зато есть примеры где никакой rewriterule в apache не помог, в отличие от lua в nginx.
Ну, панелька - просто средство для управления конфигурацией. Почему повесить один и тот же бинарник на разные порты с разными конфигами - это "извращение", а повесить разные бинарники - нет.
Да потому что так сложилось. Извращение - это все то то, чего не использует целевая аудитория ispmanager.
Ты не целевая аудитория, поэтому с твоя точка зрения не имеет голоса.
Повторяю, они уже стоят у вас
но пакетов то нет. ты не мог поставить два пакета одновременно. наврал.
myhand, а это как понять? (хотя это и убунта)
Совершенно точно нельзя поставить два пакета mpm одновременно.
Панель вообще должна минимально извращаться чтобы не запутать администратора. Текущее решение ispmanager просто ставит два пакета, все красивенько и традиционно работает.
Симлинки способны запутать. Все остальное точно было бы хуже.
Ну не подумали они про myhand. Что теперь, называть их глупыми ? Просто остальным так удобнее.
Вопчем, читай /usr/share/doc/apache2.2-common/ - много нового для себя найдешь.
Почитал. В принципе интересно, но ввиду наличия nginx теперь уже вряд-ли пригодится.
Не стоит отвечать за world
в world, те кто не знают про nginx, в качестве замены используют lighttpd, squid, varnish. Т.е. НЕ apache. По крайней мере lighttpd и varnish специально созданы для тех, кого апач не удовлетворял.
Не дезинформируйте читателей. Разные MPM в дебиане не конфликтуют.
ну я посмотрел там в пакете :
Package: apache2-mpm-prefork
Depends: apache2.2-common (= 2.2.16-6+squeeze4), apache2.2-bin (= 2.2.16-6+squeeze4)
Conflicts: apache2-common, apache2-mpm
Provides: apache2, apache2-mpm, httpd, httpd-cgi
Та же фигня в остальных пакетах mpm. Вроде, конфликтует с любым другим пакетом предоставляющим apache2-mpm.
В конце концов возьми да поставь два пакета.
2) "Управлять апачами" - можно потом точно также, как ты сейчас управляешь nginx+апачем. Разница только в том, что у тебя установлено два разных сервиса, с разными конфигами. А у меня - один (бинарник один, набор модулей общий), просто запущены несколько копий его с разными настройками (здесь такой mpm подключу и модули, там сякой).
В общем, народ этого давно ждал.
думаешь, кому-то интересно что там у тебя? разговор был так вообще о ландшафте. Спустя годы распространения nginx, mpm event уже нужен только любителям всякого ентерпрайза для нестандартных модулей апача.
Вы хоть раз сами проверяли что практически дает эта раздача статики, в сравнении с простым проксированием?
А кто их делал ? Я не помню в старом треде о сравнительной эффективности nginx и apache mpm event никаких тестов. Мне, кстати, преимущества nginx очевидны без тестов просто исходя из архитектуры приложений.
Это только потешные хлопцы из ispmanager по-умолчанию такой "оптимизированный" конфиг предлагают.
Тут не было речи о тебе. Оно актуально вообще. Это решение в ispmanager не возникло на пустом месте. Рынок потребовал - они реализовали. Одно твое оригинальное мнение ничего уже не изменит.
Зачем вообще вносить смуту ? Два разных апача попортят стройную систему из двух пакетов и каталогов с настройками apache и nginx. Как этими двумя апачами потом управлять? Как поставить в том же дебиане mpm-event, если пакет конфликтует с другими mpm ?
Ничего хорошего. Оно увеличение энтропии от тебя.
Почему?
Да все как и раньше - это обобщенный опыт.
Тут же все в довольно узком для mysql применении обсуждается. Обычные сайты и движки. Можно обобщить и сказать, что 50% - это уже достаточно хорошо и смысла гнать дальше нет. Почему желателен кеш минимального удовлетворяющего размера, надеюсь, уже ясно. Я прекрасно осознаю, что можно и ошибиться со специфичным движком, но, на мой взгляд, это грубое правило работает.
myhand, предположу что мысль была :
128мб - это вполне себе для попаданий в кеш на уровне 58.2%.
А при последующем увеличении до 1024 мб процент попаданий был 61.4% .
Так что уменьшив до 64мб может быть осталось на том же уровне около 50%.
Ну и нет смысла бороться за 2-5 процентов, если риск нестабильности скорости выполнения запросов вырастает значительно.
Что было до этого в dmesg ?
Можно сделать контрольную перезагрузку. Иногда даже порт "отлипает" после этого и можно smart почитать.
По поводу query_cache_size, ткните пожалуйста носом, как определять оптимальный размер?
А фиг его знает. поставьте 64мб если веруете в глобализацию, унификацию, макдоналдс и многопроцессорность.
Или нанимайте myhand на целый месяц.
Vin_cent,
query_cache_size=1024M - перебор в большинстве случаев. не похоже что вы подобрали это значение как оптимальное экспериментально.
general_log_file = /tmp/general-mysql-log - а что вы делаете с этими данными из этого файла потом? если это просто результат гугления, то отключайте. Сервер ведь пишет в файл все запросы и нагружает диск.
---------- Добавлено в 18:33 ---------- Предыдущее сообщение было в 18:31 ----------
проблемы на данном этапе решены.
Или нет?
так вы все еще сами не определились есть ли проблемы или нет?
если все пользователи довольны тем как открывается сайт - проблем нет.