ну вот же наврал
заявил, что давно уже поставил два пакета.
Ну скажем, быстро не нашел готового рецепта. Тупо удобнее на обычном императивном языке программирования изобразить условную логику.
И зачем мне изучать как это сделать на неудобном ресурсопотребляющем 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, а это как понять? (хотя это и убунта)
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. Что теперь, называть их глупыми ? Просто остальным так удобнее.
Почитал. В принципе интересно, но ввиду наличия nginx теперь уже вряд-ли пригодится.
в world, те кто не знают про nginx, в качестве замены используют lighttpd, squid, varnish. Т.е. НЕ apache. По крайней мере lighttpd и varnish специально созданы для тех, кого апач не удовлетворял.
ну я посмотрел там в пакете :
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.
В конце концов возьми да поставь два пакета.
думаешь, кому-то интересно что там у тебя? разговор был так вообще о ландшафте. Спустя годы распространения nginx, mpm event уже нужен только любителям всякого ентерпрайза для нестандартных модулей апача.
А кто их делал ? Я не помню в старом треде о сравнительной эффективности nginx и apache mpm event никаких тестов. Мне, кстати, преимущества nginx очевидны без тестов просто исходя из архитектуры приложений.
Тут не было речи о тебе. Оно актуально вообще. Это решение в ispmanager не возникло на пустом месте. Рынок потребовал - они реализовали. Одно твое оригинальное мнение ничего уже не изменит.
Зачем вообще вносить смуту ? Два разных апача попортят стройную систему из двух пакетов и каталогов с настройками apache и nginx. Как этими двумя апачами потом управлять? Как поставить в том же дебиане mpm-event, если пакет конфликтует с другими mpm ?
Ничего хорошего. Оно увеличение энтропии от тебя.
Да все как и раньше - это обобщенный опыт.
Тут же все в довольно узком для mysql применении обсуждается. Обычные сайты и движки. Можно обобщить и сказать, что 50% - это уже достаточно хорошо и смысла гнать дальше нет. Почему желателен кеш минимального удовлетворяющего размера, надеюсь, уже ясно. Я прекрасно осознаю, что можно и ошибиться со специфичным движком, но, на мой взгляд, это грубое правило работает.
myhand, предположу что мысль была :
128мб - это вполне себе для попаданий в кеш на уровне 58.2%.
А при последующем увеличении до 1024 мб процент попаданий был 61.4% .
Так что уменьшив до 64мб может быть осталось на том же уровне около 50%.
Ну и нет смысла бороться за 2-5 процентов, если риск нестабильности скорости выполнения запросов вырастает значительно.
Что было до этого в dmesg ?
Можно сделать контрольную перезагрузку. Иногда даже порт "отлипает" после этого и можно smart почитать.
А фиг его знает. поставьте 64мб если веруете в глобализацию, унификацию, макдоналдс и многопроцессорность.
Или нанимайте myhand на целый месяц.
Vin_cent,
query_cache_size=1024M - перебор в большинстве случаев. не похоже что вы подобрали это значение как оптимальное экспериментально.
general_log_file = /tmp/general-mysql-log - а что вы делаете с этими данными из этого файла потом? если это просто результат гугления, то отключайте. Сервер ведь пишет в файл все запросы и нагружает диск.---------- Добавлено в 18:33 ---------- Предыдущее сообщение было в 18:31 ----------
так вы все еще сами не определились есть ли проблемы или нет?
если все пользователи довольны тем как открывается сайт - проблем нет.
