Ресурсов чего? :)
У большинства хостингов ограничения ресурсов очень похожи. Даже в нюансах, указанных в договоре, а не только в описаниях на сайте :)
Если докапываться - да, у Бегет "надуманное" ограничение на количество доменов, но запихивать на одну учетку несколько ресурсов с нормальной посещаемостью - идея в любом случае так себе :)
Я не говорю что это так, но возможно, всего лишь возможно, что Ваш сайт падал по вполне объективным причинам не связанным с хостингом :) Просто где-то в коде что-то было не так :) Из моей практики, проблемы с "падениями" из-за стабильности провайдеров имели место быть лет пять назад. В данный момент, из всех тестируемых хостингов, все не очень здорово только у FirstVDS, но виртуальный хостинг для них не профильный и они закрыли услугу на доработку. Все остальные провайдеры работают стабильно.
Да, я понимаю что падения сайтов расстраивают, но возможно стоит не "рубить с плеча", а чуть более подробно разобраться в чем причина? :)
Проверил альтернативный сервер Бегет - показатели не сильно отличаются :)
Данные собраны всего за 12 часов, поэтому погрешность высокая.
Средние значения за более длительное время дадут более адекватные результаты, но это не критично т.к. цель - выявить существенные различия показателей.
Вот сравнение результатов, первыми значения альтернативного сервера, в скобках - данные сервиса:
Скорость чтения диска 1229 (998) - альтернативный быстрее.
Скорость записи диска 158 (285) - альтернативный медленнее.
БД чтение 218 (256) - практически идентичны.
БД запись 21 (38) - альтернативный медленнее.
Задержка ответа 20 (24) - практически идентичны.
PHP вычислительный тест 88 (102) - практически идентичны.
БД вычислительный тест 282 (349) - альтернативный быстрее.
WordPress - 225 (115)
Joomla - 147 (51)
Drupal 7 - 27 (30)
Drupal 8 - 63 (63)
Yii2 - 7 (9)
Laravel - 25 (26)
Да, у WordPress и Joomla разница существенная, но не на столько, как в Вашем примере. Предположительно связано это с тем, что сателлиты используют средние значения, сглаживающие минимальные и максимальные результаты. У всех остальных CMS показатели практически абсолютно идентичны и если честно, я не знаю как объяснить такое поведение у WordPress и Joomla :)
Нашел несколько хороших статей про задержки первых запросов. Причинами в них указываются создание новых процессов apache, компиляция скрипта и инициализация подключения к БД. Есть идея - написать синтетические тесты с узко специализированной нагрузкой и проверить кто из них будет "залипать" при первом обращении. Быстро не обещаю, но самому любопытно :)
Не получается нифига :(
Могу выставить значение realpath_cache_ttl у IHC (есть доступный php.ini в корне) и Beget (добавление директив в настройках), но они не показательные для проверки т.к. значения одни из лучших. У IHC было выставлено 4000 что и так превосходит время итерации тестов cms, поставил 86400 (сутки). У Бегет было 120, выставил 86400.
Мастерхост говорит что готов "подцепить" php.ini из корня сайта, но "чуда" не происходит.
php_value в .htaccess не работает предположительно в виду того что директива промаркирована как PHP_INI_SYSTEM.
suPHP_ConfigPath так же безуспешно.
Пробовал уже на SpaceWeb, Sprinthost и Джино.
Переключать php на cgi думаю не правильно т.к. не получится сохранить "чистоту" эксперимента. Умные дяди на форумах пишут что производительность может пострадать.
Какие есть еще варианты? :)
Мастерхост - партнерки нет
Руцентр - партнерки нет
SpaceWeb - партнерка через промо код, читайте никто его вводить не будет :)
Джино - подарки, которые мне не нужны и вряд ли я буду её подключать :)
Да даже если бы у всех провайдеров была партнерская/реферальная программа, в чем проблема то? :)
Если Вы переживаете, что все только ради денег, не расстраивайтесь это не так :)
Да, практически любому проекту нужна поддержка, в том числе и финансовая, иначе он "заглохнет".
Как мне кажется, я выбрал наименее навязчивый способ монетизации и если честно - ничего плохого в этом не вижу.
Я не стараюсь кого-то специально обманывать и по секрету скажу, проект еще даже не самоокупился при сравнительно не высоких затратах :)
Вы, конечно, можете считать меня злодеем, но пока я обманываю только себя :)
Если бы я работал по найму, все время потраченное на сервис, заработал бы существенно больше :)
Касательно Бегет - да, я симпатизирую этому провайдеру. Это даже из субъективных описаний на сайте видно :)
Причина - стабильность, нет акцентирования на маркетинге, ssh консоль в панели управления, memcached, redis, мультиаккаунты, прозрачный мониторинг используемых ресурсов, лояльное отношение к превышению лимитов. Иногда не хватает удобного онлайн редактора кода, но мне это не так критично т.к. сижу в ide.
А еще я симпатизирую Мастерхост, IHC и SpaceWeb. Да у Мастерхост очень странная панель управления, у IHC "ругаются" на превышение лимитов, а SpaceWeb не всегда интуитивно понятен, но все это мелочи. Как разработчик, я готов с ними работать и рекомендовать знакомым/клиентам. С моей скромной точки зрения, это хостинги у которых не возникает "странных" проблем, они адекватно реализованы технически и не надо "плясать с бубном" залив ресурс на сервер.
TimeWeb - в некоторых аспектах превосходит почти все хостинги, но "поплясать с бубном" возможно придется и меня отталкивает агрессивный маркетинг. Исключая маркетинг - очень толковый провайдер.
О негативном постараюсь обезличено. К сожалению многие хостинг провайдеры используют свои страницы ошибок 403 и 404 иногда даже с видео рекламой. Как мне кажется, это за гранью добра и зла. При этом некоторые "спиливают" установленные права доступа на вложенные папки при загрузке, что вызывает дополнительное появление тех самых 403 и 404 если не отследить.
НО! Не смотря на все мои симпатии и антипатии, алгоритм подсчета рейтинга работает автоматизированно. Как именно он считает - написано прямо на странице. Да, алгоритм составлял я, но не из личных предпочтений, а задавая seo friendly факторы. Основной фактор - отказоустойчивость, следующий по влиянию - задержка ответа сервера и загрузка cms и только потом "пузомерки". Я готов обсуждать сам алгоритм и даже менять его, при логичной аргументации :) Но объективно, он в любом случае будет очень приблизительным.
Мне кажется, что специалисты будут делать индивидуальные выводы из графиков производительности и проверять собственными тестами :)---------- Добавлено 04.01.2018 в 16:46 ----------
Ок! Сейчас сделаю!
realpath_cache - на сколько я понимаю отвечает за сохранение путей к скриптам. Попробую посмотреть в нем ли дело, но "на вскидку" не очень похоже... У некоторых cms есть механизмы кеширования непосредственно в файловую систему и работают они обычно быстрее (на много) чем кеширование в базу данных. С файловой системой особых проблем не замечал. Пробовал гонять синтетические тесты на множественный include, никаких падений производительности не было. Да и даже с БД не возникает таких "залипаний", как в ситуации с первым запуском.
Я предполагал что проблема может быть вызвана компиляцией скрипта. У Android, до определенной версии, в отличии от яблок использовалась компиляция при выполнении, а не при установке. Это вызывало существенную потерю производительности/батареи. Google даже внедрил "волшебный" оптимизатор, цепляющий наиболее часто используемые куски кода и переводящий их в native, но как работала эта "приблуда" лучше не вспоминать :)
Если получится найти способ избегать задержек первого запуска - поменяю алгоритм рейтинга т.к. фактор станет не на столько существенным!
Про перезагрузки - в последние три месяца их не было :) Изначально каждый сателлит диагностировал себя сам. Плановые отключения действительно не так важны, основная цель - отслеживание процента успешно обработанных запросов. Но, к сожалению, механизм получился очень не стабильным и не давал адекватных результатов. Пришлось оперативно перенести "прозвон" на основной сервис и мне самому это не нравится, но решение временное! Постараюсь не затягивать и реализовать нормальную архитектуру в ближайшее время!
Здравствуйте, спасибо! :)
Идея "родилась" в рабочем процессе :)
Какое-то время назад наше законотворчество запретило хранить персональные данные на иностранных серверах. В связи с этим многие знакомые/клиенты просили меня найти им новый хостинг. В данном вопросе выбор всегда сложный и не однозначный. Когда появилось свободное время, решил собрать сервис. Пока это своеобразное хобби, мне нравятся графики, диагностика и вот это вот все :) Если ресурс будет востребованным думаю привлеку к работе еще несколько знакомых, толковых разработчиков из хорошей команды, но об этом пока рано :)
Да, данные не являются "абсолютно" точными. Всегда есть погрешность и вероятность ошибки. Но исходя из собственного опыта - при выборе хостинг провайдера хочется "опереться" хоть на что-то.
Сателлиты сохраняют данные с точностью до часа. На графиках видны суточные колебания и не постоянные отклонения показателей. Если средних значений для аналитики не хватает, можно копнуть и глубже :)
Я не измеряю аптайм :)
И нет, отказоустойчивость Бегет не 100% :)
Все хостинги "теряют" какой-то небольшой процент запросов. Даже если просто пытаться открыть параллельный скрипт через http. Да, если Бегет "ляжет" он сам это отследить не сможет, но он не ложится, как и Мастерхост :) Я уже думал перенести "прозвон" куда-то на linode (например), но пока это не самая большая проблема :)
Загрузка cms точно не связана с "основным сайтом" т.к. все сателлиты постоянно "прогреваются". Обращения к сайтам на всех хостингах идут раз в минуту по cron. Но мысль я понял - проверю альтернативный сервер Бегет :)
Есть предложение - обсудить откуда вообще берется эта "задержка" после простоя и как её можно избежать :)
Думаю многим, как и мне, с пользовательской точки зрения это будет гораздо интереснее.
Действительно ли она связана с кешем apache и значит ли это что избежать неприятных ситуаций получится только используя VDS/VPS с отдельным контейнером и "своим" веб сервером? Является ли архитектура shared hosting не seo friendly по умолчанию или что-то можно сделать?---------- Добавлено 03.01.2018 в 15:51 ----------
Звучит довольно грустно :(
Нет, не то что мой сервис будет не нужен, а тот факт что хостинг провайдер не будет обновлять железо для старых клиентов.
Это как-то не правильно, не считаете?..
Тут скорее в обратном порядке логика, сервис висит на Beget т.к. по его мнению это самый толковый хостинг :)
Если появится более качественный, перенести ресурс не сложно :)
Мне не нравится то, как на многих хостингах обрабатывается первый запрос после определенного периода. Предполагаю что это связано с кешированием apache и вот тут https://hosting-pulse.ru/cms видно что для простой загрузки ядра многим хостингам нужно очень много времени после простоя. С одной стороны, это не так "страшно" для ресурса с хорошей посещаемостью, с точки зрения пользователя. Но с другой, при индексации поисковиком нет никаких гарантий что он получит "разогретую" страницу. Скорость загрузки сайта - один из факторов ранжирования и выглядеть в глазах поисковой системы "тормознутым" совсем не хочется.
Бегет, кстати и занимает лидирующие позиции т.к. при подсчете рейтинга учитываются тесты cms вместе с задержкой ответа сервера.
Касательно синтетики, я сам не люблю "узколобые" тесты, но для типизированных параметров они подходят. Тем не менее, как минимум два показателя - задержка ответа сервера и время загрузки ядра cms позволяют оценить не только "сферическую производительность в вакууме", но и то как сервер справляется с комплексными потребительскими задачами. При этом в рейтинге им уделяется большее внимание, чем обычным "пузомеркам". Не так важно, на сколько быстрые диски, если сервер "залипает" на пол секунды при каждом запросе или по несколько секунд загружает "холодную" страницу.
Я действительно старался сделать рейтинг полезным для пользователей, а не абстрактным benchmark.
Фактически он старается показать на сколько хостинг SEO friendly.
Про больше - понял, постараюсь! Спасибо!
Спасибо, буду работать!
Посмотрел ihor - действительно очень гуманный ценник. Заявленных ресурсов даже в тарифе "эконом" должно хватать для сайта со "средней" посещаемостью. Добавлю его в список кандидатов на тестирование!
Большое спасибо за добрые слова! :)
