On Nov 8, 2013, at 2:07 AM, Igor Galić <i.ga...@brainsware.org> wrote:
> > >> holds the similar type of feature which will gel well with RAID 10 level. >> If not we will go ahead with RAID 0 to save more disk space for larger >> cache. Currently we have 300GB cache on each ATS nodes. > > Given that Yahoo has switched from using YTS to using ATS, it's > probably safe to say that they consider the performance to be, > at least, sufficient. The cache does not change between YTS and ATS in this regard. Use JBOD unless you have specific needs for e.g. RAID10; One such use case I can think of is when you have very, very large files, then JBOD is undesirable. > > https://trafficserver.readthedocs.org/en/latest/admin/configuring-cache.en.html > >> 2) How does ATS scales with respect to CPU , Memory, Disk? We have our > > CPU: when compiling with --enable-hwloc (highly recommended) much, > much better. Yes, our defaults are better than they used to be. You are still strongly encouraged to tune your settings according to your hardware and application. > > Memory: We've recently increased the RAM cache backing by an order > of magnitude. IIRC, that means that for your 300 G disk(s) ATS will > now use 3G RAM. Note that this is just a default. You can (and almost always should) tune this as per your HW and app specs. > > Disk: we spawn one thread for each disk spindle (all the more reason > to not use RAID and directly expose disks to ATS). Correction: 8 I/O threads / disk *by default*. If you use RAID, you should tune this accordingly as well. The optimal setting here also depends on the actual disk, so tune it. > >> current production running with YTS and 16GB ram. Will ATS scale its >> performance If I am getting 24GB ram ? How ATS will scale with respect to >> hardware. Can you please give some insight about it. > > > Generally we try to auto-scale with the underlying hardware. But > you can always make adjustments to fit your load and working set. +1. As for RAM, it’s used in three primary ways: 1) In-memory indices for the disk storage. The bigger the disk, the more memory. Look at proxy.config.cache.min_average_object_size. The math is (ballpark) 10 * (disk size / proxy.config.cache.min_average_object_size) This is allocated up front, and also gets synced to disk periodically; during sync time, more memory can be used for “snapshots”. 2) RAM cache as autoscaled or explicitly configured with proxy.config.cache.ram_cache.size. This is allocated as necessary (so you will see memory growth until it hit this cap). 3) Connections. SSL connections consumes more than regular ones. I haven’t kept up with exactly we are with this, it used to be 32KB / 64KB minimum for an inactive connection, and potentially much more for an active one (buffers). > >> 3) What is the QPS of current ATS? Depends on your application; i.e. impossible to tell, benchmark ATS vs Varnish vs Squid for your app. — leif
