- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Я не очень сильна в вышеозвученных настройках. Так сапа работать будет или нет, по предварительным прогнозам? Неужели там мало саповодов на хостинге, что к ним (=нам) такое пренебрежительное отношение...
Запаролся, простите :)
Прочитал ваше mod_php как suPHP :)) рябит уже, видимо к НГ дело :D
suphp - это был удачный костыль для apache 1.3, который являлся вполне сносным решением 3 года назад. На сегодня он уже устарел. Как и сам apache 1.3. Все плюшки suphp сегодня можно получить за счет других средств, которые обеспечивают более высокую производительность и являются более универсальными.
Затем, что mod_php для целей виртуального хостинга - решение значительно более производительное (менее затратное по ресурсам), чем cgi/fcgi. Другое дело, что не все понимают архитектуру apache и понятия не имеют какие воркеры для чего нужны. При правильном подходе можно использовать mod_php без проблем с правами.
В посте выше я имел в виду apache prefork + mod_php.
itk безусловно можно использовать и проблем с правами не будет.
Так сапа работать будет или нет, по предварительным прогнозам?
Вы видимо еще и в форумах не разбираетесь, представители вашего хостинга пишут своим клиентам обычно на своих форумах или в личных кабинетах через тикеты ... и.т.п, по этому тут вам мало вероятно кто-то даст ответ на указанный выше вопрос. Но вопросительные предложения начинающиеся словом "так", звучат угрожающе :D
---------- Добавлено 31.12.2012 в 03:22 ----------
suphp - это был удачный костыль для apache 1.3, который являлся вполне сносным решением 3 года назад. На сегодня он уже устарел. Как и сам apache 1.3. Все плюшки suphp сегодня можно получить за счет других средств, которые обеспечивают более высокую производительность и являются более универсальными.
Немного пруфов не помешает, всегда рад ознакомиться с новой для себя информацией.
Я использую Apache/2.2.22 + mod_suphp, это сильно плохо? ;)
Я не очень сильна в вышеозвученных настройках. Так сапа работать будет или нет, по предварительным прогнозам?
Об этом только хостеру известно.
Неужели там мало саповодов на хостинге, что к ним (=нам) такое пренебрежительное отношение...
Тут дело не в сапе. Ваша сапа - это частный случай одной большой, давно известной проблемы, которой уже есть много решений. Тут дело в непонимании техническим персоналом базовых, фундаментальных вещей.
Я от них сбежал еще года два назад :)
Romka_Kharkov, вы, вероятно, не пользуетесь хостингом Мажордомо ;). Иначе вы бы знали, что отвечают они мягко говоря, не сразу. Зачастую - на следующий день.
Немного пруфов не помешает, всегда рад ознакомиться с новой для себя информацией.
Какие Вам нужны пруфы? Вы на архитектуру посмотрите. suPHP - это модуль апача, который занимается только тем, что в момент запроса он дергает РНР интерпретатор, ставит ему setUID и подсовывает интерпретатору скрипт для выполнения. "Дергание" интерпретатора на каждый запрос - операция накладная (в терминологии ресурсов). Поскольку каждый раз нужно "подымать" с диска в память сам интерпретатор, ворох модулей к нему, приклеивать модули к нему, лепить это все в одно целое и только после этого РНР сможет начать заниматься обработкой скрипта. Т.е. перед тем как запрос начнет обрабатываться должно пройти какое-то время, которое будет потрачено на накладные расходы - "компилирование" интерпретатора.
Совсем другая ситуация в случае ITK, который по своей сутки является префорком, который позволяет использовать mod_php. Тут алгоритм обработки несколько иной. Во-первых интерпретатор компилируется один раз - в момент запуска апача. Дальше экземпляры интерпретатора размножаются путем дешевого (в терминологии затрат ресурсов) fork'а. Во-вторых, в памяти постоянно префоркнуто несколько экземпляров. При поступлении запроса картина его обработки выглядит следующим образом: пришел запрос на выполнение скрипта, готовому интерпретатору делается setUID и передается скрипт для выполнения. Как видите накладная операция компилирования интерпретатора отсутствует.
Если провести аналогии с арендой серверов, то это примерно выглядит так:
suPHP: пришел клиент, попросил сервер в аренду. Едем к поставщику шасси, берем шасси, по пути заезжаем к другому поставщику за процессором, потом на другой конец города за винтами, звоним четвертому, просим подвезти память, приезжаем, собираем, выдаем. Клиент доволен.
prefork: Пока у нас было свободное время - мы заранее подготовили 10 серверов типичных конфигураций. Пришел клиент, попросил сервер в аренду. Оплатил и моментально получил сервер, который был установлен нами заблаговременно. Клиент счастлив.
Есть еще peruser, который префоркает уже setUID'нутые процессы, что еще более ускоряет обработку запроса. Но проблема в том, что ему нужно держать в памяти минимум один процесс на каждый виртуалхост. Что при нескольких сотнях виртуалхостов будет иметь примерно такие же последствия как если взять и просто отстрелить себе ногу. Не настолько накладен setUID, чтобы сотни апачей в памяти висели.
Тут вот еще почитать можно:
http://blog.stuartherbert.com/php/2008/01/18/using-suphp-to-secure-a-shared-server/
http://blog.stuartherbert.com/php/2008/04/19/using-mpm-itk-to-secure-a-shared-server/
http://blog.stuartherbert.com/php/2008/03/20/using-mpm-peruser-to-secure-a-shared-server/
аналогичная проблема с мажордомо
осталось там несколько сайтов :(
написал им тоже в поддержку, лайв-чат целый день сегодня был недоступен
ответа никакого :(
Я использую Apache/2.2.22 + mod_suphp, это сильно плохо? ;)
Нет, не сильно. Латентность suPHP клиенты на глаз вряд ли увидят, а если и увидят, то она будет скорее всего не значительной. Разница хорошо будет видна только на графике загрузки CPU и, возможно, DISK IO.