ua-hosting.company: облачный сервер в Нидерландах и США по цене хостинга, дешевле ip

kxk, но их читают больше и чаще чем email. Это факт.

С того времени как мы ввели эту практику был заблокирован из-за жалобы только один сервер, потому что номер телефона был отключен. А ранее это было часто, весьма часто. По sms бегут все и сразу.

Да, спасибо, сделаем, и не только по SMS, Viber / Telegram также подключим, ибо есть случаи, когда SMS не доходят, либо просто пользователь не смотрит их. Я вот лично также не часто смотрю.

Не обязательно. email я мониторю, SMS может и сутками ждать проверки...

LineHost, это вы и еще несколько человек, но большинство, думаю не ошибусь, если скажу более 90% людей на SMS реагируют сразу.

Добрый вечер!

Пришла и наша очередь написать отзыв (наш проект, для которого, собственно, и брался хостинг, уже работает ~2 недели, так что уже можно рассказать, что и как).

Дальше много букв, поэтому сразу наш вывод, кто испугался и решил не читать до конца:
Услугой полностью довольны, все быстро и стабильно.

Кратко о нас - разработчики десктопного софта базы ключевых слов.

Хостинг от ua-hosting.company нам нужен прежде всего для практической (в боевых условиях) проверки некоторых технических моментов (основной проект ещё не готов, но наработки для проверки уже есть).

Поэтому было решено попутно решить 2 задачи:

1. Проверить эти самые технические моменты в боевых условиях.

2. Выпустить что-то полезное, которые было бы нужно и привлекло аудиторию.

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

1. Сервис предоставить бесплатно.

2. Не требовать регистрации для доступа к сервису (т.е. просто заходи и пользуйся).

Сам сервис - это подбор ключевых слов по домену конкурента.

Ну а теперь возвращаемся к хостингу.

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

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

Но после общения с поддержкой выяснилось, что скан нужен для тестирования (т.е. когда полностью бесплатно).

В нашем же случае оплата была (февраль куплен, январь по условиям акции - бесплатно).

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

Ну а если в процессе выяснится, что нужен скан - то принять решение по факту - если ситуация такая, что действительно нужен, то предоставить, если надуманная - то отказаться от услуги.

В первую очередь нас заинтересовал выделенный SSD накопитель (поэтому собственно и обратили внимание на этот топик), поэтому конфигурация была куплена следущая:

VPS 12 Cores E5-2650v4, 20GB DDR4, 480GB SSD

Сейчас уже сложно вспомнить, сколько времени активировался сервер, но что-то типа часа или близко к этому (+/-).

Т.е. с нашей точки зрения это быстро, тем более если учесть, что это было 31 декабря :)

SSD

Прежде всего решили протестировать SSD с помощью CrystalDiskMark:

Sequential Read (Q= 32,T= 1) : 2987.601 MB/s

Sequential Write (Q= 32,T= 1) : 2035.610 MB/s

Random Read 4KiB (Q= 32,T= 1) : 148.416 MB/s [ 36234.4 IOPS]

Random Write 4KiB (Q= 32,T= 1) : 128.225 MB/s [ 31304.9 IOPS]

Sequential Read (T= 1) : 3775.585 MB/s

Sequential Write (T= 1) : 1596.060 MB/s

Random Read 4KiB (Q= 1,T= 1) : 55.548 MB/s [ 13561.5 IOPS]

Random Write 4KiB (Q= 1,T= 1) : 48.368 MB/s [ 11808.6 IOPS]

Test : 1024 MiB [C: 3.1% (13.3/431.9 GiB)] (x5) [Interval=5 sec]

Нас прежде всего интересовали случайные чтения, результаты нас полностью устроили.

Sequential Read и Sequential Write показались нам слишком высокими, было такое ощущение, что где-то что-то кешируется.

У CrystalDiskMark есть возможность увеличить область тестирования (по умолчанию она 1 Гб), чтобы не попадать в кеш.

Увеличили, провели повторный тест:

Sequential Read (Q= 32,T= 1) : 2921.873 MB/s

Sequential Write (Q= 32,T= 1) : 2022.334 MB/s

Random Read 4KiB (Q= 32,T= 1) : 137.367 MB/s [ 33536.9 IOPS]

Random Write 4KiB (Q= 32,T= 1) : 129.519 MB/s [ 31620.8 IOPS]

Sequential Read (T= 1) : 3893.853 MB/s

Sequential Write (T= 1) : 1640.742 MB/s

Random Read 4KiB (Q= 1,T= 1) : 52.716 MB/s [ 12870.1 IOPS]

Random Write 4KiB (Q= 1,T= 1) : 49.217 MB/s [ 12015.9 IOPS]

Test : 32768 MiB [C: 44.7% (193.1/431.9 GiB)] (x5) [Interval=5 sec]

