7 ms·
"When I thought of a reasonable maximum number of attachments on an email I'd probably say 64." We should not be talking of a "reasonable" maximum at all. Rat
by jorangreef 7y ago
"When I thought of a reasonable maximum number of attachments on an email I'd probably say 64."
We should not be talking of a "reasonable" maximum at all.
Rather, the maximum should be orders of magnitude away from the "reasonable".
At this distance, any arbitrariness quickly fades into meaninglessness.
Detached from the "reasonable" usage, the maximum then becomes informed by processing cost and complexity analysis, which are more concrete.
- staticassertion 7y agoThis assumes (and likely correctly assumes, in most cases) that 'reasonable limit' and 'probable system limit' are orders of magnitude apart. I think that may not always be true though. Especially for highly variable workloads. How many requests per seconds does your site handle on average vs how many can it handle? What about spikes? If your previous peak is at 10 rps and you can probably handle 20 rps, when should you start dropping connections to keep the site up? Most systems are designed to have small margins, for cost purposes, so I imagine this sort of situation might come up quite a bit.
- machinecoffee 7y agoI would disagree, a sensible limit that cannot overwhelm the machine even if a multi threaded server is processing its maximum number of emails, should be enforced. The correct response to a breach of this limit would be for a reply email to explain the limit and why the email was rejected. The user then could send multiple emails with their attachments, and the system can be sized to handle e.g. 24 threads processing 64 attachments of a maximum size of e.g. 4096kb That's how you ensure a system sized to your hardware and ensure maximum throughput for all users.
- jorangreef 7y ago"That's how you ensure a system sized to your hardware and ensure maximum throughput for all users." Sure, I think we are actually in agreement. That's exactly what I meant by "processing cost and complexity analysis".