ScaleWay review?

[djcyry]

Hello ,
Anyone is using scaleway vps·s ?
i"ve got an invitation and i see good prices .

Deploy BareMetal SSD cloud server in seconds.

PS. https://community.scaleway.com (DISCOURSE)

[djcyry]

24 hours after i buy the vps server …and counting
No node available i guess …

[Falco]

Are you using their pre-made images?

It’s a very old unsupported version.

[djcyry]

Yes , its only for testing their vps service.
The problem is i can’t create ssh key now…

[erlend_sh]

Scaleway is blocked on Discourse support because of this:

Support for ARM servers

https://github.com/discourse/discourse_docker/issues/121 Continuing on from the discussion on ARM support at GitHub. ARM support would be extremely useful for owners of small communities like myself because of the extremely low price (like the Scaleway 2GB ARM servers for €2.99) and for those who can’t afford the move from cheap shared hosting to the dedicated or KVM machines that Discourse requires. There has also been some discussion of this on the Scaleway forums, although much of this h…

[brahn]

How about now that they have x64 virtual servers?

https://blog.scaleway.com/2016/04/05/vc1-new-affordable-variants/

[erlend_sh]

Good question. Does this new development change up the status quo @rriemann?

[probus]

Would be great to hear some experiences/speculation about the cpu power as well. They have C2550 (dedicated) and C2750 (vps + dedicated) which I’ve understood are slowish in single core performance. Are more available memory and cpu cores able to offset this compared to for example Digital Ocean?

[rriemann]

I have not run any tests yet, but I would be interested in a performance comparison as well.

[ljpp]

Are more available memory and cpu cores able to offset this compared to for example Digital Ocean?

Note that to the ScaleWay x64 servers are apparently based on Intel Avoton’s (Atom architecture), which to my knowledge do not feature Hyper Threading. So while the physical core count is high, the virtual core count is not. So obviously Xeons will beat these in benchmarks by a large margin (2-3 fold, maybe?).

That said, I am going to give them a try with my small side project during the summer. And if your site does not have massive traffic, they may well be worth considering as their plans have pretty large SSDs for the price.

Where and what kind of VPS you currently have?

[probus]

We use DO currently.

I know that’s the only supported install and all forums are (somewhat) different, but it would be great if we could get some more general guidelines on Discourse performance on different hardware. Or a way to run some kind of Discourse-benchmark to compare.

This is great info:

Do your users ever complain about the speed of Discourse?

in general: get a fast (single-core performance) CPU, fast disks, lots of RAM, and a low-latency network. The CPU’s single-core performance is the limiting factor for a lot of the page generation time (page render isn’t multi-threaded, so lots of slow cores isn’t useful), while most of the rest is down to how quickly the DB can service requests, which is helped by fast disks (so data gets loaded and saved quickly) and lots of RAM (so you never have to touch those fast disks in the first place). A low-latency network means you’re not left sitting around all day waiting for the packets to get from column A to column B.

But what kind of numbers are we talking about here? What would the 2-3 fold cpu speed difference do in terms of latency or concurrent users for example? What about having 2, 4 or 8 cores instead of one? Or doubling or quadrupling the RAM?

I can tell you Discourse runs fine on ScaleWay (x64) and the install is as easy as any. I have no idea of the performance, even in theory.

[mpalmer]

But what kind of numbers are we talking about here? What would the 2-3 fold cpu speed difference do in terms of latency or concurrent users for example?

If you doubled or tripled(!) single-core CPU performance, you’d be reducing the page generation component of site load time by about the inverse ratio (double CPU -> half the time; triple CPU speed -> third of the time). Note that’s only one component of site load time – there’s still the client-side JS rendering and network latency, which is completely outside your control, as well as database request processing time, which is within your control, but is dominated by the speed of your disks, and the size and speed of your RAM, rather than the CPU clock speed.

