- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Тем не менее, знаю хостеров, которые лет 5 его используют успешно. Под тысячи сайтов на каждом сервере. Это тоже о чём-то говорит?
И никаких взломов, никаких особых проблем и т.п.
Естественно есть другие решения, но и это имеет право на существование.
Тем не менее, знаю хостеров, которые лет 5 его используют успешно. Под тысячи сайтов на каждом сервере. Это тоже о чём-то говорит?
Вариантов много:
1) "тысячи сайтов" нафиг никому не упали, вместе с хостером
2) они не используют дырявые модули, работающие _до_ понижения привилегий (напр., mod_ssl) в MPM itk
3) они своевременно патчат апач
Естественно есть другие решения, но и это имеет право на существование.
Конечно. ТС важно понять, что это решение для массового виртуального хостинга. Если у него десяток сайтов - лучше придумать что-то другое.
Мы и для массового сейчас используем другие решения. Важно понимать, что mpm-itk даст ещё определённое снижение производительности и его объём зависит от количества пользователей/сайтов и нагрузки. Да и смотря под какие скрипты используется.
в itk рутовый процесс не занимается обработкой данных
Dimanych, fcgid чем не вариант?
Это ведь подобие PHP-FPM?
Там нельзя использовать php value в htaccess и ещё какие то минусы были.
Это разве минусы? Незачем php value там использовать. Но можно использовать полностью свой php.ini, добавлять туда подгрузку своих модулей и т.п.. Может это скорее плюс?
2 минуса,
первый, php.ini на юзера, а .htaccess на директорию
второй, обычный пользователь который ставит какую то CMS а там эти переменные и у него работает всё не так как надо, начинает много курить и терроризировать суппорт)
первый, php.ini на юзера, а .htaccess на директорию
второй, обычный пользователь который ставит какую то CMS а там эти переменные и у него работает всё не так как надо, начинает много курить и терроризировать суппорт)
1. Только если экзотический скрипт ставите, который потребует какого-нибудь небезопасного register_globals. Тут его можно включить любо глобально, либо для одного сайта. Но правильный путь - такие скрипты не использовать вообще.
А популярным CMS экзотики не требуется.
2. Убираем переменные и всё работает "как надо". Если CMS из популярных, то там эти значения задаются "на всякий случай". Поэтому можно всё поправить в php.ini
P.S.: Сейчас посмотрел на одном из серверов с fastcgi, там крутится 547 сайтов, которые никаких проблем с fastcgi не испытывают :)
первый, php.ini на юзера, а .htaccess на директорию
В php 5.3.x + есть .user.ini
Очень удобно.
Наверное стоит задуматься перейти, основная масса же всё равно WP / DLE / JOOMLA.
Что мне в itk не нравится, порой память закушает всю из-за php))
Это можно исправить