Как выбрать по-настоящему хороший хостинг

    Почти на каждом сайте разработчиков платных тиражных CMS есть раздел «Сертифицированные хостинг-провайдеры», или «Рекомендуемые хостинги», или просто «Хостинги».



    Разработчик CMS проверяет соответствие характеристик тестового тарифа, предоставленного хостером, минимальным техническим требованиям своей CMS. В идеале – устанавливает на этом тестовом тарифе свою систему и выполняет базовые операции.

    Хостинг-провайдер попадает в список протестированных (сертифицированных) хостеров… и – обычно – на этом все взаимодействие с ним и заканчивается.

    В 2008-ом году мы шли по этому же пути. Некоторой (полезной – на наш взгляд) особенностью было то, что для успешной сертификации тарифов помимо собственно тестов требовалось прохождение двух наших онлайн-курсов («Установка и настройка» и «Конфигурирование») сотрудниками хостера. Это давало нашим клиентам некоторую гарантию того, в случае возникновения каких-либо проблем или вопросов на данном конкретном хостинге его сотрудники будут готовы оказать необходимую помощь.

    Однако в конце 2010 года мы поняли, что настала пора что-то менять в нашем партнерстве с хостинг-провайдерами. И вот почему…
    • К 2010-му году наш каталог хостинг-партнеров насчитывал более 100 компаний. При этом каталог был простым списком, не было никакой системы рейтингования. Иначе говоря, такой каталог становился совершенно бесполезным для конечных клиентов, так как не давал никакой помощи в выборе подходящего хостера.
    • Не было актуализации данных. Простой пример: хостер А создавал новый тариф хостинга под названием «Битрикс», который показывал отличную производительность. Затем через полгода-год забивал новые серверы клиентами так, что все просто еле шевелилось… Но мы об этом, к сожалению, уже не знали.

    Устранение именно этих ключевых недостатков (а также несколько дополнительных приятных фич, о которых – немного дальше) – главная цель нового каталога-рейтинга «Рекомендуемых хостингов», который мы открыли в этом году.

    О том, как мы тестируем хостинги, на что обращаем особое внимание, что вообще нужно иметь в виду при выборе хостинга любому клиенту, — хотим рассказать вам сегодня.
    • Во-первых, мы сохранили все те требования к хостинг-провайдерам, которые существовали и раньше (соответствие тарифов техническим требованиям CMS, прохождение курсов сотрудниками хостера).
    • Во-вторых, для тестов тарифов теперь не только проверяется соответствие формальным требованиям, но еще делается «живая» установка демо-сайта, для того, чтобы сделать замеры скорости работы с помощью «монитора производительности».
    • В-третьих, для каждого тарифа в каталоге осуществляется повторное тестирование каждые 6 месяцев.


    Для расчета позиции хостера в рейтинге мы придумали вот такую формулу:



    Остановлюсь на ней подробнее.

    С тестовым периодом — все понятно. Наличие «простой установки» — это возможность инсталляции продуктов «1С-Битрикс» непосредственно из панели управления хостингом или же с помощью предустановленного скрипта bitrixsetup.php.

    Основным критерием для определения позиции хостера в рейтинге стало соотношение «производительность / цена».

    Параметр «цена» был добавлен очень осознанно. За последние годы сложилась нехорошая практика у хостинг-провайдеров: «Мы берем стандартные тарифы хостинга, немного тюним на них параметры, дописываем слово «Битрикс» и вешаем ценник в полтора-два раза больше обычного. Клиент купил CMS, купит и хостинг!»

    Такая картина не устраивала ни нас, ни клиентов, ни партнеров-разработчиков. Если хостер выделил под спец. тарифы отдельное оборудование, сделал нужные настройки, размещает на каждом сервере не слишком много аккаунтов – в этом случае повышенная цена (за качество и комфорт) обоснована. Просто за название (без отличий от стандартных тарифов) – нет.

    Если с «измерением» цены все просто и понятно, то с «производительностью» все не слишком очевидно. Расскажу о ней подробно.

    Для замеров мы используем возможности стандартного модуля платформы «1С-Битрикс» — «Монитор производительности».



    Вкладка «Конфигурация» отвечает за диагностику хостинга или сервера и настроек серверого ПО, вкладка «Битрикс» — те настройки самой платформы, которые могут влиять на производительность, «Разработка» — качество кода разработчика, «Масштабируемость» — простой встроенный инструмент для проведения простейших нагрузочных тестов.

    Самый интересный для нас раздел – «Конфигурация». Именно им мы и пользовались, тестируя хостеров.

    Один из самых частых вопросов, на который нам приходилось отвечать: «Как мы можем верить вашей измерялке, если она меряет производительность в каких-то непонятных «попугаях»? Почему у нас на мощном железе получаются низкие цифры? Ваша формула врет!»

    И здесь я развенчаю один из самых давних мифов. Состоит он в том, что существует некая магическая секретная формула, хитрым образом перемножающая разные цифры из таблицы (количество файловых операций, CPU, операции с базой данных и т.п.) и дающая в итоге то самое итоговое число.

    Такой формулы нет! :)

    Как работает монитор производительности

    Мы запрашиваем несколько раз (10, если быть точными) некоторую системную страницу, на которой загружается только ядро продукта. По результатам 10 замеров оцениваем среднее время генерации этой страницы (именно серверное, а не время передачи страницы клиенту). Именно эта цифра есть «среднее время отклика». А общий итоговый индекс – это обратная величина. В нашем случае – 1/0.0137. Иными словами, на нашем тестовом хостинге за 1 секунду может быть сгенерировано 72 «пустые» (только с ядром) страницы.

    Именно эта величина важна, так как для клиента имеет значение именно то, с какой скоростью открывается его сайт (генерируются страницы), а не каждый параметр по отдельности. Они указываются скорее для того, чтобы системный администратор (или даже просто опытный пользователь) мог быстрее и проще определить, где в его системе «узкие» места.

    (Более подробно о работе монитора производительности можно прочитать в блоге Дениса Шаромова, руководителя службы технической поддержки «1С-Битрикс»)

    С формулой разобрались и возвращаемся к нашим тестам.

    Опыт тестирования нескольких десятков (уже близко к сотням) хостингов показал интересную картину: к счастью, хостеры не очень часто экономят на оборудовании, но, к сожалению, очень часто «тянут» за собой историческое наследие старых конфигураций и неоптимальных структур хостинга. «Новички» рынка тоже, к сожалению, очень часто не дают максимальной производительности и совершают одни и те же типовые ошибки.

    Хотел обратить внимание на некоторые из них. Думаю, это будет полезно для тех, кто тщательно выбирает хостинг, тестируя разные варианты.

    PHP как CGI

    PHP, запускаемый как CGI (не FastCGI!) – страшный атавизм. Быть такого не должно.

    Чем такая схема плоха. Если в двух словах – на каждое обращение к php-скрипту запускается новый процесс интерпретатора PHP. Все это работает очень медленно, производительность сайта (любого сайта, написанного на PHP, не только на платформе «1С-Битрикс») будет крайне низкой.

    Такие конфигурации, к счастью, встречаются все реже (за последние полгода в реальной жизни мы с таким не сталкивались), но, тем не менее, пока еще существуют.

    Включенный параметр open_basedir в конфигурации PHP

    Наверное, все знают, за что отвечает этот параметр – ограничивает «область видимости» файлов и директорий, которыми может оперировать PHP.

    Многие хостеры включают этот параметр на виртуальном shared хостинге в целях обеспечения безопасности пользовательских данных (ограничивая доступ других пользователей на том же сервере).

    Но далеко не все знают, что включение этого параметра снижает производительность PHP на 10-40%, а на нагруженных системах (особенно с большим количеством дисковых операций) – до 2-3 раз!



    Смотрите, вот – тот же самый сервер, на котором выполнялся тест, показанный выше, но только с включенным open_basedir. Скорость генерации страниц снизилась почти в полтора раза. Мы видим, что конфигурация PHP отмечена «неоптимальной», а по ссылке «рекомендации» можно подробно прочитать о том, где именно возникают проблемы.

    Нам повезло, на этом конкретном хостинге мы можем управлять этим параметром в PHP. А на многих хостингах это – неотключаемо ни при каких условиях.

    Многие хостеры возражают нам: «Ну, сами понимаете, на шаред хостинге отключить это невозможно… Иначе будут проблемы с безопасностью.»

    Это утверждение неверно. Соблюсти баланс безопасности и производительности можно самыми разными методами: начиная с запуска персональных копий веб-сервера (например, тот же Apache) для разных пользователей, заканчивая использованием FastCGI через php-fpm. Кстати, разные хостеры в нашем рейтинге используют и тот, и другой вариант.

    Отмечу еще раз: данная особенность работы open_basedir присуща PHP вообще и всем проектам, написанным на этом языке, а не только платформе «1С-Битрикс» (попробуйте поискать, например, в Google «open_basedir performance»). Если ваш сайт на WordPress, Joomla, Drupal и любой другой CMS на PHP – обращайте на это внимание.

    Не установлен прекомпилятор PHP

    Еще один враг производительности – отсутствие на хостинге предустановленного прекомпилятора для PHP. Их существует достаточно много (APC, eAccelerator, XCache и т.п.), и все они выполняют примерно одну и ту же работу – ускоряют работу PHP, прекомпилируя интерпретируемый код. В зависимости от конкретного прекомпилятора, его настроек (например, количество доступной памяти), кода проекта прирост производительности может достигать нескольких раз.

    Помучаем еще раз наш тестовый хостинг, уберем включенный в предыдущем тесте open_basedir и отключим на время прекомпилятор.

    На наше счастье, мы проделываем все эти операции на том хостинге, где мы все можем настроить «так, как нужно» и в итоге получить хороший (быстрый!) хостинг. На многих хостингах, к сожалению, набор изменяемых пользователем опций строго фиксирован, и добиться хороших результатов (кроме как – поменять хостинг) не представляется возможным.

    Вернемся к цифрам:



    Обратите внимание, параметры сервера (CPU, дисковые операции), базы данных практически не изменяются (естественно!), а, вот, правильная конфигурация PHP решает все.

    Конечно, мы перечислили далеко не все вещи, которые влияют на производительность. Помимо собственно настроек PHP, имеют значение очень многие параметры конфигурации базы, правильно настроенные параметры веб-сервера, грамотно спроектированная двухуровневая (frontend+backend) архитектура…

    Бывают хостинги (к сожалению, совершенно реальные), на которых плохо просто все, и тогда получается вот такой «трэш и угар»:



    А на хорошем мощном железе, быстрых SAS-дисках, и при грамотных настройках – сайт просто «летает» (скриншот с реального, а не «сферического в вакууме» shared хостинга):



    * * *

    Еще один аспект, который хоть и не описан в формальных требованиях к хостерам, которые хотят пройти сертификацию «1С-Битрикс», но на который мы обязательно обращаем внимание – безопасность. Откровенно «дырявые» хостинги никогда не получают наши значки «Сертифицированный хостинг» и «Рекомендуемый хостинг».



    Самая частая проблема – open_basedir выключили, но никаких других средств изоляции пользователей не придумали. Что в итоге получается: все клиенты хостинга работают с одним и тем же веб-сервером, процессы которого запущены под одним системным пользователем (иногда это бывает даже root).

    В итоге каждый пользователь может «видеть» не только свои файлы и директории, но и данные других пользователей.

    Простейшие проверки можно выполнить в административном интерфейсе «1С-Битрикс»:



    Среди крупных известных хостеров мы, конечно, подобных откровенных «дыр» не нашли, но среди тех, у кого несколько десятков/сотен клиентов – сплошь и рядом.

    Будьте внимательны и бдительны при выборе хостинга.

    И если описанная выше проблема достаточно типична, то бывают и настолько безалаберные «хостеры», которые вызывают искреннее удивление – как они смогли привлечь хоть одного клиента.

    Пара самых ярких примеров на нашей памяти.

    Хостер У (потому что на Украине)

    Получили тестовый аккаунт, поставили демо-сайт — интернет-магазин на редакции «Малый бизнес» (мы все хостинги тестируем для единообразия именно этой редакцией). Сделали через веб-интерфейс «ls –la /tmp»… и увидели несколько десятков файлов вида «login.txt», в которых хранились все параметры доступа к FTP, SSH, MySQL всех пользователей хостинга.

    Хостер К (в Казахстане).

    Стандартная процедура, тестовый аккаунт. Все неплохо с производительностью и (на первый взгляд) с безопасностью.

    Тесты закончили, перешли на сайт самого хостера… И обнаружили, что над ним осталась верхняя административная панель Битрикса.

    Как оказалось, сайт хостера был сделан на нашей платформе. И был настроен так криво, что сохранял авторизационные данные с поддоменов (где и был тестовый аккаунт) на основном сайте.

    * * *

    Я сознательно не указываю в тексте названий конкретных хостингов (возможно, смогу дать те или иные конкретные рекомендации при личном общении).

    Нет цели очернить ту или иную компанию. Задача — показать, сколь много нюансов ожидает тех, кто подходит к вопросу выбора хостинга серьезно, а не действует наобум (хотя и здесь может повезти ;)).

    При этом, надеюсь, наш рейтинг на самом деле может помочь клиентам сделать выбор с учетом самых разных параметров хостинга — производительности, скорости работы сайтов на нем, стоимости тарифа, наличия тестового периода, удобства работы.

    При этом хостерам мы предлагаем понятную и прозрачную схему ранжирования в рейтинге. Тем самым — даем всем равные возможности для того, чтобы быть в топе. И тем самым — очень эффективно (в том числе и за счет нашего продвижения) привлекать новых клиентов хостинга! Как показывает наша статистика, за одну неделю со страниц рейтинга на сайты хостеров осуществляется до тысячи переходов. Это — почти готовые клиенты. :)

    Наш рейтинг хостеров мы будем активно развивать и, надеюсь, со временем сделаем отличный объективный рейтинг хостинга вообще, а не только «special for bitrix». Почему бы и нет? :)

    С уважением, Александр Демидов
    руководитель направления арендных решений «1С-Битрикс»
    1С-Битрикс 66,41
    Компания
    Поделиться публикацией
    Комментарии 97
    • 0
      А где «Хостер G» (потому что Germany)?
      • +3
        Если без иронии, то схема такова: хостер подает заявку на сертификацию и заполняет нужные данные. Иначе говоря — инициатор процесса именно хостер.

        «Хостер G» пока (!) просто не знает, что надо так сделать. ;)

        Но, думаю, обязательно применим опыт работы с нашими хостерами и на западное направление.
        • 0
          Просто сейчас уже очень много людей сотрудничают с немецкими хостерами и, я думаю, многим из них будет полезна такая информация.
          • +2
            У немцем, в основном, выбирают бюджетные dedicated. В данном случае — почти все зависит от грамотного администрирования.

            Критерии выбора того или иного провайдера уже несколько иные.
          • 0
            «Хостер Г» — смотрите скриншот выше, с производительностью «0,26» :-)
            • +2
              Не путайте G и Г! ;)
              • +2
                Да мы просто за столько лет с разными хостерами успели поработать среди которых хватало и Хостеров Г и Хостеров Х, Хостер М до сих пор снится в кошмарных снах…

                Остановились на Хостере Т — работаем 3 года, очень довольны :-)
        • +2
          Да, тема актуальная очень. Спасибо за полезную информацию.
          • +1
            Спасибо за статью. Особенно хочется плакать от хостеров У…
            • +1
              Мне кажется, ситуация с Хостером К гораздо потешнее.
              • 0
                Да я больше скорблю в принципе по поводу ситуации с хостингом в Украине…
                • 0
                  Ну а моя скорбь над головотяпством разработчиков интернациональна.
            • +3
              Александр, спасибо, прояснили некоторые факты =)
              Но есть сомнения, что хостинг за 100 рублей в месяц для БУС будет качественно работать с течением времени.
              Это я вам, как «доктор» объясняю (с) =)
              Я думал, что ниже нас в цене уже никто не упадет, а нет, ошибался =) Пойду потестирую...=)

              ps.
              Добавляйте отзывы (голосования) — будем видеть реальное положение дел.
              • 0
                Честно говоря, хостинг за 100 рублей и меня смущает. :) Но формально — все условия соблюдены.

                Посмотрим, что будет с пересертификацией. И да — добавим отзывы.
              • –3
                Ну да, как же. Тест должен быть скрытым и анонимным, чтобы попасть на самый обычный сервер к хостеру, а не такой, чтобы все знали, ага, вот Александр Демидов из Битрикса зарегистрировался, давайте-ка его на пустой сервер зарегаем, чтобы 700 запросов в секунду получить. Вы сами верите в эту цифру? И другие аналогичные из вашего топа… Виртуальный хостинг с 300 запросов в секунду? Бугога.
                • –2
                  Не 700, а 90-100, это я уже не на ту цифру посмотрел.
                  • +3
                    Стоп-стоп.

                    Разве где-то в тексте указано, как получается тестовый тариф?

                    Почти у всех сейчас так или иначе есть триальный период. Он заказывается под разными (реальными) именами, которые могут совершенно не ассоциироваться с Битриксом. По максимуму — под видом простого пользователя.

                    Интересуют конкретные результаты конкретных тестов — добро пожаловать, demidov@1c-bitrix.ru.
                    • 0
                      Да я знаю конкретные тесты. Видел ваши регистрации с этого самого мыла :)
                      Просто у меня есть конкретное недоверие к конкретным хостерам.
                      Кстати, как часто «переаттестация» будет проходить?
                • +1
                  А как читаемость файла /etc/passwd или каталога /home можем быть показателем безопасности хостинга?
                  • +1
                    Никак. Если брать просто вывод этих команд сам по себе.

                    Но если посмотреть чуть дальше, читаемость /home показывает, какие есть домашние директории, какие на них стоят атрибуты (права) и кто владелец файлов и директорий. Ну, а дальше можно сделать какие-то выводы… И т.д.
                    • 0
                      Можно сделать вывод, сколько сайтов на сервере и какие сайты. И все.
                      • 0
                        Точно? :)
                        А вариант 1 аккаунт — 17 сайтов не учитываем? А юзеры у нас, например, с цифрами, без смысловых слов, как узнать какое сайты? :)

                        Примерно узнать какие сайты на сервере не сложно и внешними средствами.
                        • 0
                          Ну, это у вас юзеры. Я видел, где домены, где еще как иначе.
                          • 0
                            НУ, а про сайты — это да. Бинг в помощь :)
                    • +12
                      Забавно наблюдать как битрикс рассуждает на тему хостинга… Донаписали б своё произведение до нормального, не пришлось бы говорить какой хостинг подходит по такое, какой нет… Один баг e404 чего стоил… сервер просто раком вставал от дрочки этого файла…
                      «Битрикс не ломают» да кому он на фиг нужен… тьфу! Битрикс хорошо пропиареное говно!
                      • +2
                        Все описанные в статьи моменты имеют примерно равное значение для любого приложения, написанного на PHP.

                        Для WordPress, Drupal, Joomla — все актуально.

                        У меня была идея поставить рядом все перечисленные системы (плюс Битрикс) и делать тесты не нашими внутренними инструментами (а в других системах их просто нет, к сожалению), а чем-то внешним — хоть ab, хоть JMeter.

                        Но это — гораздо более трудоемко, а результат вполне предсказуем.

                        Возможно, когда-нибудь сделаем такое более расширенное исследование.

                        Сейчас вполне уверенно (по многолетнему опыту работы в хостинге) могу сказать, что Битрикс не требовательнее к хостингу, чем тот же Друпал или Вордпресс.
                        • 0
                          Т.е. кроме своего велика вы предлагаете испытывать хостинг ещё другими инструментами, а при чем тут другие CMS?
                          И что предсказуемо?

                          з.ы. сорри, смысл ваших последних фраз не совсем понятен…
                          • +3
                            По многолетнему опыту работы с Битриксом могу сказать так — не было ни одного проекта, где бы не пришлось возиться с хостингом.

                            Особенно понравилась бага с глобальной переменной ID, если сервак ее резервирует, например для id юзера, то всё — админка не работает)

                            Я не знаю, где истина, но с Друпалами и Вордпрессами таких казусов никогда не было.

                            • –1
                              > Особенно понравилась бага с глобальной переменной ID, если сервак ее резервирует

                              Мне кажется, тут уже что-то не так с хостингом, а не с Битриксом. ;)
                              • –1
                                Неизвестно, тут нет левых и правых
                              • 0
                                Не совсем понятно что вы имеете в виду под " если сервак ее резервирует, "
                                • –1
                                  отдает, например, $_ENV['ID'] => 450009 или еще где-нибудь. Битрикс собирает это в $GLOBALS, а для добавления чего-нибудь в админке $ID должен быть = 0. И ищи сиди по сурсам где завтык)
                                  • +1
                                    Какую то странную проблему описываете, либо я чего то не понял. Но ничего подобного не наблюдал за Битриксом.
                          • –4
                            Хотите нормальный хостинг — берите в США или Britan. ИMXO СНГ просто и рядом не стоят…
                            • +4
                              Очень интересует борьба хостеров с нагрузками БД.
                              По моему опыту хостер частенько пресекает 60-80 запросов, на фирменных тарифах.
                              Планируете ли описать подобные ситуации.
                              Сколько запросов должны держать ваши сертифицированные хостеры?
                            • +2
                              60-80 — за какую единицу времени?

                              На мой личный взгляд, лимитировать количество запросов — вообще неверно. Можно смотреть на нагрузку по процессору, памяти и т.п. Но не запросы.

                              Как минимум, потому что один «тяжелый» запрос может стоить тысяч запросов, выданных из query cache'а.

                              По личному опыту — крайне неприятно получать сообщение об ошибке о лимите запросов, восстанавливая, например, базу из дампа.
                              • 0
                                отладка — статистика sql запросов,
                                хостер говорит — «ваш скрипт грузит базу», вы будете отключены
                                • 0
                                  На сертифицированных (точнее, «Рекомендуемых») хостингах такого быть не должно.

                                  Если есть конкретные примеры и проблемы — пишите, пожалуйста: demidov@1c-bitrix.ru.
                                  • +1
                                    ясно, спасибо.
                                    Было бы здорово, если бы вы тестировали хостеров такими нагрузками.
                                    И еще добавили информации в документации про запросы, нагрузки базы на процессор и т.п.
                                    Только Академия Долганина раскрывает приоткрывает немного занавес.
                                    • 0
                                      Такие тесты не получатся объективными.

                                      Они уже будут зависеть от каждого конкретного сайта, от качества разработки.

                                      Тестовый демо-сайт полезных данных даст очень мало.
                              • +1
                                я про количество запросов на странице которое отображается инструментом
                                • +1
                                  Спасибо, за интересную статью!

                                  Наконец-то мы узнали про эту магическую формулу расчета производительности =)
                                  • 0
                                    А правильно ли я понимаю, что рейтинг хостеров будет дополнен отзывами и рекомендациями клиентов?

                                    И, на самом деле, я рад что из рекомендованных хостингов исчез Мастерхост и РБК. У них традиционно тяжело с качественной настройкой PHP
                                    • +2
                                      Да, учет отзывов в том или ином виде будет.
                                    • +3
                                      Вот это цифры!
                                      Имею выделенный сервер в G от Hetzner EQ4, php работает как fastcgi, open_basedir выключен, eAccelerator стоит и настроен. На сервере есть пара сайтов, но посещаемость их незначительна, нагрузку практически не дают. Производительности Битрикса более 25 ни разу добиться не смогли. В чем секрет?
                                      • 0
                                        Разные факторы могут влиять. Например, редакция Битрикса (разный набор модулей).

                                        Хотите, можем посмотреть подробнее — demidov@1c-bitrix.ru.
                                        • +2
                                          там же и такой же сервер
                                          nginx+apache+apc(местами php-fpm)
                                          бус бизнес, серер под нагрузкой.
                                          image
                                          • +1
                                            Михаил, это Юрий из Русоникса :) Хороший виртуальный сервер может быть гораздо быстрее и производительнее чем даже Ваш мощный i7. А если еще и настроен под конкретный продукт, то тут вообще вне конкуренции.

                                          • +7
                                            Как оказалось, сайт хостера был сделан на нашей платформе. И был настроен так криво, что сохранял авторизационные данные с поддоменов (где и был тестовый аккаунт) на основном сайте.
                                            а. здесь я заплакал
                                            • 0
                                              шутка точно в народ пойдёт :)
                                            • +1
                                              Прошу прощения, а ls /etc/passwd это как? А кто его и зачем закроет? :)
                                              • 0
                                                где положительный герой?
                                                • –3
                                                  Битрикс такой особенный, что ему нужен сферический хостинг в вакууме %)
                                                  а лучше выделенный сервер сразу
                                                  • +4
                                                    Вы не прочитали статью.

                                                    Битриксу нужен просто нормальный хостинг. И он — в отличие от других систем — имеет удобные средства диагностики, которые позволяют сразу оценить все нужные параметры.
                                                  • 0
                                                    мне кажется, вы пишете странное, применительно к shared-хостингу:
                                                    «начиная с запуска персональных копий веб-сервера (например, тот же Apache) для разных пользователей, заканчивая использованием FastCGI через php-fpm»

                                                    берём захудалый сервер со 100 пользователями, каждому выдаём по два личных PHP-процесса через php-fpm (что в продакшн работать нормально разумеется не будет, но пусть мы считаем по минимуму), memory_limit пусть будет 32 mb (тоже возьмём по минимуму): итого только под php в минимальном окружении нужно более 6 гб памяти. Приближаемся к минимально рабочим реалиям — даём 4 воркера и 64 мб memory_limit — внезапно нужно уже более 25 гигов на 100 юзеров. это фантастика, мне кажется.
                                                  • +1
                                                    знаю как минимум 2 хостинга, где apache запускается под правами пользователя, mod_php, eAccelerator…
                                                    и там не требуется 25 гигов на 100 юзеров.
                                                    • 0
                                                      так не бывает =)
                                                      либо вы даёте N постоянных процессов на юзера, каждый из которых ест M памяти, либо не даёте.
                                                      минимально рабочий конфиг (4 потока на сайт и 64 Mb memory_limit) потребляет минимум 256 мегов на сайт.
                                                      • 0
                                                        я не говорю, что нужно постоянно держать запущенными все пользовательские apache, ведь в реальности к некоторым сайтам обращаются всего-лишь несколько раз за день.
                                                        «Из коробки» такое решение сходу не запустить, наверное, и действительно потребуется столько ресурсов, сколько вы описали. Но никто же не запрещает реализовывать свои прослойки для apache, которые эту активность мониторят, предсказывают и принимают решения о выделении ресурсов.
                                                        • 0
                                                          вы рассуждаете о сферическом коне. в настоящее время нет ни одного решения, позволяющего реализовать подобное.
                                                          в то, что где-то в секретных застенках никому неизвестного хостинга сидят люди, способные написать свой MPM для Apache, я верить отказываюсь.

                                                          я кстати не сомневаюсь, что вы видели хостинги, где apache работает под пользователем, ибо знаю что это реализовано у некоторых через MPM-ITK, но сей воркер к статье отношения не имеет, там почти тот же overhead, что и в CGI-режиме.
                                                          • +1
                                                            Вы спорите с человеком, который работал именно в таком хостинге, где это было реализовано на практике. ;))

                                                            Если Вы чего-то не видели, это не значит, что этого не бывает.
                                                            • 0
                                                              я собственно и пытаюсь найти таких людей, ибо схема слишком вкусная, хочется применить у себя =)
                                                              опишете вкратце, но поподробнее абстрактных слов?
                                                              • 0
                                                                если честно, то мне этика не позволяет дать больше деталей, т.к. я там больше не работаю. если здесь есть сотрудники Зенона и они посчитают допустимым рассказать больше, то надеюсь, они Вам помогут
                                                                • 0
                                                                  возможно =)
                                                                  но я всё равно не могу себе этого представить даже в самой общей теории, к сожалению. гасить пользовательские apache совсем — это нужно интегрироваться в матрицу, чтобы предстказывать, когда к какому сайту кто-то обратится =)
                                                                  а если не гасить основной процесс, только не нужных в данный момент детей, то во-первых мы приближаемся по оверхеду к CGI (если сайты посещаемые, а не «раз в сутки два захода»), а во-вторых, для 1000 сайтов на сервер чисто родительские процессы apache отожрут 64 гига =)
                                                                • 0
                                                                  Я посмотрел профили — а разве Вы с mephist сейчас не в одной компании работаете? :)
                                                                  • 0
                                                                    пожалуй, что нет =)
                                                              • 0
                                                                значит мне посчастливилось поработать в секретном хостинге с застенками, в котором разрабатывались свои кастомные решения.
                                                                • 0
                                                                  подробностей вы не знаете?
                                                                  мне просто кажется, что у вас случай сильно специфический, и на более общий не спроецируется…
                                                        • +2
                                                          16-32 (и более) Гб RAM на серверах хостинга — это реальность. Ну, конечно, у хороших хостеров.

                                                          Память постепенно перестает быть ограничивающим фактором для роста.

                                                          Вместе с разными доп. инструментами (рестарт неактивных процессов; расчет на то, что не все пользователи потребляют максимум ресурсов и т.п.) — все перестает казаться фантастикой, а становится вполне работающей схемой.
                                                          • 0
                                                            в prefork нет пространства для маневра, либо вы даёте N постоянных процессов на юзера, каждый из которых ест M памяти, либо не даёте.
                                                            минимально рабочий конфиг (4 потока на сайт и 64 Mb memory_limit) потребляет минимум 256 мегов на сайт.
                                                          • 0
                                                            Попробовать что ли новенький битрикс у себя… если вы не отказались от идиотизма overload что-то там в php.ini, то наверное даже смысл имеет. У меня +- всё соответствует.
                                                            • +2
                                                              Фил, не отказались…

                                                              Исторически — очень много инсталляций в 1251. Поэтому приходится поддерживать и 1251, и utf-8.

                                                              mbstring.func_overload нужно только во втором случае.

                                                              Универсальные решения (кастомные функции, использующие в зависимости от конфигурации мультибайтовые или обычные функции) работают медленнее.
                                                              • 0
                                                                Почему в какой-то версии просто не отказаться от первых? Ты понимаешь да, что чтобы я сейчас сделал кастомную настройку с инструкциями для идиотов, которым ещё и не по умолчанию это будет, мне нужна достаточно веская мотивация. А если человек хочет два сайта разместить, и второй у него факапится этим оверлоадом, то мне ещё ему и объяснять, что придётся брать ещё один тариф. И большинству остальных хостеров эта мотивация нужна тоже. В итоге у меня куча UMI, которые умудрились даже на php5.3 заработать, хотя у них написано что не работают, и вообще ни одного битрикса. В умолчание я это естественно ставить не буду — я ещё не сошёл с ума. Держать Битрикс-тариф… на это тоже нужна хорошая мотивация. Мне нужна статистика по ресурсам, её нет и быть не может у меня. А гугленее говорит что-то такое страшное, что я даже опасаюсь. Проблеме столько лет сколько у меня хостинг существует. Я раз в год об этом кого-нибудь пинаю, а вы всё ещё млин в cp1251 живёте. Сделайте две сборки — ну ё-моё (собственно, мне например чтобы это убрать придётся сделать две конфигурации с возможностью выбора — то на то).

                                                                Чуешь да, основные вопросы «с той стороны»?
                                                                • +2
                                                                  Я тебя прекрасно понимаю. Самому не нравится вариант с этим оверлоадом…

                                                                  Но, блин… «Отказаться». Пробовал на хостинге отказаться от старого PHP? От старого MySQL? Их тянут из проекта в проект. Еще и новые на них делают.

                                                                  Вот и у нас примерно так же получается. Иногда явное требование в ТЗ — 1251. Вот и поддерживаем.

                                                                  «Две сборки» — звучит просто.

                                                                  Но на практике это — 20 дистрибутивов (8 редакций — «Управление сайтом», 4 — «Корпоративный портал», 8 — разные отраслевые решения).

                                                                  Делать 40?
                                                                  • 0
                                                                    Да, у меня никогда не было php4 и наверное с Нового Года я перестану ставить на сервера php5.2. У меня с самого начала кодировки UTF-8 по-умолчанию и… MySQL-5.5 :) У меня везде MySQL-5.5. Да, есть проблемы «что-то у нас..» но я не тяну бремя совместимости.
                                                                    Сделайте над собой усилие. СP1251 не существует в массовом продакшене с 1996 года, когда Win´95 OSR2 перешла на внутренний Unicode. 15 лет! Тут части хабрахабравцев тогда пуповину перерезали… ТЗ млин… Есть хорошая фраза «CP1251 не хочешь ты».
                                                                    «Две сборки» я привёл только для примера. Мне вот тоже придётся делать кучу сборок конфигураций. Это тоже будет не цифра 2. Это пример того, что надо просто от чего-то отказаться во имя.
                                                                    • +1
                                                                      к сожалению, очень многие все еще разрабатывают в 1251. И очень много production сайтов сделано в 1251.

                                                                      У себя мы, например, 3 года назад принудительно перешли на разработку в UTF-8. И счастливы.
                                                                      • 0
                                                                        Да пусть разрабатывают. Нет проблемы. Зачем млин у себя-то этот рудимент держать? Я в смысле у конкретной разработки? Вон, взяли бы в версии битрикса 8.0 и перешли бы строго на UTF-8, даже такие противники CMS в общем и Битрикса в частности — ну был бы у меня ещё и Битрикс. А так — нет. И не потому что я считаю его… бякой, а потому что я ля этой бяки должен противоестественные телодвижения делать из-за причин мне неясных — сами они намного меньшие телодвижения сделать не хотят.
                                                                        • +1
                                                                          Это сложно сделать, так как есть крупные проекты изначально сделанные в других кодировках. Как правило перевод этих проектов на utf8 не тривиальная задача и не всегда владельцы проектов готовы платить за него. Особенно если этот перевод ничего не дает проекту в плане функционала (на проекте используется только один язык).
                                                                          • 0
                                                                            Ну так и сиди на предревних версиях. Совместимость даже ретроградная венда за собой не тянет. А тут второе десятилетие XI века и Битрикс в новейших версиях тянет за собой неисправимую в общем случае галочку.
                                                            • 0
                                                              Почему много сборок конфигураций?
                                                              как пример — по умолчанию включен overload, а кому не надо отключает в .htaccess
                                                              • +2
                                                                Через .htaccess в PHP 5.3 не переключается.
                                                                • 0
                                                                  Да упустил из виду.
                                                                  Данный параметр проставлять в настройках виртуального хоста apache параметром php_admin_value mbstring.func_overload 0, что мне кажется в принципе приемлемым решением.
                                                                  • 0
                                                                    Кто его туда на массхостинге вставлять будет?
                                                                    • 0
                                                                      Вынести в отдельный пункт настройки хостинга и у тех клиентов кому это надо автоматически проставлять. На мой взгляд не сложно.
                                                                      • 0
                                                                        А зачем? Есть баланс между писанием целой системы управления с проверками и не делания идиотских настроек в изначальной программе.
                                                                        • 0
                                                                          А потом, это я со своей панелькой. А те кто покупными пользуется (подавляющее большинство)? Я с таким же успехом считаю что легче это из CMS выпилить.
                                                                    • 0
                                                                      В 5.2 тоже
                                                                      • 0
                                                                        О! Вы на php5.3 «заводитесь»? Ну хоть и то слава Богу. Надеюсь на MySQL 5.5 тоже?
                                                                        • +2
                                                                          Да Битрикс работает на php 5.3 и MySQL 5.5
                                                                  • 0
                                                                    Господа, а почему бы вам свой эталонный хостинг не открыть?
                                                                    • 0
                                                                      у Битрикса немного другой бизнес.
                                                                      • +3
                                                                        Открыть свой хостинг с нуля — для этого потребуется достаточно много усилий (в том случае, если мы хотим сделать по-настоящему хороший хостинг — надежный, устойчивый, с хорошим суппортом и т.д.)

                                                                        Окупится такое новое направление очень и очень не скоро. При этом «оттянет» на себя часть имеющихся ресурсов. То есть, мы «недовложим» там, где могли бы.

                                                                        Поэтому лучше дружить со своими партнерами — хостинг-провайдерами (а не конкурировать с ними). И каждый при этом будет делать хорошо именно то, что умеет делать.
                                                                      • 0
                                                                        Добавлю свои 5 копеек. Работал я лет 10 назад в компании, в т.ч. предоставлявшей услуги хостинга. И был у нас клиент с сайтом на Битриксе, который очень переживал за скорость работы и безопасность своего сайта.

                                                                        По просьбе клиента я связывался тогда с Битриксом, с вопросом, мол, как же оптимально настроить сервер под ваше ядро. В ответ получил — «это должен знать ваш хостер». На мое уточнение, что я и есть представитель хостера, ответы мне дали лишь одно, а именно впечатление, что никто на тот момент в Битриксе не знал ответа на этот скаральный вопрос.

                                                                        С тех пор, насколько могу судить, ситуация улучшилась, и за это спасибо! И хотя никто мне так и не объяснил (да что мне — форумы на сайте Битрикса ломятся от таких вопросов), как менее мощная машина вдруг выбивает больше «битриксопопугаев» в тесте на производительность, чем куда более мощный и навороченный сервер с той же (вроде бы) ОС, уже одно существование скрипта bitrix_env, как минимум, скрашивает жизнь.

                                                                        Так что из хостингов сейчас я выберу такой, который special for bitrix, потому что — попугаи будут больше! :)
                                                                        • НЛО прилетело и опубликовало эту надпись здесь

                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                          Самое читаемое