Scaleway - облако из bare-metal ARM серверов c SSD

Kuzmitch, я читал эту статью.

Всё равно не совсем понимаю, в чём выигрыш именно промышленных масштабов. Ограниченная производительность как узкое место. Возможность порезать на мелкие ноды? Не лучше ли тогда VDS?

Узкое мезко? Большинство EC2 нод запущенных в облаке амазона примерно с такой же производительностью процессора и никто не убегает.

Под мощные процессоры на самом деле не так много задач.

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

Самый простой пример переезда средненагруженного проекта на сервисы, подобные Scaleway, это разделить на 2 машинки - БД и фронтенд, чтобы они друг дружке не мешали. Тут еще, правда, вопрос, что для MySQL лучше - 4 ядра по, скажем, 1 Гц или 1 ядро на 4Гц? (Скорее, последнее)

Любая динамика - мощная задача по сути, где чем быстрее, тем лучше. Смысл от кучи медленных ядер, если как правило один процесс = одно ядро.

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

https://twitter.com/kuzmitch_ru/status/595993684073656321

А что с каналом у хранилища? Скорость замеряли? Там постоянная скорость или общий канал какой-нибудь?

Нет, скорость не мерял. С hetzner до них пинг 20 мс, каких-то тормозов при заливке файлов не наблюдал, кроме 500-ошибок (за 12 часов примерно 50 штук). Файлы, правда, мелкие - от 5 кб до 10 мб.

Тут выше есть моя жалоба на заливку больших файлов, не знаю - поправили или нет. Сейчас все сделано через S3QL, там такие ошибки довольно прозрачно обрабатываются, я их даже не замечаю. Справедливости ради могу отметить, что в логах соседнего Google Cloud Storage тоже есть ошибки.

UPD 100 Мбит точно есть при заливке, но постоянно скачет. Потому что S3QL делает это во много потоков, и в зависимости от размера файла.

---------- Добавлено 07.05.2015 в 14:06 ----------

Вот, положил к ним 100Мб файл, раздается с их Infinite Storage. Можете тестировать:

http://kuzmitch.fr-1.storage.online.net/100MB.zip

Как исключение. Потому что как правило у большинства динамика не мощная задача.

В конце 90-х, кто помнит, а кто и сам писал, динамика запускалась через CGI на медленных Pentium 2, потом Pentium 3 процессорах. Время генерации странички было 300-1000 мс, целый perl интерпретатор запускался на каждый запрос. Это было медленно, но даже тогда процессор не был узким местом, CGI был. Переход на FastCGI, mod_perl, mod_php позволил генерировать ответы за 1-100 мс. С тех пор уже много лет большая часть времени динамики не на процессор тратится, а на БД или диск.

К сожалению, в данный момент нечем замерить. Кто проверит - выложите результат, пожалуйста.

Resolving kuzmitch.fr-1.storage.online.net... 212.47.225.66

Connecting to kuzmitch.fr-1.storage.online.net|212.47.225.66|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 104857600 (100M) [application/octet-stream]

Saving to: “STDOUT”



100%[======================================>] 104,857,600 26.2M/s   in 3.8s



2015-05-07 16:43:12 (26.4 MB/s) - written to stdout [104857600/104857600]