А теперь, добро пожаловать всем! Описываем секреты и магию тестирования автора.
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 гб памяти кешировано и в любой момент может быть отдано при необходимости любому из приложений:
Откройте, прочитайте и ознакомьтесь: http://www.tldp.org/LDP/sag/html/buffer-cache.html
Если не изменяет память, то так написали, когда у них на всех серверах было "Sold Out". Сейчас такого уже нет вроде.
Кажется, Вы ошиблись топиком. Это письмо из OVH, а тема про online.net в основном.
Местоположение - Калининград Тестируемый ДЦ - Франция Начало работы - Май 2008 Клиентская база - 284 домена Тарифный план - 900 рублей в месяц
Я по позже Вам видео отсниму, именно с этого же сайта, именно с этого же установленного Bitrix, именно Вами. Так как мне непонятно, как Вы тестируете.
Также непонятно тестирование в 500-4500 соединений. Понятно, что будет 100% ошибок, разрешено не более 48 соединений, на Вашем аккаунте. Почему Вы игнорируете стандартный тест в 32 соединения с ростом в 2 соединения?
Не знаю, не приходилось пользоваться пока что. Отзывов о их защите пока не слышал и сам не сталкивался.
OS можно переставлять из панели, IPMI не требуется. Единственное, я бы сказал, что переустановка немного долгая. В том же Hetzner это делается быстрее.
Собственной, мой небольшой отзыв об их бизнес поддержке.
Несмотря на то, что на сайте написано, что при подключении бизнес поддержки будет выделен персональный менеджер, с которым можно оперативно связаться в будние дни для решения вопросов - ничего подобного! Ответ поддержки после подключения был таков: "Actually there is no project manager for foreigners, this is a bad information on our website." Но, Французы все же молодцы, человек из поддержки дал личный ящик (расположенный на домене online.net) для консультаций, правда не стал гарантировать быстрое время ответа.
Далее... Приоритетная, круглосуточная поддержка - миф, а не реальность. Как отвечали раз в сутки, так и отвечают, к сожалению. Ночью ответов нет. Более-менее оперативно реагируют на сообщения в твиттер, но общаться на французском... через переводчик... очень сложно.
Единственное отличие, которое заметил - это возможность расширенной DDoS защиты, заказа IP адресов подсетями (/27). И вроде всё.
Подтверждаю. Apache пересобирать не требуется. Единственное, перезапустили еще DirectAdmin, так как если установлено защищенное соединение при работе с панелью, уязвимость остается актуальной.
Только смутило то, что после обновления OpenSSL, проверка http://filippo.io/Heartbleed/ через раз выдавала сообщение о наличии уязвимости (видимо кеш?). Сейчас уже информация о незакрытой уязвимости не проскакивает.
Да, я понимаю, спасибо, за Ваши развернутые ответы. При написании просто развернуто все описал, чтобы было понятно, о чем идет речь и выделил шрифтом важные для меня моменты, на них хотел получить ответ.
Мне уже сообщили на другом ресурсе, как происходит общение по UDP протоколу и как работает с этим iptables.
А так, мне сообщили только что был исходящий UDP трафик. Куда, откуда - нет информации.
Еще раз спасибо за информацию, тема исчерпана.
Тут больше вопрос не в том, что хостер дает, дают все хостеры одинаково - VDS. А вот обслуживание разное. Конкретно в данном случае, странное обслуживание в виде миграции в новый дата центр.