Clodo.ru — облачный хостинг

Разгребаю черновики и на очереди циферки по тестированию Облачного хостинга от Clodo.ru. Машинку на тест мне предоставили без всяких проблем и очень быстро, за что большое спасибо директору по маркетингу Аурике Виларди.

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

Выбор тарифа виртуального сервера Clodo.ru

Тесты

root@214552-1:~# curl -s http://freevps.us/downloads/bench.sh|sh
CPU model : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
Number of cores : 4
CPU frequency : 2266.810 MHz
Total amount of ram : 505 MB
Total amount of swap : 0 MB
System uptime : 3 days, 16:11,
Download speed from CacheFly: 3,95MB/s
Download speed from Coloat, Atlanta GA: 837KB/s
Download speed from Softlayer, Dallas, TX: 1,45MB/s
Download speed from Linode, Tokyo, JP: 908KB/s
Download speed from i3d.net, Rotterdam, NL: 1,78MB/s
Download speed from Leaseweb, Haarlem, NL: 2,27MB/s
Download speed from Softlayer, Singapore: 976KB/s
Download speed from Softlayer, Seattle, WA: 1,26MB/s
Download speed from Softlayer, San Jose, CA: 1,00MB/s
Download speed from Softlayer, Washington, DC: 1,62MB/s
I/O speed : 225 MB/s

4 ядра, полгига ОЗУ, своп не подключен. Каналы — средние. Дисковая, при линейной записи показывает средние результаты — не SSD же.

root@214552-1:~# dd if=/dev/zero of=zero.txt bs=1M count=17000 oflag=nocache && rm zero.txt
17000+0 records in
17000+0 records out
17825792000 bytes (18 GB) copied, 107,388 s, 166 MB/s
root@214552-1:~# dd if=/dev/zero of=zero.txt bs=1M count=17000 oflag=direct && rm zero.txt
17000+0 records in
17000+0 records out
17825792000 bytes (18 GB) copied, 84,6209 s, 211 MB/s

По случайным записи и чтению цифры немного странные, хотя, наверное, специалисты могут это объяснить:

readtest: (groupid=0, jobs=1): err= 0: pid=19960
read : io=1556.3MB, bw=3616.4KB/s, iops=904 , runt=440662msec
clat (usec): min=3 , max=1581.6K, avg=8813.32, stdev=29563.36
writetest: (groupid=0, jobs=1): err= 0: pid=19961
write: io=16597MB, bw=38585KB/s, iops=9646 , runt=440461msec
clat (usec): min=2 , max=1111.3K, avg=797.47, stdev=5314.40

Я про то, что IOPSов на запись получилось больше, чем на чтение. Может, что-то с приоритетами — не знаю.

Дальше тесты вебприложения, коим у нас выступает WordPress.

Server Software: lighttpd/1.4.28
Server Hostname: 62.76.40.6
Server Port: 80

Document Path: /
Document Length: 28143 bytes

Concurrency Level: 10
Time taken for tests: 116.161 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 28363000 bytes
HTML transferred: 28143000 bytes
Requests per second: 8.61 [#/sec] (mean)
Time per request: 1161.611 [ms] (mean)
Time per request: 116.161 [ms] (mean, across all concurrent requests)
Transfer rate: 238.45 [Kbytes/sec] received

С кэшированием, по обыкновению, ситуация меняется. Получилось выжать чуть больше 50 мбит/с статики.

Server Software: lighttpd/1.4.28
Server Hostname: 62.76.40.6
Server Port: 80

Document Path: /
Document Length: 28182 bytes

Concurrency Level: 300
Time taken for tests: 41.902 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 285380000 bytes
HTML transferred: 281820000 bytes
Requests per second: 238.65 [#/sec] (mean)
Time per request: 1257.050 [ms] (mean)
Time per request: 4.190 [ms] (mean, across all concurrent requests)
Transfer rate: 6651.08 [Kbytes/sec] received

Итак, выводы

  • Относительно недорого (мой тариф обошелся бы в 755 рублей в месяц)
  • Простая панель
  • Русскоязычный саппорт

Стоит ли использовать? Почему нет, хорошая репутация и не первый год на рынке. Очень неплохие ДЦ. Заказать виртуальный сервер можно тут.

7 Comments

  1. Максим

    Иопсов в операциях записи показывается больше потому, что весь поток записи проходит через кэш. Операции чтения тоже используют кэш, но для того что бы данные попали в кэш при чтении, их надо хотя бы один раз запросить. Т.е. в первый раз файл будет читаться со скоростью дисков, второй раз уже из кэша. Если этот файл какое то время не запрашивается, он удаляется из кэширующего уровня и в следующий раз при его запросе вновь будет прочитан напрямую с дисков.

    Объяснение, конечно, сумбурное. Но надеюсь понятное 🙂

    • Так-то оно так, в общих случаях. В данном случае происходило случайное чтение/запись из/в файл размером «bs=1M count=17000». Оно не влезло бы в кэш моей виртуалки. А как там кэшируется снаружи — это уже другое дело.
      Так что для меня такой разброс остается немного странным.

    • Максим

      Как раз при случайном записи и чтении можно кэшировать только запись. Поэтому и иопсов больше — запись кэшировалась. Кэширование естественно на стороне дисковой подсистемы происходит а не в кэше виртуалки. И массива кэш очень большой — около 250ГБ поэтому по записи много влезет.

    • Максим

      Реальная производительность выше естественно. Но учитывая, что не вы один используете сторадж, то вам «досталось» именно столько. В состоянии покоя или когда вы на нем одни, Сторадж отдал бы около 110 тысяч иопсов на рандомное чтение блоками по 4к. Это физический потолок всех шпинделей в рейде одного сегмента стораджа.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *