traeak edited a comment on issue #7179: URL: https://github.com/apache/trafficserver/issues/7179#issuecomment-692186676
By default with an uncached asset ATS actually does internally throttle. However when ATS discovers that the data is already cached in RAM it decides to "optimize": ignore throttling and stack all those in order memory blocks up in the send to client queue. This is what I found during testing and why I added the throttling. We've been using the slice in production for more than a year without throttling turned on using servers with 128GB+ ram without throttling. However our servers push a lot of traffic with hundreds of remap rules so the slices that are cached in RAM are quickly evicted from ram cache and don't stack up like what you are seeing. I added this throttling later when observing the ram cache behavior during synthetic testing. I'm actually surprised that the slice throttling isn't working well enough. I believe ats deals internally with 32kb chunks, throttling at that level. The slice plugin throttles at the slice block size, (1MB by default). Perhaps with enough assets pushing through that 1MB vs 32kb might add up. _It's not difficult to make that throttle size configurable so that it could be set to 32kb or more. I'd have to start looking at more of the TSIOBuffer handling in the rest of the buffer handoff stack to see what could be done there. Maybe a more correct solution would be to change (try to configure or add an option) ATS so that it doesn't do the smart optimization and stack up all those sequential ram cache hit blocks (TCP_MEM_HIT)._ <-- This has no effect, the way the cache works throttling only works at the segment level. If throttling is working correctly the segments won't load in advance, generally one segment and perhaps 2 segments ahead will be loaded (I could add a tweak there to make the 2 segments more rare but the gain will be minimal). ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
