<div dir="ltr"><div dir="ltr">Robert Engels <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> ezt írta (időpont: 2023. aug. 6., V, 23:16):<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">That is not the way you would configure the db - that leaves you open to east DDoS attacks. Relying on well behaved/configured apps is the wrong way - you prevent/balance this at the database. </div><div dir="ltr"><br></div><div dir="ltr">The reason you wouldn’t add it is like all resources like this - you are trying to control it at the wrong location. </div><div dir="ltr"><br></div><div dir="ltr">Controlling the number of concurrent threads to control the number of requests to a resource is simply wrong. You do it at a lower level (semaphore, etc) or in the resource itself. </div></div></blockquote><div><br></div><div>You have to put limitations on both sides. Just because the external service (such as the DB) protects itself from ddos (accidental or not) doesn't mean that applications don't have to be well behaved and limit the pressure they put on the service. In fact - in a lot of cases - the protection you are talking about is that the service will just outright ban your IP (in less severe cases, it will just return a failure which will be a lot more awkward to handle than if you made your app well-behaved). This is something you have to avoid at app level.</div></div></div>