3 ms·

There are several red flags here, not the least of which is that a CDN isn't just about bandwidth, it is about disk. If a cache node doesn't have the object, it

There are several red flags here, not the least of which is that a CDN isn't just about bandwidth, it is about disk. If a cache node doesn't have the object, it has to go to origin to get it. That has a cost at origin, which most CDN customers want to minimize. Cache management (eviction, invalidation, etc) is done where? By the look of that diagram, you are actually doubling your origin traffic just to push to the cache after serving the original client request. Perhaps subsequent requests could get served from their 'peer' but the hit rate will be abysmal. Maybe there is more to it than they describe here, but I don't see how this can work. Are they going to rewrite the object in a way that doesn't require the host certificate?

mranton 4y ago
>a CDN isn't just about bandwidth, it is about _disk_ The disk performance - is the weakest part of the Peer. It is a part you can't guarantee any QoS on a cheap server. The idea is to keep popular cache on Peers in memory. Everything else we will host from a limited number of regular servers (belong to Farba), with high-performance disk subsystem. >Cache management (eviction, invalidation, etc) is done where? yes. You can invalidate either a single URL or a folder with a wildcard >you are actually doubling your origin traffic just to push to the cache after serving the original client request this is something we can proxy and do only one request per file. Current implementation was done for simplicity and reliability. >but I don't see how this can work. Are they going to rewrite the object in a way that doesn't require the host certificate? you can easily check this up. Please open the network console on our demo-page and see how it works: - we have two different certificates (one for the main site, for for the Peer) - everything works flawlessly
- uncertainrhymes 4y ago
  Your example servers have 16-32 GB of memory, which is basically nothing. If you ever ramp to real world traffic the peer will be constantly evicting objects (if you use a normal LRU). Even if you backstop that with a mid-tier belonging to Farba to protect the origin, what kind of cache hit rate are you expecting at the peer?
  - mranton 4y ago
    >Your example servers have 16-32 GB of memory, which is basically nothing we just need to add more Peers and evenly distribute the workload. > what kind of cache hit rate are you expecting at the peer? I don't know. We have too many moving parts right now and can't predict anything.
    - bastawhiz 4y ago
      > we just need to add more Peers and evenly distribute the workload. That doesn't make sense! If you add more peers just to keep more files in memory, each peer is serving less and less data. There's a fixed, finite amount of usage that the system will receive, and the more peers you add, the more that usage gets subdivided among the peers. Which means they make less money, which makes the system unprofitable. Moreover, you're spending more money to distribute the file to more peers (well, you're not, you're offloading that to the customer right now), which means the more peers, the more expensive for you or the customer. The problem you have is that handling more files means cutting peer profits without adding any benefit for yourself or the peers. Storage isn't factored into pricing, which means that any accommodation you make to increase availability (an important part of being a CDN!), the worse the economics end up being.
- bastawhiz 4y ago
  > The disk performance - is the weakest part of the Peer. It is a part you can't guarantee any QoS on a cheap server. The idea is to keep popular cache on Peers in memory. Everything else we will host from a limited number of regular servers (belong to Farba), with high-performance disk subsystem. I use a CDN to serve about 50GB of files stored on my origin, which turn over every week or so (a new 50GB every week). What you're saying means that _at best_ I need at least 3-4 peers in order to keep one copy of all of my files available. That's your using your numbers for a LeaseWeb or OneProvider peer. And if I'm competing with other customers, my content is getting evicted, resulting in more hits to my origin. If I'm actually using your system as a CDN where peers should be physically close to my users, that means that I'm filling up RAM of lots and lots of peers just so that enough peers that are close to my users can serve the files.
  - mranton 4y ago
    for unpopular content, we will deploy a limited number of servers (belong to Farba) with a performant disk subsystem. A web cache storage is a separate option in every CDN: if you want your files always in "hot" cache, you have to pay extra.

mranton 4y ago

>a CDN isn't just about bandwidth, it is about _disk_ The disk performance - is the weakest part of the Peer. It is a part you can't guarantee any QoS on a cheap server. The idea is to keep popular cache on Peers in memory. Everything else we will host from a limited number of regular servers (belong to Farba), with high-performance disk subsystem. >Cache management (eviction, invalidation, etc) is done where? yes. You can invalidate either a single URL or a folder with a wildcard >you are actually doubling your origin traffic just to push to the cache after serving the original client request this is something we can proxy and do only one request per file. Current implementation was done for simplicity and reliability. >but I don't see how this can work. Are they going to rewrite the object in a way that doesn't require the host certificate? you can easily check this up. Please open the network console on our demo-page and see how it works: - we have two different certificates (one for the main site, for for the Peer) - everything works flawlessly

uncertainrhymes 4y ago
Your example servers have 16-32 GB of memory, which is basically nothing. If you ever ramp to real world traffic the peer will be constantly evicting objects (if you use a normal LRU). Even if you backstop that with a mid-tier belonging to Farba to protect the origin, what kind of cache hit rate are you expecting at the peer?
- mranton 4y ago
  >Your example servers have 16-32 GB of memory, which is basically nothing we just need to add more Peers and evenly distribute the workload. > what kind of cache hit rate are you expecting at the peer? I don't know. We have too many moving parts right now and can't predict anything.
  - bastawhiz 4y ago
    > we just need to add more Peers and evenly distribute the workload. That doesn't make sense! If you add more peers just to keep more files in memory, each peer is serving less and less data. There's a fixed, finite amount of usage that the system will receive, and the more peers you add, the more that usage gets subdivided among the peers. Which means they make less money, which makes the system unprofitable. Moreover, you're spending more money to distribute the file to more peers (well, you're not, you're offloading that to the customer right now), which means the more peers, the more expensive for you or the customer. The problem you have is that handling more files means cutting peer profits without adding any benefit for yourself or the peers. Storage isn't factored into pricing, which means that any accommodation you make to increase availability (an important part of being a CDN!), the worse the economics end up being.
bastawhiz 4y ago
> The disk performance - is the weakest part of the Peer. It is a part you can't guarantee any QoS on a cheap server. The idea is to keep popular cache on Peers in memory. Everything else we will host from a limited number of regular servers (belong to Farba), with high-performance disk subsystem. I use a CDN to serve about 50GB of files stored on my origin, which turn over every week or so (a new 50GB every week). What you're saying means that _at best_ I need at least 3-4 peers in order to keep one copy of all of my files available. That's your using your numbers for a LeaseWeb or OneProvider peer. And if I'm competing with other customers, my content is getting evicted, resulting in more hits to my origin. If I'm actually using your system as a CDN where peers should be physically close to my users, that means that I'm filling up RAM of lots and lots of peers just so that enough peers that are close to my users can serve the files.
- mranton 4y ago
  for unpopular content, we will deploy a limited number of servers (belong to Farba) with a performant disk subsystem. A web cache storage is a separate option in every CDN: if you want your files always in "hot" cache, you have to pay extra.