Ну не надо сравнивать хетзнер, где десктопные компьютеры стоят без нормального питания, охлаждения, ухода и сети, с датацентрами. Особенно, как я понял из описаний, премиум-класса.
Лучше бы посадили в саппорт людей, которые не отвечают на вопрос о смене IP шаблоном про получение доп. информации для устранения технической неполадки.
Вы говорите, что при тестировании мы сможем получить цифры, которые характеризуют каким-либо образом сервер провайдера. Я соглашаюсь с этим, но говорю, что эти цифры не нужны пользователю — они не несут информации о том, как будет хостинг работать для того, чтобы хостить сайт пользователя.
Ни один сайт никогда не будет в 1 поток долго проводить операции с памятью внутри себя. Вы тестируете это. Намного интереснее — тестировать 10-30 параллельных недолгих вычислений, которые по времени укладываются в генерацию средней страницы, так как это почти покажет реальную ситуацию при посещении сайта.
Ни один сайт никогда не будет часто делать select на 10000 элементов. Вы тестируете это. Намного интереснее — тестировать много параллельных запросов в MySQL с небольшими ответами, иногда перекрывающимися, иногда — нет, так как это покажет еще и качество настроек кеширования MySQL. Это тоже почти покажет реальную ситуацию при посещении сайта.
Ни один сайт (и не только сайт) никогда не будет читать побайтово 1 мегабайт данных из одного файла. Вы же тестируете это. Намного интереснее — делать большой файл и читать его большим куском, чтобы узнать среднюю скорость потокового чтения. А потом еще читать много маленьких файлов в случайном порядке, чтобы узнать среднюю скорость рандомного чтения. Это тоже почти покажет реальную ситуацию при посещении сайта.
Клиенту, на мой взгляд, не нужны непонятные цифры для сравнения некоторых пузомерок хостеров. Ему нужно сравнение того, как его сайт будет работать на этих хостерах.
Мне кажется, что задача тестирования хостинга — поиск провайдера, у которого будет быстро и без падений работать сайт, а не быстро считаться миллион синусов.
Ну вот тест CPU — что он покажет? Он покажет, сколько астрономического времени будет выполняться тест, требующий 0.4 секунд процессорного времени подряд. Это может дать примерную оценку количества конкуррентных запросов за сервер а данный момент времени, используемого планировщика и его настроек. Но это не даст никакой информации о том, как эти процессорные секунды перейдут в астрономические при 10 запросах на сайт клиента и еще 50 на другие сайты на сервере.
Вы все равно не поняли идею моего комментария, она заключалась в последних строках.
Тестировать хостинг надо не синтетическими тестами, а именно реальными сайтами. В комментарии я просто показал конкретно, по каким причинам каждый из синтетических тестов не будет показывать нужной картины.
1. DipHost тут вроде-бы писал, что у них количество детей Apache на пользователя зависит от ТП.
2. Монстры вроде MasterHost, РБК. Правда, по ним информации нет, это оценка по скорости работы сайтов. Возможно, они суют разные ТП на разные сервера, которые загружены по-разному — оттуда и получается разница.
Как надоело, когда люди, ничего не понимающие в хостинге, пытаются оценивать работу людей, что-то понимающих в хостинге. Ну, давайте по пунктам:
>Хостер
>Тарифный план
>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% самых быстрых, по остальному посчитайте среднее значение для каждого часа, проанализируйте получившуюся функцию, сравните с другими результатами. Получите тестирование хостера, показывающее то, что должно показывать тестирование хостера — как на нем работают сайты, а не за сколько он считает миллион синусов.
Множество.
Второе множество.
Каждому элементу одного множества сопоставляем элемент другого множества по определенному правилу.
Получается функция.
Математический анализ — совокупность разделов математики, посвященных исследованию функций и их обобщений.
А Вам не кажется, что когда человек с таким подходом уйдет от JS и перейдет на PHP, то станет только хуже?
Мне приходится почти каждый день видеть шедевры пхпшного сайтостроения, там встречаются вещи и похуже (например, недавно — при каждом запросе 1) загрузка файла в память (10^6 записей по 32 байта, файл изменяется пару раз в месяц, файл растет), 2) проход по ним всем в поисках соотвествия).
Ну, согласитесь, неправильно называть уявзимостью именно FreeBSD или Linux уязвимость в ПО, которое можно использовать на этой ОС. null pointer dereference в kqueue — на мой взгляд это уязвимость в FreeBSD.
ZFS в ядре, насколько я понимаю, реализовал не Sun, так что этот баг как раз в FreeBSD.
Вы говорите, что при тестировании мы сможем получить цифры, которые характеризуют каким-либо образом сервер провайдера. Я соглашаюсь с этим, но говорю, что эти цифры не нужны пользователю — они не несут информации о том, как будет хостинг работать для того, чтобы хостить сайт пользователя.
Ни один сайт никогда не будет в 1 поток долго проводить операции с памятью внутри себя. Вы тестируете это. Намного интереснее — тестировать 10-30 параллельных недолгих вычислений, которые по времени укладываются в генерацию средней страницы, так как это почти покажет реальную ситуацию при посещении сайта.
Ни один сайт никогда не будет часто делать select на 10000 элементов. Вы тестируете это. Намного интереснее — тестировать много параллельных запросов в MySQL с небольшими ответами, иногда перекрывающимися, иногда — нет, так как это покажет еще и качество настроек кеширования MySQL. Это тоже почти покажет реальную ситуацию при посещении сайта.
Ни один сайт (и не только сайт) никогда не будет читать побайтово 1 мегабайт данных из одного файла. Вы же тестируете это. Намного интереснее — делать большой файл и читать его большим куском, чтобы узнать среднюю скорость потокового чтения. А потом еще читать много маленьких файлов в случайном порядке, чтобы узнать среднюю скорость рандомного чтения. Это тоже почти покажет реальную ситуацию при посещении сайта.
Клиенту, на мой взгляд, не нужны непонятные цифры для сравнения некоторых пузомерок хостеров. Ему нужно сравнение того, как его сайт будет работать на этих хостерах.
Ну вот тест CPU — что он покажет? Он покажет, сколько астрономического времени будет выполняться тест, требующий 0.4 секунд процессорного времени подряд. Это может дать примерную оценку количества конкуррентных запросов за сервер а данный момент времени, используемого планировщика и его настроек. Но это не даст никакой информации о том, как эти процессорные секунды перейдут в астрономические при 10 запросах на сайт клиента и еще 50 на другие сайты на сервере.
Тестировать хостинг надо не синтетическими тестами, а именно реальными сайтами. В комментарии я просто показал конкретно, по каким причинам каждый из синтетических тестов не будет показывать нужной картины.
2. Монстры вроде MasterHost, РБК. Правда, по ним информации нет, это оценка по скорости работы сайтов. Возможно, они суют разные ТП на разные сервера, которые загружены по-разному — оттуда и получается разница.
>Хостер
>Тарифный план
>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% самых быстрых, по остальному посчитайте среднее значение для каждого часа, проанализируйте получившуюся функцию, сравните с другими результатами. Получите тестирование хостера, показывающее то, что должно показывать тестирование хостера — как на нем работают сайты, а не за сколько он считает миллион синусов.
Второе множество.
Каждому элементу одного множества сопоставляем элемент другого множества по определенному правилу.
Получается функция.
Математический анализ — совокупность разделов математики, посвященных исследованию функций и их обобщений.
Правда, вместо картонной трубочки была обычная деревянная палка.
Мне приходится почти каждый день видеть шедевры пхпшного сайтостроения, там встречаются вещи и похуже (например, недавно — при каждом запросе 1) загрузка файла в память (10^6 записей по 32 байта, файл изменяется пару раз в месяц, файл растет), 2) проход по ним всем в поисках соотвествия).
ZFS в ядре, насколько я понимаю, реализовал не Sun, так что этот баг как раз в FreeBSD.