Евгений Русаченко

Евгений Русаченко
Рейтинг
174
Регистрация
17.04.2013

А теперь, добро пожаловать всем! Описываем секреты и магию тестирования автора.

1. Автору был выдан аккаунт. На тарифе сразу же установлен скрипт bitrixsetup.php + создана база данных для сокращенной установки.

2. Примерно через неделю автор устанавливает систему 1С-Битрикс с нестандартным шаблоном (адрес сайта: sergej.p-host.in, скриншот http://yadi.sk/d/tPgEjy4NMCkW3, можно посмотреть лично, адрес все равно был уже сообщен, скрывать нечего) Может шаблон и обычный, стандартный и я просто о нём не знаю, но суть не в этом, суть в том, что в шаблоне есть некоторая тонкость, о которой далее.

3. Автор проводит тестирование, из которого сайт получает 20 баллов (скриншот: http://yadi.sk/d/NBOzegUEMCkkT)

Отлично, такой бал действительно был получен, этого никто не отрицает, но вопрос как? Остается далее.

4. Автор проводит нагрузочное тестирование с числом одновременных соединений от 500 до 4 500. Уважаемые участники, простите, но на каком виртуальном хостинге разрешено даже его минимальное 500 одновременных соединений? Мне кажется, мало на каком. В добавок, точно не на виртуальном хостинге с OS от CloudLinux. Открыто можем сказать, что на выданном тарифе стоит не более 48 одновременных соединений. В итоге наблюдаем такую картинку: 100% ошибок (скриншот: http://yadi.sk/d/b-sicPqQMCkwt)

Да, было, но проблема не только в ограничении 48 соединений. Есть еще одна тонкость о которой далее.

Разбор масштабирования и 100% числа ошибок

Как и говорилось, вернемся к шаблону. В используемом шаблоне при каждом обновлении страницы меняется длина (скриншот: http://yadi.sk/d/eqwOC_aPMCmEY) из-за случайно выводимой информации (я сам на этом был пойман, когда тестировал сайт автора в этой теме), собственно, это видно при сравнении исходников. Следовательно, при тестировании почти всегда возвращается разная длина страницы и это считалось ошибкой! Тоже самое можно наблюдать и при тестировании с помощью ab:

Time taken for tests: 13.687 seconds

Complete requests: 1630

Failed requests: 1628

(Connect: 0, Receive: 0, Length: 1628, Exceptions: 0)

Следовательно, тестирование масштабируемости можно считать не действительным. Может быть другим участникам он ставил другой шаблон, но нам попался именно этот.

Оценка системы

С этим сложнее, так как если просто запускать оценку системы, то выдает 57 баллов (скриншот: http://yadi.sk/d/yJHX2zWHMCmtv)

Можно предположить, что в момент измерения сервер был загружен (но это маловероятно, у нас за последнюю нагрузки ресурсы всегда оставались свободными: http://yadi.sk/d/0Se8LXQeMCnQH, как и сейчас). Следовательно, оценка делалась видимо в момент масштабирования. Отлично, запустим и проверим: (скриншот: http://yadi.sk/d/BebfPfBmMCo3f)

1 балл! 500 соединений и недостаток ресурсов дают о себе знать.

Но исходя из того, что хостинг аккаунт не рассчитан на 500+ соединений, то 1 балл можно принять нормой. CloudLinux, ограничивая ресурсы, со своей задачей вполне справляется.

Ниже видео тестирования сайта автора и видео тестирования чистой Битрикс системы на этом же аккаунте:

Сайт автора: ~60 баллов

Тест масштабирования не проходится даже при минимальном числе соединений из-за особенности шаблона

Чистый Битрикс со стандартным шаблоном корпоративного сайта (длина страницы не меняется): ~90 баллов

Тест масштабирования проходит без ошибок 44-52 соединения со генерацией страницы в 0.011816 секунд, это эквивалентно 84 баллам - можно подчеркнуть, что при нагрузке. На 52 соединениях появляются ошибки, так как на аккаунте лимит в 48 соединений.

Автор, прошу объяснений. Мне надоело читать всю это ложь по отношению к участникам данного сообщества! Модераторы, прошу обратить внимание на это и по возможности предпринять какие-то меры в отношении автора. Я думаю, предоставлено информации должно хватить для этого.

Автор, да, и еще. Относительно 160 мб свободной памяти. Если Вы не знакомы с Linux, лучше промолчите. 20 гб памяти кешировано и в любой момент может быть отдано при необходимости любому из приложений:

If the cache is of a fixed size, it is not very good to have it too big, either, because that might make the free memory too small and cause swapping (which is also slow). To make the most efficient use of real memory, Linux automatically uses all free RAM for buffer cache, but also automatically makes the cache smaller when programs need more memory.

Откройте, прочитайте и ознакомьтесь: http://www.tldp.org/LDP/sag/html/buffer-cache.html

DanSol:
Евгений Русаченко, сорри, но я про то, что овх не спекся.

Если не изменяет память, то так написали, когда у них на всех серверах было "Sold Out". Сейчас такого уже нет вроде.

DanSol:
Вчера получил письмо следующего содержания

Тема с ip-адресами очень порадовала, доволен как слон, хорошая скачуха для клиентов.

Кажется, Вы ошиблись топиком. Это письмо из OVH, а тема про online.net в основном.

Sergej_Sim:
Один из читателей этой темы, хостер, попросил повторно протестировать качество своего хостинга.

Для теста нам выдали сервер на самом дорогом тарифном плане Битрикс-Эксперт.

Реклама на сайте обещает:

поэтому мы предполагаем, что сервер наберет не менее 30 баллов ...

Однако, запустив внутренний тест, видим, что наши ожидания не оправдались ...



Сервер не набрал даже 30 баллов, то есть норматив 2008 года для серверов "младших классов VDS-256" не сдан ...

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



На первой же секунде теста сервер выстреливает пачку из 500 ошибок, после чего на 13 секунде впадает в глубокую кому ...

Чтобы понять, в чем причина такой внезапной клинической смерти, вскрываем еще не остывшее тело пациента и запускаем посмертную диагностику



Быстрый взгляд на историю болезни пациента выделяет несколько моментов:

1.1 - Локация = Франция
( без комментариев ... )

1.2 - Операционная система = Cloud Linux
( пока ни один из протестированных нами серверов на этой OS не смог набрать более 30 баллов ...)

1.3 - Размер свободной памяти = 162 Мб
( противники тут же могут возразить, что она вся вытекла, например в кеш ? ... )

1.4 - Время бесперебойной работы - всего 154 дня ...
( без комментариев ... )

1.5 - На сервере обнаружено 598 сайтов
( противники тут же могут возразить, что на их серверах работает без проблем 5980 "высоконагруженных" проектов,
именно поэтому мы и запускаем многопоточный тест из расчета всего по 10 посетителей на один сайт сервера ... )

На копии экрана многопоточного теста преднамеренно показан адрес сайта сервера,
чтобы хостер не стал возражать, что тестировали не его хостинг ...

Остальные выводы наши уважаемые читатели могут сделать сами ...

Информация о хостере


Местоположение - Калининград
Тестируемый ДЦ - Франция
Начало работы - Май 2008
Клиентская база - 284 домена
Тарифный план - 900 рублей в месяц

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

Также непонятно тестирование в 500-4500 соединений. Понятно, что будет 100% ошибок, разрешено не более 48 соединений, на Вашем аккаунте. Почему Вы игнорируете стандартный тест в 32 соединения с ростом в 2 соединения?

Fansmorgan:
я думаю, что это тоже миф, а не реальность !

Не знаю, не приходилось пользоваться пока что. Отзывов о их защите пока не слышал и сам не сталкивался.

rustelekom:
В online.net взять недорогой сервер и переставлять насколько рук хватит. Но для дешевых они квм не дадут, так что надо будет вслепую. Также можно и у хетцнера взять что нибудь дешевое типа https://robot.your-server.de/order/market - тоже можно реинсталлить.

OS можно переставлять из панели, IPMI не требуется. Единственное, я бы сказал, что переустановка немного долгая. В том же Hetzner это делается быстрее.

Собственной, мой небольшой отзыв об их бизнес поддержке.

Несмотря на то, что на сайте написано, что при подключении бизнес поддержки будет выделен персональный менеджер, с которым можно оперативно связаться в будние дни для решения вопросов - ничего подобного! Ответ поддержки после подключения был таков: "Actually there is no project manager for foreigners, this is a bad information on our website." Но, Французы все же молодцы, человек из поддержки дал личный ящик (расположенный на домене online.net) для консультаций, правда не стал гарантировать быстрое время ответа.

Далее... Приоритетная, круглосуточная поддержка - миф, а не реальность. Как отвечали раз в сутки, так и отвечают, к сожалению. Ночью ответов нет. Более-менее оперативно реагируют на сообщения в твиттер, но общаться на французском... через переводчик... очень сложно.

Единственное отличие, которое заметил - это возможность расширенной DDoS защиты, заказа IP адресов подсетями (/27). И вроде всё.

ultrasparc:
Да, знаю. Но было достаточно обновления openssl и перезагрузки httpd, чтобы перестало ругатся на уязвимость.

Подтверждаю. Apache пересобирать не требуется. Единственное, перезапустили еще DirectAdmin, так как если установлено защищенное соединение при работе с панелью, уязвимость остается актуальной.

Только смутило то, что после обновления OpenSSL, проверка http://filippo.io/Heartbleed/ через раз выдавала сообщение о наличии уязвимости (видимо кеш?). Сейчас уже информация о незакрытой уязвимости не проскакивает.

hqhost:
проблема описана как именно DNS amplification и поэтому и предложены решения для него.

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

например, если речь идет о выделенном сервере, то может иметь место трафик к/c IPMI

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

Мне уже сообщили на другом ресурсе, как происходит общение по UDP протоколу и как работает с этим iptables.

А так, мне сообщили только что был исходящий UDP трафик. Куда, откуда - нет информации.

Еще раз спасибо за информацию, тема исчерпана.

speed-core:
За что платите, то и получаете.
Могли бы не экономить, и Вам все сделали бы. А так вы заказали VDS - его дали, там да на Украине форс-мажор, вам дали другой. Хотите переносите, хотите нет - Ваше право, ведь VDS дан, как и полагаться. Ну или деньги обратно заберите.

Прежде чем обвинять, нужно иметь представление что именно Вы заказали.

Я не оправдываю хостера "ибо можно было бы и человеческий фактор учесть", но и вы должны понимать - что они обязаны, а что нет, что заказали и что получили "VDS заказали, его и получили, пусть и в другой стране, и не надо сюда приплетать, что на нем Вы храните".

Я предерживаюсь политике "Клиент всегда прав", Но сам когда в роли клиента, стараюсь все свое "На всякий" держать при себе, в случаи "Форс-мажора"

(Просто некоторые хостеры дают то что заказал, а другие дают чуть больше, но это не показатель их квалификации)

Тут больше вопрос не в том, что хостер дает, дают все хостеры одинаково - VDS. А вот обслуживание разное. Конкретно в данном случае, странное обслуживание в виде миграции в новый дата центр.

Всего: 1131