You will also be able to serve twice (or three times as many) requests as you would otherwise, because the CPU is completing requests that much faster, so it can move onto the next request quicker.

What about having 2, 4 or 8 cores instead of one? Or doubling or quadrupling the RAM?

Increasing either of these will increase the capacity of the machine to serve concurrent requests, if that is the current limiting factor. Each concurrent request takes up a CPU core (while the request is being processed), so if you want to process more requests simultaneously, you need more cores. Note, however, that with all CPUs produced these days, more cores on a single die equates to a lower per-core speed, so it’s a tradeoff. We (CDCK) run more machines, each with fewer (faster) cores, for maximum performance, but it does mean there’s more machines to power and manage.

Increasing RAM is needed once you’re running a certain number of unicorn worker processes, because each unicorn is only processing one request at a time, and each unicorn also consumes a certain amount of RAM (200-300MB, typically). So, if you had 16 cores but only 1GB of RAM (say), you could really only run 1-2 unicorns (RAM is also needed for the system, DB, etc) and all those extra cores would go to waste. Similarly, if you had 2 cores but 32GB of RAM (say), you could run 50 unicorns, but they’d all be arguing over the two available CPU cores and you’d be wasting most of that RAM. You need to balance CPU cores and RAM to get the most out of your system. There’s no hard-and-fast rules about that, though, because so much depends on what else the box is doing, the request rate and pattern of your visitors, and so many, many other things. It’s why I get the big bucks.

[probus]

Thanks!

So bringing this back to topic, ScaleWay (SW), we can roughly estimate that 1 DigitalOcean (DO) core is about twice as fast as 1 SW core. DO CPU is not dedicated, so the performance varies: worst case close to SW and best case even quicker.

That means that the page generation time on SW would be double that compared to DO. That may sound worst than it actually is, since most of the site load time is spent on client anyway. Maybe <100ms increase would be in the ballpark? The upside is with SW you can get more cores which bring you capacity to serve more concurrent users. 8 SW cores can handle roughly twice the traffic compared to 2 DO cores, since there is plenty of RAM available on both systems.

[codinghorror]

Lots of slow cores is not a good match to Discourse. If it was in a compiled language, perhaps that would be OK. But it’s Ruby.

[mpalmer]

Yeah, got to agree with @codinghorror here… I think it’ll cost you a lot more than 100ms in page generation time.

[ljpp]

Has anyone trialed Discourse on Scaleway’s x86_64 servers? I was about to start myself, but the setup fails early at the Dockers installation script.

 wget -qO- https://get.docker.com/ | sh

This results in error messages about AUFS support and suggests to install linux-virtual meta-packages for added support, but the installation does not complete even with them.

Right now I have no time to goof around, so I am moving to trusted ponies (DO or OVH), but I am still curious to try them at a later phase.

[ljpp]

Responding to myself. One needs to:

1. Create server
2. Hidden under server’s advanced settings, switch to bootscript that contains docker
3. Reboot
4. Voila! (Excuse my french)

[ljpp]

Oh and they block SMTP by default.

1. Say Merde! a few times. (Excuse my french)
2. Switch off STMP block in control panel’s security group settings.

(Hm…still having problems with Scaleway + SendGrid SMTP, even with the block disabled)

[ljpp]

As promised, now running my small hobby site on ScaleWay. Runs just fine on my light loads - few hundred page views per day, mostly anonymous visitors.

Perfectly usable for Discourse development and smaller communities. They should also scale up rather nicely, if needed. 50GB SSD is a great feature for the price. Single core performance is slow, which is easily seen in slow ./launcher rebuild times, but the web front-end works OK.

NOTE: discourse-setup defines the number of unicorns at 4, as the 2.99€ VC1S is dual core. Their cores are however Intel Atom / Avotons, which to my knowledge are non-hyper threading. I would stick to 3 unicorns.

[ljpp]

You need to hard reboot in order to unblock SMTP…