Announcement

Collapse
No announcement yet.

Scaleway's EPYC Powered Cloud Is Delivering Competitive Performance & Incredible Value

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Scaleway's EPYC Powered Cloud Is Delivering Competitive Performance & Incredible Value

    Phoronix: Scaleway's EPYC Powered Cloud Is Delivering Competitive Performance & Incredible Value

    Scaleway, the European cloud company we previously have talked about on Phoronix for their usage of Coreboot on servers, this week announced new "general purpose" VMs powered by AMD EPYC processors. Curious about the performance, I fired up some benchmarks.

    http://www.phoronix.com/vr.php?view=27677

  • dkasak
    replied
    Originally posted by atomsymbol View Post
    You are very good at avoiding precise questions to win over a discussion so that you seem to look "cool" in the end. The question was: How are you proposing to enable both "wget http://100.100.100.100:80/index.html" and "wget http://200.200.200.200:80/index.html" if you allocate only a single public IP address? If you change the question and answer it correctly the answer won't necessarily be applicable to the original question.
    OK buddy, now look. I gave you a detailed example of precisely this. It wasn't to look "cool" as you propose. The discussion on this story has well as truly moved on. It was to try to help an amateur to get on top of his web hosting skills. My example of how everybody implements this has clearly gone way over your head, and you're instead taking professional advice personally. Whatever. Buy some more IP addresses for all I care. You won't go far in IT with that combination of attitude and lack of intelligence.

    Leave a comment:


  • atomsymbol
    replied
    Originally posted by dkasak View Post
    Just be clear what you're trying to do. You were originally talking about services with hard-coded IPs, and now you're hosting domains?
    The base problem is that you assumed information that wasn't explicitly stated. I am not responsible for invalid assumptions you make when faced with incomplete information.

    Please read https://en.wikipedia.org/wiki/List_of_fallacies

    Originally posted by dkasak View Post
    I'm pretty sure you don't host anandtech.com and phoronix.com.
    It was an example.

    Originally posted by dkasak View Post
    But if you're running different domains, then you'd just use something like apache virtual hosts. I do this myself - I host a handful of sites ( my own blog, some charity stuff, a friend's blog ), all off the 1 server & IP, using apache virtual hosts.
    You are very good at avoiding precise questions to win over a discussion so that you seem to look "cool" in the end. The question was: How are you proposing to enable both "wget http://100.100.100.100:80/index.html" and "wget http://200.200.200.200:80/index.html" if you allocate only a single public IP address? If you change the question and answer it correctly the answer won't necessarily be applicable to the original question.

    Originally posted by dkasak View Post
    If these things are real world issues for you, then hurry up and learn how it's done before people realise they're flying blind
    No comment. The sentence is using low terminology.

    ----

    I am refraining from further responses to your posts in this discussion. If you write a response I predict it won't be about how you corrected your viewpoints.

    Leave a comment:


  • dkasak
    replied
    Originally posted by atomsymbol View Post

    You are proposing to "regenerate" anandtech.com and phoronix.com into anandronix.com/tech and anandronix.com/phoro! It is possible in theory, but unlikely to happen in practice.
    Oh dear No need for all bold. Just be clear what you're trying to do. You were originally talking about services with hard-coded IPs, and now you're hosting domains? I'm pretty sure you don't host anandtech.com and phoronix.com. But if you're running different domains, then you'd just use something like apache virtual hosts. I do this myself - I host a handful of sites ( my own blog, some charity stuff, a friend's blog ), all off the 1 server & IP, using apache virtual hosts.

    If these things are real world issues for you, then hurry up and learn how it's done before people realise they're flying blind

    Leave a comment:


  • atomsymbol
    replied
    Originally posted by dkasak View Post

    OK, OK. Once more ...

    So firstly, you come up with some mapping scheme. Here's one example. Let's say the 1st part of the URI will be something for your proxy to consume and act on, and that by convention, it will start wtih a 'p_' ( which I'll nominate as meaning 'proxy hint' ). The next part will be a port offset ... and let's say the backend port numbers start at 10000. So, for example:

    p_100 will mean "proxy this request to port 10100 ( ie 10000 - our base port, plus 100, which is our offset ).
    p_200 will mean "proxy this request to port 10100 ( ie 10000 - our base port, plus 200, which is our offset ).

    ---

    So http://100.100.100.100:80/index.html you'd expose externally as:
    http://100.100.100.100:80/p_100/index.html
    ... and the service which used to listen on 100.100.100.100:80 would be running on 100.100.100.100:10100

    Another way of expressing this is:
    /p_100 ==> 127.0.0.1:10100, or:
    /p_100 ==> 100.100.100.100:10100

    Then http://200.200.200.200:80/index.html you'd expose externally as:
    http://100.100.100.100:80/p_200/index.html
    ... and the service which used to listen on 200.200.200.200:80 would be running on 100.100.100.100:10200

    Another way of expressing this is:
    /p_200 ==> 127.0.0.1:10200, or:
    /p_200 ==> 100.100.100.100:10200

    ---

    The proxy could modify the URI on the way through ( eg strip out the proxy hint ... which you might do in a regular expression ... eg:
    s/\/p_[\d]*\//

    This would mean that the backend services wouldn't have to be altered to know about the leading proxy hint in the incoming requests.

    ---

    This is but 1 mapping scheme. You can come up with your own. I used numbers in the mapping scheme because it makes it pretty explicit what's happening. Other people use more descriptive mapping URI components, like:

    /auth ==> 10100
    /products ==> 10101
    /users ==> 10102

    ... etc.

    You obviously need to regenerate all your URLs. There is no way to switch to using a single IP without regenerating your URLs. But the end result is much more flexible, and frankly, it's the way everybody does it. When your site becomes busy enough to warrant expanding onto >1 server ( say your products service is getting hammered ), then you just deploy the service on another host, and update your proxy rules to know about the new location to map to ... ie you don't need to rewrite any end-user-facing URLs to make backend changes.

    There are lots of proxies. nginx is popular, fast, often used for this kind of thing, and does https termination. haproxy would be another option.
    You are proposing to "regenerate" anandtech.com and phoronix.com into anandronix.com/tech and anandronix.com/phoro! It is possible in theory, but unlikely to happen in practice.

    Leave a comment:


  • dkasak
    replied
    Originally posted by atomsymbol View Post

    How are you proposing to enable both "wget http://100.100.100.100:80/index.html" and "wget http://200.200.200.200:80/index.html" if you allocate only a single public IP address?
    OK, OK. Once more ...

    So firstly, you come up with some mapping scheme. Here's one example. Let's say the 1st part of the URI will be something for your proxy to consume and act on, and that by convention, it will start wtih a 'p_' ( which I'll nominate as meaning 'proxy hint' ). The next part will be a port offset ... and let's say the backend port numbers start at 10000. So, for example:

    p_100 will mean "proxy this request to port 10100 ( ie 10000 - our base port, plus 100, which is our offset ).
    p_200 will mean "proxy this request to port 10100 ( ie 10000 - our base port, plus 200, which is our offset ).

    ---

    So http://100.100.100.100:80/index.html you'd expose externally as:
    http://100.100.100.100:80/p_100/index.html
    ... and the service which used to listen on 100.100.100.100:80 would be running on 100.100.100.100:10100

    Another way of expressing this is:
    /p_100 ==> 127.0.0.1:10100, or:
    /p_100 ==> 100.100.100.100:10100

    Then http://200.200.200.200:80/index.html you'd expose externally as:
    http://100.100.100.100:80/p_200/index.html
    ... and the service which used to listen on 200.200.200.200:80 would be running on 100.100.100.100:10200

    Another way of expressing this is:
    /p_200 ==> 127.0.0.1:10200, or:
    /p_200 ==> 100.100.100.100:10200

    ---

    The proxy could modify the URI on the way through ( eg strip out the proxy hint ... which you might do in a regular expression ... eg:
    s/\/p_[\d]*\//

    This would mean that the backend services wouldn't have to be altered to know about the leading proxy hint in the incoming requests.

    ---

    This is but 1 mapping scheme. You can come up with your own. I used numbers in the mapping scheme because it makes it pretty explicit what's happening. Other people use more descriptive mapping URI components, like:

    /auth ==> 10100
    /products ==> 10101
    /users ==> 10102

    ... etc.

    You obviously need to regenerate all your URLs. There is no way to switch to using a single IP without regenerating your URLs. But the end result is much more flexible, and frankly, it's the way everybody does it. When your site becomes busy enough to warrant expanding onto >1 server ( say your products service is getting hammered ), then you just deploy the service on another host, and update your proxy rules to know about the new location to map to ... ie you don't need to rewrite any end-user-facing URLs to make backend changes.

    There are lots of proxies. nginx is popular, fast, often used for this kind of thing, and does https termination. haproxy would be another option.

    Leave a comment:


  • Scellow
    replied
    I've been using scaleway for more than 1 year, and i'm impressed, price, performance, quality, everything is there

    And Unlimited bandwidth !!!!!! what else do you need ?

    Leave a comment:


  • atomsymbol
    replied
    Originally posted by dkasak View Post
    As a couple of us have noted, the standard approach is to map different URL paths to different ports, thereby only requiring 1 IP address.
    How are you proposing to enable both "wget http://100.100.100.100:80/index.html" and "wget http://200.200.200.200:80/index.html" if you allocate only a single public IP address?

    Leave a comment:


  • dkasak
    replied
    Originally posted by atomsymbol View Post

    IP addresses is are parameters.
    Sure, but you've locked in the requirement that there be a 1:1 relationship between 'services' and IP addresses, right? As a couple of us have noted, the standard approach is to map different URL paths to different ports, thereby only requiring 1 IP address. As you've discovered, having multiple IPs can cost you ...

    Leave a comment:


  • atomsymbol
    replied
    Originally posted by dkasak View Post
    Ah! Well if you've hard-coded the IP address thing into your design, then yeah, not much else will fit.
    IP addresses is are parameters.

    Leave a comment:

Working...
X