Comments 81
UFO just landed and posted this here
OpenId нужен только для комментирования. Для добавления теста OpenId не нужен
UFO just landed and posted this here
пускай учатся OpenId юзатьзачем?
затем, что это очень кошерная штука.
по ссылке на архив со скриптом — 404
а можно конкретный URL? Видимо, ссылка битая.
хм, странно, у меня качается. может хабраэффект? %)
странно. Залейте чтоль на какой-нибудь rghost
Хреновенький тогда у вас хостинг провайдер… Сам проверял раз. Хаброэффект это фикция. Если площадка настроена корректно, то не наступает он. Добавляет лишь максимум 1-1.5 к просмотров. Это копейки.
за 5-10 минут для некоторых эти 1-1.5 к пользователей может быть критическим.
Скачать архив, распаковать на своём хостинге, настроить данные для теста (пароли для MySQL) и нажать кнопку. После теста будет кнопка добавить тест в базу.
Качество результата зависит не только от времени суток…
а еще, например, от заполненности сервера (сколько клиентов на нем уже сидит)
А уж про то что у одного хостера обычно куда более чем 1 сервер… и обычно разных совсем по установленному в них железу.
Может стоило бы это как-то учитывалось, хотя бы на уровне указания процессора, памяти, какойто характеристики дисковой подсистемы… имя самого сервера в рамках одного хостера
Так что даже на пустом сервере core2duo 2.4 покажет совсем не то, что пара quad xeon-ов. Да и аппаратный рейд контроллер просто творит чудеса для простых тестов дисковой подсистемы…
а еще, например, от заполненности сервера (сколько клиентов на нем уже сидит)
А уж про то что у одного хостера обычно куда более чем 1 сервер… и обычно разных совсем по установленному в них железу.
Может стоило бы это как-то учитывалось, хотя бы на уровне указания процессора, памяти, какойто характеристики дисковой подсистемы… имя самого сервера в рамках одного хостера
Так что даже на пустом сервере core2duo 2.4 покажет совсем не то, что пара quad xeon-ов. Да и аппаратный рейд контроллер просто творит чудеса для простых тестов дисковой подсистемы…
Совершенно верно! Но большинство тестирущих не знает о своей площадке ничего, единственное — известен тариф. В этой ситуации приходится усреднять данные по тарифу хостера. Получается этакая «средняя температура по больнице». Понимаю, что не очень, но это лучше чем отсутствие данных.
А при наличии большой статистики тестов надеюсь на более справедливые цифры.
А при наличии большой статистики тестов надеюсь на более справедливые цифры.
сразу извиняюсь, что отвечаю не сразу, ибо сначала спрашиваю у автора проекта. ну, может накопим ему на инвайт ещё :)
Интересно, потестим. Только вот дизайн сайта не очень современный, но я думаю что со временем автор исправится.
Как надоело, когда люди, ничего не понимающие в хостинге, пытаются оценивать работу людей, что-то понимающих в хостинге. Ну, давайте по пунктам:
>Хостер
>Тарифный план
>URL тестируемого сайта
Как уже говорилось выше, у хостера может быть несколько серверов и ситуация по ним может отличаться самым кардинальным образом. Тут полезнее было бы смотреть хостнейм сервера и показывать результаты по нему. Еще, я знаю только 3 хостера в России, у которых выдаваемые ресурсы действительно зависят от тарифного плана.
>Версия PHP
Это может быть полезно только из любопытства.
>Дата теста
Это уже полезнее, позволяет оценить нагрузку как в пики, так и в спокойное время. Другой вопрос, что усереднять значения нельзя — потому что пользователь не будет рад, когда Ваша проверка скажет, что сервер нагружен на 50% своих возможностей, ночью его сайт будет летать, а днем он не будет грузиться из-за тормозов.
>CPU: миллион синусов
>CPU: млн слияний строк через точку
>CPU: млн слияний строк в кавычках
>CPU: млн слияний строк через массив
Просто шедевр. Ни один хостинг-сервер не оптимизирован на выполнение долгих операций. В основном они настраиваются на то, чтобы быстро отрабатывали быстрые генерации страниц, а долгие фоновые процессы выполнялись долго. Или Вы просто хотите узнать, заселен сервер другими сайтами, или нет?
>MySQL: соединение/разъединение
Будет показывать результаты совсем не в пользу удаленного MySQL-сервера. А я бы сказал, что удаленный сервер — это плюс, а не минус.
>MySQL: benchmark (млн. синусов )
Еще один шедевр.
>MySQL: 10000 вставок строк
>MySQL: 10000 select и fetch
Скорее всего, эти данные попадут в кэш MySQL и будут доставаться уже оттуда, что выдаст завышенные результаты.
>Версия MySQL
Тоже любопытство.
>Время работы сервера
Не понятно, маленький аптайм — это плохо? Или хорошо? Если плохо — то как быть с апдейтами багфиксов/безопасности?
>Выдача байт в секунду в среднем
>Соединений в секунду в среднем
>Запросов SELECT в секунду в среднем
Тоже играет против удаленного MySQL-сервера на несколько web-серверов. Так же сервер с тысячей SELECT Str FROM Tbl WHERE Id=1000 будет нагружен меньше, чем сервер с какими-то 10 запросами с сортироками, join'ами и прочим в каком-нибудь кривом скрипте.
>FS: Запись в файл
>FS: Чтение из файла
Тоже веселая оценка. Она говорит нам практически обо всем, кроме производительности дисковой системы.
Увы, я не уверен в наличии буферизации файловых операций в php, но в случае, если оно есть — то результат теста будет очень сильно зависеть от его размера, а если его нет — то результат теста будет показывать, сколько времени процессор делает переключение контекста для выполнения сисколла, читающего один байт, чем производительность ФС. А если еще вспомнить о существовании кеша у ОС…
Итог:
Зачем эти синтетические тесты, которые пытаются необъективно оценить какие-то цифры у сервера? Сделайте пять дистрибутивов наиболее популярных опенсорс-cms, наполните их достаточным количеством шаблонных данных, напустите на сайт нагрузку, подобную приходящим туда людям, разнесите ее на сутки по времени, замерьте минимальное, максимальное и среднее время обработки для каждой страницы, выкиньте 10% самых медленных страниц, 10% самых быстрых, по остальному посчитайте среднее значение для каждого часа, проанализируйте получившуюся функцию, сравните с другими результатами. Получите тестирование хостера, показывающее то, что должно показывать тестирование хостера — как на нем работают сайты, а не за сколько он считает миллион синусов.
>Хостер
>Тарифный план
>URL тестируемого сайта
Как уже говорилось выше, у хостера может быть несколько серверов и ситуация по ним может отличаться самым кардинальным образом. Тут полезнее было бы смотреть хостнейм сервера и показывать результаты по нему. Еще, я знаю только 3 хостера в России, у которых выдаваемые ресурсы действительно зависят от тарифного плана.
>Версия PHP
Это может быть полезно только из любопытства.
>Дата теста
Это уже полезнее, позволяет оценить нагрузку как в пики, так и в спокойное время. Другой вопрос, что усереднять значения нельзя — потому что пользователь не будет рад, когда Ваша проверка скажет, что сервер нагружен на 50% своих возможностей, ночью его сайт будет летать, а днем он не будет грузиться из-за тормозов.
>CPU: миллион синусов
>CPU: млн слияний строк через точку
>CPU: млн слияний строк в кавычках
>CPU: млн слияний строк через массив
Просто шедевр. Ни один хостинг-сервер не оптимизирован на выполнение долгих операций. В основном они настраиваются на то, чтобы быстро отрабатывали быстрые генерации страниц, а долгие фоновые процессы выполнялись долго. Или Вы просто хотите узнать, заселен сервер другими сайтами, или нет?
>MySQL: соединение/разъединение
Будет показывать результаты совсем не в пользу удаленного MySQL-сервера. А я бы сказал, что удаленный сервер — это плюс, а не минус.
>MySQL: benchmark (млн. синусов )
Еще один шедевр.
>MySQL: 10000 вставок строк
>MySQL: 10000 select и fetch
Скорее всего, эти данные попадут в кэш MySQL и будут доставаться уже оттуда, что выдаст завышенные результаты.
>Версия MySQL
Тоже любопытство.
>Время работы сервера
Не понятно, маленький аптайм — это плохо? Или хорошо? Если плохо — то как быть с апдейтами багфиксов/безопасности?
>Выдача байт в секунду в среднем
>Соединений в секунду в среднем
>Запросов SELECT в секунду в среднем
Тоже играет против удаленного MySQL-сервера на несколько web-серверов. Так же сервер с тысячей SELECT Str FROM Tbl WHERE Id=1000 будет нагружен меньше, чем сервер с какими-то 10 запросами с сортироками, join'ами и прочим в каком-нибудь кривом скрипте.
>FS: Запись в файл
>FS: Чтение из файла
Тоже веселая оценка. Она говорит нам практически обо всем, кроме производительности дисковой системы.
Увы, я не уверен в наличии буферизации файловых операций в php, но в случае, если оно есть — то результат теста будет очень сильно зависеть от его размера, а если его нет — то результат теста будет показывать, сколько времени процессор делает переключение контекста для выполнения сисколла, читающего один байт, чем производительность ФС. А если еще вспомнить о существовании кеша у ОС…
Итог:
Зачем эти синтетические тесты, которые пытаются необъективно оценить какие-то цифры у сервера? Сделайте пять дистрибутивов наиболее популярных опенсорс-cms, наполните их достаточным количеством шаблонных данных, напустите на сайт нагрузку, подобную приходящим туда людям, разнесите ее на сутки по времени, замерьте минимальное, максимальное и среднее время обработки для каждой страницы, выкиньте 10% самых медленных страниц, 10% самых быстрых, по остальному посчитайте среднее значение для каждого часа, проанализируйте получившуюся функцию, сравните с другими результатами. Получите тестирование хостера, показывающее то, что должно показывать тестирование хостера — как на нем работают сайты, а не за сколько он считает миллион синусов.
UFO just landed and posted this here
Все тесты — средняя температура по всем больницам области…
Не зря компы тестят на реальных игрушках и пр. приложениях.
Логично тогда хостинг оценивать на реальных проектах.
Интересно всего два параметра: сколько часов в месяц сайт не отвечает и сколько времени идет генерация/отдача страниц. Бывают любители прикрутить кран, так что отдача страницы занимает в десятки раз больше времени, чем генерация.
Логично тогда хостинг оценивать на реальных проектах.
Интересно всего два параметра: сколько часов в месяц сайт не отвечает и сколько времени идет генерация/отдача страниц. Бывают любители прикрутить кран, так что отдача страницы занимает в десятки раз больше времени, чем генерация.
UFO just landed and posted this here
Тайминг урлов, естественно. Возможно, в развороте на сутки, в сочетании с количеством хитов. Это скорее не про хостинг знание, а про конкретный проект.
Если страницы генерятся «по 10 секунд» — Яндекс плохо кушает сайт. 30-40 тыс. страниц будут попадать в индекс вечность. Если по ночам сайт недоступен — опять большие проблемы с индексацией.
Можно дать интегральную оценку конкретному проекту. Но ее вычисление — процесс сугубо интимный.
Ну а так, один дурак с кривым скриптом всегда обесценит самый лучший хостинг.
Если страницы генерятся «по 10 секунд» — Яндекс плохо кушает сайт. 30-40 тыс. страниц будут попадать в индекс вечность. Если по ночам сайт недоступен — опять большие проблемы с индексацией.
Можно дать интегральную оценку конкретному проекту. Но ее вычисление — процесс сугубо интимный.
Ну а так, один дурак с кривым скриптом всегда обесценит самый лучший хостинг.
Попытаюсь ответить по порядку.
Для начала хочу отметить, что тест вытаскивает множество информации (например версия PHP, MySQL, аптайм)просто потому что эта информация может быть легко вытащена и имеет некую ненулевую ценность. Другими словами для кучи :) Эти данные не участвуют в ранжировании.
Кроме того есть показатели, которые интересны с точки зрения перенаселённости сервера сайтами. Например Количество MySQL соединений в секунду, количество запросов в секунду. Большие показатели должны вызывать интерес, хотя опять же как бы не был перенаселён сервер, если главное чтобы он работал шустро. Поэтому такие показатели записываются в базу, но не участвуют в ранжировании.
Главная тесты (тесты на время) по идее должны отобразить скорость работы платформы. Они участвуют в ранжировании, т.к. говорят о производительности площадки.
Я пока не буду наверное затрагивать все тесты. Пока скажу что этот тест есть некое олицетворение дистрибутива опенсорс-cms специально направленного на тестирование.
Не спорю набор тестов может быть не идеален. Согласен обсуждать любые рекомендации
Для начала хочу отметить, что тест вытаскивает множество информации (например версия PHP, MySQL, аптайм)просто потому что эта информация может быть легко вытащена и имеет некую ненулевую ценность. Другими словами для кучи :) Эти данные не участвуют в ранжировании.
Кроме того есть показатели, которые интересны с точки зрения перенаселённости сервера сайтами. Например Количество MySQL соединений в секунду, количество запросов в секунду. Большие показатели должны вызывать интерес, хотя опять же как бы не был перенаселён сервер, если главное чтобы он работал шустро. Поэтому такие показатели записываются в базу, но не участвуют в ранжировании.
Главная тесты (тесты на время) по идее должны отобразить скорость работы платформы. Они участвуют в ранжировании, т.к. говорят о производительности площадки.
Я пока не буду наверное затрагивать все тесты. Пока скажу что этот тест есть некое олицетворение дистрибутива опенсорс-cms специально направленного на тестирование.
Не спорю набор тестов может быть не идеален. Согласен обсуждать любые рекомендации
Вы все равно не поняли идею моего комментария, она заключалась в последних строках.
Тестировать хостинг надо не синтетическими тестами, а именно реальными сайтами. В комментарии я просто показал конкретно, по каким причинам каждый из синтетических тестов не будет показывать нужной картины.
Тестировать хостинг надо не синтетическими тестами, а именно реальными сайтами. В комментарии я просто показал конкретно, по каким причинам каждый из синтетических тестов не будет показывать нужной картины.
>Тестировать хостинг надо не синтетическими тестами, а именно реальными сайтами.
Всё зависит от конкретной задачи.
Если мы имеем реальный сайт и думаем, куда его пристроить, то вероятно так и нужно действовать. Правда при этом нужно будет опробовать кучу хостинг провайдеров и получить те же тесты но для конкретной CMS.
Здесь же поставлена задача сравнения различных хостинг провайдеров. Этот рейтинг может существенно сузить круг поиска для реального сайта, хотя конечно же не решает полностью всей задачи.
Пройдусь по конкретным тестам:
>CPU: миллион синусов и прочие
Даёт информацию о вычислительной мощности, которую хостинг может выдать данному процессу. Иногда она тормозит меньше иногда она больше. Факторов тут много тут и населённость сервера, и мощность оборудования. Но нужно ли пользователю знать причину тормозов? Причину нужно диагностировать хостеру. В этом случае такой тест конечно же бессилен и абсолютно ничего не скажет.
Всё зависит от конкретной задачи.
Если мы имеем реальный сайт и думаем, куда его пристроить, то вероятно так и нужно действовать. Правда при этом нужно будет опробовать кучу хостинг провайдеров и получить те же тесты но для конкретной CMS.
Здесь же поставлена задача сравнения различных хостинг провайдеров. Этот рейтинг может существенно сузить круг поиска для реального сайта, хотя конечно же не решает полностью всей задачи.
Пройдусь по конкретным тестам:
>CPU: миллион синусов и прочие
Даёт информацию о вычислительной мощности, которую хостинг может выдать данному процессу. Иногда она тормозит меньше иногда она больше. Факторов тут много тут и населённость сервера, и мощность оборудования. Но нужно ли пользователю знать причину тормозов? Причину нужно диагностировать хостеру. В этом случае такой тест конечно же бессилен и абсолютно ничего не скажет.
Мне кажется, что задача тестирования хостинга — поиск провайдера, у которого будет быстро и без падений работать сайт, а не быстро считаться миллион синусов.
Ну вот тест CPU — что он покажет? Он покажет, сколько астрономического времени будет выполняться тест, требующий 0.4 секунд процессорного времени подряд. Это может дать примерную оценку количества конкуррентных запросов за сервер а данный момент времени, используемого планировщика и его настроек. Но это не даст никакой информации о том, как эти процессорные секунды перейдут в астрономические при 10 запросах на сайт клиента и еще 50 на другие сайты на сервере.
Ну вот тест CPU — что он покажет? Он покажет, сколько астрономического времени будет выполняться тест, требующий 0.4 секунд процессорного времени подряд. Это может дать примерную оценку количества конкуррентных запросов за сервер а данный момент времени, используемого планировщика и его настроек. Но это не даст никакой информации о том, как эти процессорные секунды перейдут в астрономические при 10 запросах на сайт клиента и еще 50 на другие сайты на сервере.
Сорри. Сорвалось. Продолжаю.
>MySQL: benchmark (млн. синусов )
То же самое
>MySQL: 10000 вставок строк
>MySQL: 10000 select и fetch
Вставка не кешируется. Селект кешировался бы. Но в тесте выполняется не 10000 селектов, а 1 селект всех 10000 записей.
Вы поглядите в тест — там код открытый :)
>FS: Запись в файл
>FS: Чтение из файла
>Тоже веселая оценка. Она говорит нам практически обо всем, кроме производительности дисковой системы.
Работа с диском может быть устроена довольно сложно, там могут быть и RAID и кеши всяких уровней. И этот тест, конечно же, не скажет ничего о конкретном звене этой цепочки.
Но он даст довольно уверенную интегральную характеристику, которая будет доступна пользователю, и которую можно оценивать и сравнивать.
Мне кажется тут всё нормально.
PS: Хочу отметить, что эти тесты, как впрочем наверное любые тесты, неидеальны. Есть куча факторов, которые они учитывают не совсем точно, есть которые учитывают совсем неточно. А есть которые вообще не учитывают.
>MySQL: benchmark (млн. синусов )
То же самое
>MySQL: 10000 вставок строк
>MySQL: 10000 select и fetch
Вставка не кешируется. Селект кешировался бы. Но в тесте выполняется не 10000 селектов, а 1 селект всех 10000 записей.
Вы поглядите в тест — там код открытый :)
>FS: Запись в файл
>FS: Чтение из файла
>Тоже веселая оценка. Она говорит нам практически обо всем, кроме производительности дисковой системы.
Работа с диском может быть устроена довольно сложно, там могут быть и RAID и кеши всяких уровней. И этот тест, конечно же, не скажет ничего о конкретном звене этой цепочки.
Но он даст довольно уверенную интегральную характеристику, которая будет доступна пользователю, и которую можно оценивать и сравнивать.
Мне кажется тут всё нормально.
PS: Хочу отметить, что эти тесты, как впрочем наверное любые тесты, неидеальны. Есть куча факторов, которые они учитывают не совсем точно, есть которые учитывают совсем неточно. А есть которые вообще не учитывают.
Да, Вы все-таки не поняли :)
Вы говорите, что при тестировании мы сможем получить цифры, которые характеризуют каким-либо образом сервер провайдера. Я соглашаюсь с этим, но говорю, что эти цифры не нужны пользователю — они не несут информации о том, как будет хостинг работать для того, чтобы хостить сайт пользователя.
Ни один сайт никогда не будет в 1 поток долго проводить операции с памятью внутри себя. Вы тестируете это. Намного интереснее — тестировать 10-30 параллельных недолгих вычислений, которые по времени укладываются в генерацию средней страницы, так как это почти покажет реальную ситуацию при посещении сайта.
Ни один сайт никогда не будет часто делать select на 10000 элементов. Вы тестируете это. Намного интереснее — тестировать много параллельных запросов в MySQL с небольшими ответами, иногда перекрывающимися, иногда — нет, так как это покажет еще и качество настроек кеширования MySQL. Это тоже почти покажет реальную ситуацию при посещении сайта.
Ни один сайт (и не только сайт) никогда не будет читать побайтово 1 мегабайт данных из одного файла. Вы же тестируете это. Намного интереснее — делать большой файл и читать его большим куском, чтобы узнать среднюю скорость потокового чтения. А потом еще читать много маленьких файлов в случайном порядке, чтобы узнать среднюю скорость рандомного чтения. Это тоже почти покажет реальную ситуацию при посещении сайта.
Клиенту, на мой взгляд, не нужны непонятные цифры для сравнения некоторых пузомерок хостеров. Ему нужно сравнение того, как его сайт будет работать на этих хостерах.
Вы говорите, что при тестировании мы сможем получить цифры, которые характеризуют каким-либо образом сервер провайдера. Я соглашаюсь с этим, но говорю, что эти цифры не нужны пользователю — они не несут информации о том, как будет хостинг работать для того, чтобы хостить сайт пользователя.
Ни один сайт никогда не будет в 1 поток долго проводить операции с памятью внутри себя. Вы тестируете это. Намного интереснее — тестировать 10-30 параллельных недолгих вычислений, которые по времени укладываются в генерацию средней страницы, так как это почти покажет реальную ситуацию при посещении сайта.
Ни один сайт никогда не будет часто делать select на 10000 элементов. Вы тестируете это. Намного интереснее — тестировать много параллельных запросов в MySQL с небольшими ответами, иногда перекрывающимися, иногда — нет, так как это покажет еще и качество настроек кеширования MySQL. Это тоже почти покажет реальную ситуацию при посещении сайта.
Ни один сайт (и не только сайт) никогда не будет читать побайтово 1 мегабайт данных из одного файла. Вы же тестируете это. Намного интереснее — делать большой файл и читать его большим куском, чтобы узнать среднюю скорость потокового чтения. А потом еще читать много маленьких файлов в случайном порядке, чтобы узнать среднюю скорость рандомного чтения. Это тоже почти покажет реальную ситуацию при посещении сайта.
Клиенту, на мой взгляд, не нужны непонятные цифры для сравнения некоторых пузомерок хостеров. Ему нужно сравнение того, как его сайт будет работать на этих хостерах.
Просто я задался задачей написать простой скрипт на PHP, который мог бы запустить на своём хостинге любой вебмастер и по результатам этих тестов выполнять некое сопоставление.
Перечисленные Вами тесты и правда интересны и полезны, но насколько я знаю PHP не поддерживает многопоточность. Если такие тесты и реализовывать — это нужно делать совершенно другими средствами. И возможно простых прав вебмастера на виртуальном хостинге будет недостаточно.
С другой стороны уже реализованные тесты хоть и имеют ряд изъянов, всё же дают некую отправную точку. Я думаю что результат моих тестов неплохо коррелирует с реальной производительностью хостинга, хотя и возможны отклонения.
Перечисленные Вами тесты и правда интересны и полезны, но насколько я знаю PHP не поддерживает многопоточность. Если такие тесты и реализовывать — это нужно делать совершенно другими средствами. И возможно простых прав вебмастера на виртуальном хостинге будет недостаточно.
С другой стороны уже реализованные тесты хоть и имеют ряд изъянов, всё же дают некую отправную точку. Я думаю что результат моих тестов неплохо коррелирует с реальной производительностью хостинга, хотя и возможны отклонения.
> Еще, я знаю только 3 хостера в России, у которых выдаваемые ресурсы действительно зависят от тарифного плана.
Это какие?
Это какие?
1. DipHost тут вроде-бы писал, что у них количество детей Apache на пользователя зависит от ТП.
2. Монстры вроде MasterHost, РБК. Правда, по ним информации нет, это оценка по скорости работы сайтов. Возможно, они суют разные ТП на разные сервера, которые загружены по-разному — оттуда и получается разница.
2. Монстры вроде MasterHost, РБК. Правда, по ним информации нет, это оценка по скорости работы сайтов. Возможно, они суют разные ТП на разные сервера, которые загружены по-разному — оттуда и получается разница.
ИМХО есть смысл разделить тесты БД и РНР. С тем же мускулем можно работать не только из под РНР. И РНР, в свою очередь, может работать с другими СУБД.
Мне, как разработчику ASP.Net было бы интересно увидеть подобный набор тестов для связки ASP.Net+MSSQL — такое в принципе планируется?
Мне, как разработчику ASP.Net было бы интересно увидеть подобный набор тестов для связки ASP.Net+MSSQL — такое в принципе планируется?
hostertest.ru/tests/result/367 ну не плохо…
отличный по функциональности ресурс,
но предлагаю повесить вашего дизайнера, если он вообще есть.
но предлагаю повесить вашего дизайнера, если он вообще есть.
Если я правильно понимаю, то вы предлагаете добавлять тесты всем желающим?
Ок, я пишу короткий тест, который помимо прочего, ещё и аккуратно сливает мне информацию о MySQL соединении на мыло. Логин, пароль, всё ещё, до чего загребущие ручки дотянутся…
Как вы планируете обходить подобные узкие места? Рефакторинг каждого теста?
Ок, я пишу короткий тест, который помимо прочего, ещё и аккуратно сливает мне информацию о MySQL соединении на мыло. Логин, пароль, всё ещё, до чего загребущие ручки дотянутся…
Как вы планируете обходить подобные узкие места? Рефакторинг каждого теста?
hostertest.ru/tests/result/380 Хм… SunFire T1000 сейчас без нагрузки… Пилите дальше свой тест (в сторону многопоточности).
Действительно тестируется только железо сервера, а это можно узнать из cpuinfo. Как бы я сделал: поставил тестовый скрипт в виде какой-нибудь CMS вроде друпала — полностью настроенного, с тестовой базой данных, и зарегистрировал этот скрипт в host-tracker с минутным тестом в триальном режиме. Получилось бы 80 запросов в минуту. Логи хосттрекера содержат информацию о запросах из разных точек, способ выбора учитываемых точек можно обсуждать.
Почему host-tracker наверно понятно — не надо свою инфраструктуру для запуска тестов ставить. Но можно и поставить, конечно.
Почему host-tracker наверно понятно — не надо свою инфраструктуру для запуска тестов ставить. Но можно и поставить, конечно.
У Вас лишняя точка в линке: «ru./»
почитайте на досуге — ru.wikipedia.org/wiki/Корневой_домен
У вас опечатка в: «10 последник тестов:»
1. Попробовал ввести OpenID — получил — Ошибка аутентикации; указан неверный OpenID.
hostertest.ru/user/openidquery — тут
2. Справа блок «Поиск хостинг-провайдера», добав кнопку «Начать» или «Поиск» чтоли
3. Залогинился. Вышел на главную — меня выкинуло.
ну вроде что смог на первый взгляд нарыть…
ЗЫ: но для меня как для владельца сайта — я заходил проверить свой сайт на скорость (так я понял с твоего топика)… а на самом деле — выбираю твой тест, а он меня сразу цифрами ублажает… повторюсь — для меня…
hostertest.ru/user/openidquery — тут
2. Справа блок «Поиск хостинг-провайдера», добав кнопку «Начать» или «Поиск» чтоли
3. Залогинился. Вышел на главную — меня выкинуло.
ну вроде что смог на первый взгляд нарыть…
ЗЫ: но для меня как для владельца сайта — я заходил проверить свой сайт на скорость (так я понял с твоего топика)… а на самом деле — выбираю твой тест, а он меня сразу цифрами ублажает… повторюсь — для меня…
Не грузит процессор на и на 50% во время тестирования :-) Похоже у вас все однопоточное, и квады покажут такую же производительность что и одноядерники :-) Незачет :-)
сомнительный тест. в идеале нужно проводить тестирование в 5, 10, 50, 100 потоков (одновременных посетителей).
Боюсь, для многопоточного тестирования средств PHP не достаточно.
А других средств простому вебмастеру скорее всего не дадут.
А других средств простому вебмастеру скорее всего не дадут.
ab -n 1000 -c 10 site.ru/benchmark.php
Очень понравились результаты в виде паутинки.
Была бы очень кстати возможность удобно сравнивать результаты нескольких хостеров/тарифных планов
Была бы очень кстати возможность удобно сравнивать результаты нескольких хостеров/тарифных планов
Бред.
Описана ситуация — сравнить хлеб в ближайшем магазине за 20 рублей, и через дорогу такой же за 19,50.
В рамках 99% существующих на рынке CMS — железо 99% хостеров не имеет никакого значения для быстродействия сайта, а разница в стоимости тарифных планов — никакого значения для бизнеса.
А крупные проекты (и тяжелые CMS) никто в здравом уме на виртуалхостинге запускать не будет.
Описана ситуация — сравнить хлеб в ближайшем магазине за 20 рублей, и через дорогу такой же за 19,50.
В рамках 99% существующих на рынке CMS — железо 99% хостеров не имеет никакого значения для быстродействия сайта, а разница в стоимости тарифных планов — никакого значения для бизнеса.
А крупные проекты (и тяжелые CMS) никто в здравом уме на виртуалхостинге запускать не будет.
Если говорить о shared-хостинге — никто вам не разрешит сильно загружать сервер, поэтому если проект подразумевает большую нагрузку — нет смысла выбирать среди хостеров, нужно выбирать датацентр и арендовать там отдельный сервак — обычно это 70 — 400 баксов в месяц в зависимости от крутости датацентра и сервера. Ну или хотя бы VPS.
То есть сравнивать хостеров по этому критерию — всё равно что сравнивать машины для Москвы по, скажем, скорости — всё равно в городе вы не будете гонять на них, так зачем выбирать по этому критерию?
Для обычного хостинга куда важнее общая стабильность, uptime, хорошая техподдержка, а не крутость их серверов…
То есть сравнивать хостеров по этому критерию — всё равно что сравнивать машины для Москвы по, скажем, скорости — всё равно в городе вы не будете гонять на них, так зачем выбирать по этому критерию?
Для обычного хостинга куда важнее общая стабильность, uptime, хорошая техподдержка, а не крутость их серверов…
«Крутость сервера» — не самый маловажный показатель. История проекта как раз началась с того, что одного друга на одном хостинге бложик на WP при 20 униках ложил хостинг. У другого блог открывался по ощущениям в 3 раза медленнее чем у всех.
Проверили тестом, поменяли хостинг — теперь у всех всё путём.
Проверили тестом, поменяли хостинг — теперь у всех всё путём.
По-моему, стоит дать возможность отсекать старые результаты. По моему хостеру и ТП есть один результат годичной давности, который сильно отличается от сегодняшних замеров. Конечно, это может быть и из-за выходного дня. Но может быть и из-за того, что провайдер оборудование уже поменял.
А еще было бы здорово видеть рядом цены. Хочется понять, есть зависимость между быстродействием и стоимостью хостинга.
Я в хостинге не очень силен, но, кажется, тесты неадекватны с точностью до наоборот :)
Вот, например, миллион синусов — если на шаред-хостинге миллион синусов вычисляется быстро, значит, никаких квот процессорного времени для длительных процессов нет. Следовательно, если какой-нибудь умник загрузит своими скриптами процессор, то все его соседи лягут. Как мне — это плохой хостинг, а не хороший.
Вот, например, миллион синусов — если на шаред-хостинге миллион синусов вычисляется быстро, значит, никаких квот процессорного времени для длительных процессов нет. Следовательно, если какой-нибудь умник загрузит своими скриптами процессор, то все его соседи лягут. Как мне — это плохой хостинг, а не хороший.
тут уже говорили — интересно как хостинг отработает cms — там будет и несколько запросов в базу и файлы и какие-то вычисления, а не синтетические тесты. Сделать можно установив и настроив cms, выкинуть из нее все лишнее и прикрутить скрипт для заливки базы и выставления ее параметров. И так раз 5-10 для топа по популярности.
Также интересно отработка нескольких запросов ( 10-100 ) — в параллель — сurl в помощь.
И также время ответа по часам в сутках — есть ли полки нагрузки, — важно не иметь провалов.
В текущем состоянии рейтинг — ни о чем.
Также интересно отработка нескольких запросов ( 10-100 ) — в параллель — сurl в помощь.
И также время ответа по часам в сутках — есть ли полки нагрузки, — важно не иметь провалов.
В текущем состоянии рейтинг — ни о чем.
Протестил хостера
Висит 4 проекта — точнее 5
Проблем по этим тестам с хостером не обнаружил
hostertest.ru/hosters/info/271
Висит 4 проекта — точнее 5
Проблем по этим тестам с хостером не обнаружил
hostertest.ru/hosters/info/271
Паутинную диаграмму не осилил. %) Предпочитаю простую таблицу с цифрами.
Очередная попытка померять линейкой круглый аквариум.
Что выясняется в результате теста, что у говнохостера с пустым сервером все быстро и круто? Так это и без теста понятно.
Топ вашего рейтинга — author-media.ru
person: Private person
REGTIME-REG-RIPN
Контакты:
ICQ: 392-***
e-mail: support @ author-media.ru
Вы не поверите, но мне и тестов не надо никаких что б понять, что время жизни этого «проекта» полгода от силы.
Что выясняется в результате теста, что у говнохостера с пустым сервером все быстро и круто? Так это и без теста понятно.
Топ вашего рейтинга — author-media.ru
person: Private person
REGTIME-REG-RIPN
Контакты:
ICQ: 392-***
e-mail: support @ author-media.ru
Вы не поверите, но мне и тестов не надо никаких что б понять, что время жизни этого «проекта» полгода от силы.
Не стоит ожидать чуда от этого тестирования. Он худо-бедно тестирует только техническую платформу и не более. Огромное множество факторов (надёжность, репутация хостера, качество поддержки, цены, качество каналов и т.д.) остаётся за бортом.
Поэтому, конечно же, такой тест не даст полной картины о хостинге.
И, конечно же, одним лишь тестированием технической платформы нельзя ограничиваться при подборе хостинга.
Это, собственно, заявлялось изначально.
Думаю, стоит относиться к этому тесту проще :)
Поэтому, конечно же, такой тест не даст полной картины о хостинге.
И, конечно же, одним лишь тестированием технической платформы нельзя ограничиваться при подборе хостинга.
Это, собственно, заявлялось изначально.
Думаю, стоит относиться к этому тесту проще :)
Мешать в кучу результаты шаредов и вдсов бред полнейший.
Да и вдсы бывают a) с жесткими лимитами на процессор б) с мягкими лимитами на процессор и пустым сервером, ох они вам и покажут ц) С мягкими лимитами на процессор и полным сервером (Причем б медленно переползает в ц )
Вот бы набрали статистики за год, да по большому количеству клиентов, может быть вышло что то интересное. Хотя, клиента раз в час произволящий милион записей низачем я бы выпер. Ибо нечего сервер грузить.
Да и вдсы бывают a) с жесткими лимитами на процессор б) с мягкими лимитами на процессор и пустым сервером, ох они вам и покажут ц) С мягкими лимитами на процессор и полным сервером (Причем б медленно переползает в ц )
Вот бы набрали статистики за год, да по большому количеству клиентов, может быть вышло что то интересное. Хотя, клиента раз в час произволящий милион записей низачем я бы выпер. Ибо нечего сервер грузить.
Спасибо за сервис! Уверен, что его ждет успех.
Маленькая рекомендация: используйте относительные (а не абсолютные) координаты на диаграмме-паутинке, где вы сравниваете тесты. Сейчас используется только несколько %% площади диаграммы (маленький кусочек ближе к центру). А если использовать относительные значения, то можно будет более наглядно и точно их сравнивать.
img202.imageshack.us/img202/8218/diagram.gif
Маленькая рекомендация: используйте относительные (а не абсолютные) координаты на диаграмме-паутинке, где вы сравниваете тесты. Сейчас используется только несколько %% площади диаграммы (маленький кусочек ближе к центру). А если использовать относительные значения, то можно будет более наглядно и точно их сравнивать.
img202.imageshack.us/img202/8218/diagram.gif
readme.txt не utf8 :( пришлось сделать лишние движения
Sign up to leave a comment.
Проверка производительности хостинга