Это практически не изменило цифры.

В итоге просто скопировали большой файл в nul и посмотрели сколько времени это займет.

Скорость вышла ~420 Mb/sec для последовательного чтения, на чем мы и успокоились (на выяснение, где все-таки и что кешируется, просто решили не тратить время).

CPU и память

После этого решили потестировать CPU и память.

С нашей точки зрения для этого идеально подходит архиватор 7-zip (у него есть встроенный benchmark, и его результаты хорошо ложатся на нашу задачу).

Тестирование проводилось со словарем 2 MB и 32 Mb.

Тест с словарем 2 MB:

1 - 3009

6 - 14798

12 - 22852

Тест с словарем 32 MB:

1 - 2708

6 - 16395

12 - 26233

Первая цифра - это количество потоков, вторая - MIPS, общий рейтинг.

Из этих цифр можно сделать простой вывод - чем интенсивнее используется память (словарь 32 MB - более интенсивно, чем словарь 2 Mb), тем лучше масштабирование по ядрам.

Для варианта со словарем 32 Mb оно почти линейное, что очень хорошо.

Поскольку VPS - это не ты один, а всегда с "соседями по коммуналке", то было интересно проверить, насколько цифры могут меняться со временем.

Запускали тест повторно в разное время суток, цифры были такими же, на чем опять же и успокоились :)

Сеть

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

Но проверили по другому - с трех разных обычных ПК у разных провайдеров начали загружать данные по полной (100 мбит).

В итоге ~300 мбит было стабильно загружены, т.е. на практике 300 Mbit (то, что было в силах проверить) отдаются отлично.

Дальше пришло время разработки самого проекта - разработка, баги, фиксы.

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

18 января был первый пик посещений - был анонс на разных форумах.

25 января был второй пик посещений - этот пик связан с тем, что 24 вечером мы были упомянуты в новостной ленте серча - /ru/news/40230 - соответственно, были как новые заходы с самого серча, так и с других ресурсов, которые новость растиражировали.

В пиках у нас было 80-90 одновременных поисков в секунду (для нас это самая тяжелая операция, просто запрос страничек с точки зрения нагрузки можно игнорировать).

Технически для нас один поиск - это 2-4 случайных операции чтения с диска, каждая объемом вплоть до 20 МБ (но обычно меньше 1 МБ).

Т.е. в итоге в моменты пика нагрузки это было от 160 ("легкий" вариант) до 360 ("тяжелый" вариант) IOPS.

Просто для сравнения: обычные десктопные HDD, грубо говоря, неплохо себя чувствуют приблизительно до 100 IOPS, все что свыше - уже проблема (медленно).

Серверные - приблизительно 150-200 IOPS - нормально, выше - тоже медленно.

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

Но благодаря SSD это даже не нагрузки (см. цифры выше: 33-36 тыс. IOPS для SSD), т.е. запас огромный, и мы уже знаем как его использовать :)

В итоге, как видно, выбор хостинга с выделенным SSD от ua-hosting.company себя полностью оправдал.

По CPU/памяти хотелось добавить следующее - изначально ни CPU, ни память не планировалось особо использовать.

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

Т.е. исходили из того, что нужен только быстрый SSD, а остальное - как получится.

Но в реальности получилось, что CPU было столько и памяти столько, что данные уже формировались на самом сервере, и не было необходимости формировать их локально.

Более того, по результатам боевого теста (первый пик) - стало видно, что CPU более, чем достаточно, схема работы ещё немного поменялась, и часть данных мы стали считать "на лету", не формируя заранее.

Ну и поскольку ресурсов сервера хватает с избытком, то решили добавить (пока в разработке) ещё один модуль, который изначально не планировали.

По поводу hosting_manager (Sergii Sikorskyi)

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

Поэтому было решено поспрашивать в чате у поддержки, что и сколько стоит, в итоге в чате попали именно на Sergii Sikorskyi (он же здесь hosting_manager).

Ответив на несколько технических вопросов, Сергей задал пару вопросов-уточнений для чего нужно, предложил ещё пару возможностей.

Потом снова ответил на вновь возникшие вопросы...

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

Все это время Сергей отвечал на все вопросы, которые возникли, и которые уже, наверное, достигли стадии "непонятно будут ли клиентами, но голову поморочат" :)

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

Впечатление об общения исключительно положительное - все по делу.

Итого:

1. Техническая часть (железо) - отлично.
2. Консультация hosting_manager - отлично.
3. Тех. поддержка - "общие" вопросы - отлично, решение проблем - неизвестно (не пришлось воспользоваться).

Надеемся, наш отзыв, пусть и отчасти субъективный, был интересен и полезен.

Спасибо hosting_manager за отличную услугу.

Марина и Сергей,

