2

I have some servers that do a lot of file zipping operations. This also means that all the files have to be remotely downloaded first before being zipped and remotely uploaded, or remotely streamed to clients.
I have the option of either upgrading old servers or getting new ones.

The old server specs are about 3.1 GHz and bandwidth averaging 100 Mbps. The new server specs are about 2.4 GHz and the bandwidth guaranteed to be 1000 Mbps up to 2000 Mbps. Memory usage should remain the same or be reduced in the new iteration.

At this point, I have figured out my RAM and Disk usage. That is not an issue. The question leans on how CPU speeds and bandwidth affect streamed downloads.

Those are my options.
Which option is better for my use case?

Edwinner
  • 121
  • 1
  • 3
  • 1
    Does this answer your question? [Can you help me with my capacity planning?](https://serverfault.com/questions/384686/can-you-help-me-with-my-capacity-planning) – mfinni Jan 08 '21 at 17:46
  • Those are some good points. At this point, I have figured out my RAM and Disk usage. That is not an issue. The question leans on how CPU speeds and bandwidth affect streamed downloads. – Edwinner Jan 08 '21 at 18:19

2 Answers2

4

You should track CPU and bandwidth usage on your current servers when they are performing those "zipping operations".

If they use 100% CPU, go for faster CPUs; if they use 100% bandwidth, go for higher bandwidth.

Also, please note that newer CPUs can be a lot faster than older ones, regardless of nominal GHz values; the number of CPU cores is also relevant (assuming those "zipping operations" are multithreaded and/or run in parallel).

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • That is what they sold me on, your second part. I have tested regular zipping and my newer servers seem to be slightly faster. Not a big difference though. The reason for the upgrade is because of streaming speeds. I have yet to test that because I need both servers running the same code, which won't happen till later in the weekend. – Edwinner Jan 08 '21 at 18:09
  • @edwinnet how big are the files? as smaller as less needed is the compression and in fact for Germany the common bandwidth is around 50+ mbits so it wouldnt be a benefit to compress a alot – djdomi Jan 08 '21 at 20:06
  • @djdomi, yes my new iteration went light on the compression which 10X-100X the download speeds. Plus concurrency I am hoping to 100X the whole process. – Edwinner Jan 08 '21 at 20:23
  • Everything being equal, it looks like the new servers outperform the old servers despite the low CPU speed rating. it looks like a 2x gain and about 200X gain from old code implementation. – Edwinner Jan 09 '21 at 14:44
0

If you're going to find some "optimal" solution, you have to find out how much data can pass through your data busses, the optimal would be that the data arrives at some netcard, get read from the cpu and directly zipped to memory in a netcard.

Lets assume you got

  • 2 (so they don't get confused by sending and receiving) 10GB ethernet cards with each 8 lanes of PCI express 4 (15GB/s for each) assuming you can get a MB that supports this.
  • you invest in some CPU+MB that can actually support this, RyZen 5950X+x570

Then there is the memory throughput

  • the above system offers around 54GB/s read/write or 48GB/s copy
  • the ethernet drives might copy the received data to ram (via cache or not)
  • most likely you haven't yet had the benefit of zero-copy sending but more likely sending will cause 3-6 copies.
  • it is likely the same for receiving, but there the CPU has to read it at least once to zip it, if lucky directly in the cache, if not from memory, and the same when its zipped to cache, the NIC could copy it directly to its internal send buffer.

So best case, with the best NIC, user level drivers, always hit cache

  • copy from NIC to cache without writeback to RAM
  • zip from cache to cache
  • copy from cache to NIC
  • assuming 32 threads can feed it You could get 10 GB/s throughput

If you do not have access to this lucky scenario you are more likely to be memory bandwidth limited as

  • assumed 3 copies to move data to the application
  • 2 copies to load to zip and save result
  • 3 copies to send
  • and a lot of cache writebacks to bind it all in darkness

Assuming 7 reads and 7 writes writes the limit should be around 54GB/s / 14 = 3.85 GB/s in best case. With fewer read/writes you quickly run into the NIC max speed.

So from here you can cut down on specs until your budget or needs are met.

I have not been able to locate any data for in memory multithreaded zipping.

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
Surt
  • 101
  • 1