Using trickle to slow down browser

If it was a DDoS attack you would seem many such connections from multiple locations. You don't give any stats in your question so we can not really judge.

If many of the slow requests are coming from the same location, especially if they are for a large object, it could be that you have people opening many many connections using a download manager.

If you are not locked into Apache for specific reasons you could consider a move to a server that is based on an event driven architecture rather than a threat/process based one, such as nginx. These allow the number of concurrent connections to scale much more efficiently as each basic request requires very little by way of extra resource (particularly RAM) - though the scalability on requests for scripted resources can vary a lot depending on your setup, getting the efficiency of modPHP (unless you already run it in (faast)CGI mode) can be more work to setup for instance, and of course you might be using other modules/features not well supported away from Apache.

You could also just allocate more RAM and increase the maximum number of Apache processes/threads.

A mid-way between those two solutions is that if the slow requests are for static resources you could use light-weight web server to serve the static content (in much less RAM than Apache would) and proxy the scripted requests (and other the require the extra features other than just serving a file) to Apache's setup. Many large heavily loaded sites operate in a similar manner to this.

Off the top of my head I do not know of a method that limits the amount of time a single request can take - this would probably not solve your problem anyway because in both a DoS situation or in the case of download managers a new connection will immediately be attempted.

This solution requires at least haproxy 1.6.

First, add the following to the frontend:

http-request set-header X-DOS-Protect %[src];%[req.fhdr(host)]%[capture.req.uri]

Then, add the following to the backend:

stick-table type integer size 1m expire 5m store http_req_rate(5m)
tcp-request inspect-delay 5s
tcp-request content track-sc0 req.fhdr(X-DOS-Protect),crc32(1) if HTTP
http-request tarpit if { sc0_http_req_rate gt 3000 }

I was not able to find a way to do the tracking in the frontend as I didn't find a way to apply a converter on that concatenated string that makes up the X-DOS-Protect header.

I am applying the hash function in order to make sure that you don't store a huge string in the stick-table as it could easily lead to a denial of service. If you think that this hash function is not suitable for you due to too many possible collisions, you could also make it bigger by applying crc32 to each of the concatenated components (and, of course, removing it when storing the data and switching to a bigger stick-table storage), like this:

http-request set-header X-DOS-Protect %[src,crc32(1)];%[req.fhdr(host),crc32(1)]%[capture.req.uri,crc32(1)]

stick-table type string len 30 size 1m expire 5m store http_req_rate(5m)
tcp-request inspect-delay 5s
tcp-request content track-sc0 req.fhdr(X-DOS-Protect) if HTTP
http-request tarpit if { sc0_http_req_rate gt 3000 }

Please note that this last solution will use more than 7 times more memory than the first one, for each entry in the stick table. Of course, the collision risk would be way smaller too.