Команда Букварикс

Лучше бы использовали fio. Более приближенные к реальности тесты отображает, естественно при верном подходе.

Что вы подразумеваете в термине "десктопные"? У меня последний диск на старом десктопе был лучше чем у многих на серверных платформах стоят. Лучше по производительности имею ввиду, другое не обсуждаю. Характеристики нужно смотреть, если есть возможность, или тестировать, а не клеймо ставить. Вот если взять наугад 20 провайдеров с северным железом из СЕ, то 90%, если не у всех вы не сможете выжать из диска того что описали, это нонсенс.

Или вы ведете разговор об дисковом массиве из нескольких накопителей? Ну хорошая дисковая как правило на нодах, но виртуальный сервер не один на ноде, их много, по этому аналогично выше производительности не будет?

Если об цифрах, то я пока не видел ни одного диска (или двух в RAID1), которые бы смогли выдать больше чем 192 IOPS random read-write. Если честно то только одну дисковую такую видел (RAID1), на втором месте 173 IOPS. А вообще выше 150 нашел только три накопителя. Хотя список протестированных уже большой. Как правило 100-120 у нормальных дисков. Это все при сохранении латентности до 10 msec. Что выше это никому не нужно.

По этому об каких 200 iops и выше идет речь вообще непонятно. Попугаи эти никому не нужны, тесты должны быть близки к реальности.

Извиняюсь, что встрял в тему, просто цифры мифические, причем все перечисленные.

WapGraf, попробуем сказать по другому:

Обычные лучшие компьютерные 3.5 HDD (именно их мы называем десктопными) вряд ли смогут значительно преодолеть 100 IOPS.

Серверные SAS, в самом лучшем исполнении, вряд ли смогут взять значительно больше 200 IOPS.

Какое количество из предложенных на рынке самых лучших серверных SAS 15000 RPM перейдет 200 IOPS - не знаем, у нас нет серверного парка HDD.

Наш посыл был в том, что в самом-самом лучшем случае, мы не можем расчитывать на скорость больше 200 IOPS даже для лучших SAS HDD.

Если вы говорите, что на вашей практике самый лучший выдал 192 IOPS - так тому и быть, пусть вместо 200 будет 192, сути это не меняет.

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

В любом случае, она вряд ли будет больше 200 IOPS, а скорее всего меньше.

Т.е. речь шла о том, что даже получив отличное решение в виде SAS HDD, мы бы значительно не вышли за 200 IOPS в случае одного диска

(а в реальности эта цифра в силу разных причин была бы меньше).

А нам уже нужно было больше, т.е. без SSD никак.

Приведенные цифры не мифические, а предельно допустимые.

Если нужны ссылки подтверждения , то вот сходу находятся несколько ссылок:

https://answers.splunk.com/answers/84340/how-many-iops-can-i-expect-from-a-disk.html

Device Type IOPS Interface

=========== ===== ================ ===========

7,200 rpm SATA ~75-100 IOPS[2] SATA 3 Gb/s

10,000 rpm SATA ~125-150 IOPS[2] SATA 3 Gb/s

10,000 rpm SAS ~140 IOPS[2] SAS

15,000 rpm SAS ~175-210 IOPS[2] SAS

http://community.netapp.com/t5/FAS-and-V-Series-Storage-Systems-Discussions/IOPS-for-SATA-SAS-FC-disks/td-p/51494

sata 70-80 iops

scsi

10k FC/sas 110-120 iops

15k FC/sas 150-160 iops

http://serverfault.com/questions/512386/hdd-performance-differences-between-7-2k-sata-and-15k-sas

For a 7.2K RPM drive, a seek-time of 8.5ms and latency of 4.16 gives an IOPS number of 78.

For a 15K RPM drive, a seek-time of 2.6ms and latency of 2.0ms gives an IOPS number of 217.

For a 15K RPM drive, a seek-time of 3.4ms and latency of 2.0ms gives an IOPS number of 185.

Bukvarix, раз вы сравниваете с десктопными дисками, то однозначно речь НЕ идет об SAS, ибо таковых нету. А раз это SATA HDD то 15K RPM не в тему.

WapGraf, мы нигде не говорили о том что SATA это 15000, и не сравнивали исключительно с десктопными дисками.

... перечитайте внимательно наш отзыв :)

Колеги, не сосвем понимаю о чём спор. Само собой на этих виртулаках с дисковыми операциями будет всё ок, и этот в этом случае вопрос про проблемы с IO надо просто забыть.

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

По опыту своих коллег, которые несколько лет тому назд затеяли виртуалки с выделенными на виртуалку накопителями, то эта услуга не оправдалась.

---------- Добавлено 31.01.2017 в 11:34 ----------

Да забудьте десктоповое/серверное. Это муть.