We have a fairly-complicated routine that draws pictures on a web site. Trouble is, sometimes we get a hundred requests for pictures within one second's time, such that all of the Apache workers are now drawing pictures and no other requests will be serviced.

I need a simple solution (been looking at mod_qos) which works on Apache 2.4.18 with mpm_event ... and that will work on all browsers.

If too many requests are being sent at the same time for this particular URL, we need to send back a response that will cause the browser to try again in a few seconds ... on its own.

It would be even nicer if we had something that could "cherry pick" the requests in Apache's queue so that some requests could simply wait-a-bit.

This is an o-l-d straight CGI application.

Don't know about apache, but nginx has something called HttpLimitReq that can be used to delay requests. You can use it to delay specific (cherry pick) ones once exceeded a certain limit
Some explanation

While I am certainly not opposed to using Nginix, my particular concern has nothing at all to do with "load balancing" or "attack prevention." Rather, in my dream-of-dreams, I would have a module (compatible with mpm_prefork) which could sift through the queue of requests, divide it into "lanes" e.g. by regular expressions, and impose more-intelligent queueing protocols on the request-selection process.

For example, "only so many requests in this 'lane' may be active at one instant."

I even picked out a name for it: mod_fastlane. But I have neither the time nor the expertise to write it.

is there some error on apache log?
you can upload the apache log.
so wo can check the log to solve the question

@OP
Perhaps you can use mod_security like this example.

Regards

Actually, it seems to me now that we need to shift some of this workload to an external job/work-queueing mechanism, such that the Apache workers no longer do the work, but instead queue it to a much-smarter workload management process, then (somehow ...) wait for a response.

Even the most-brief Internet search confirms that a plethora of such systems exist ... with suitably-cute names: "RabbitMQ," "Celery," and so on. (As, of course, I anticipated ...)

Who dat?

https://www.varnish-cache.org/ ?

No, what we truly need (and for a variety of things related to this system) is a true workload-management / background-job system that can be installed and run as a Ubuntu (LTS) service using an Ubuntu package.

By now we know more-or-less exactly what requests are "the bugaboo," and we know that our system is being flooded ... legitimately and in the normal course of web-site operations(!) ... with more concurrent requests "of a particular kind" than it can actually serve.

But, we've also got things ... related to the same system ... that truly are "batch jobs." And some of these have resource-availability-related queueing requirements such as what a "batch job" system would handle. At the same time we've got very fast, "FastCGI-like" requests that might arrive many hundreds or thousands per second. We need a solution that can do it all.

(Note: this is an "ancient, huge, troublesome and cantankerous ... but very profitable(!) ... 'straight-CGI' application" that runs quite well under mpm_event, and it always will be.)

I also need to know if and how it is possible for HTTP to "push" a request to a particular connected user. In other words, is it possible for the HTTP worker, having dispatched the request, to go off and do other things ... and for the web browser also to go off and do other things ... until the web browser is notified by some message that is pushed to it that the requested data is now available?

Or, since many of the pieces of data that are being generated in this way are images, can we somehow seamlessly insert an offline request processing stage into this process, without client-side JavaScript polling? And, without tying-up an HTTPD worker process for the duration? (Assume mpm_event).)

References to existing web-pages (and LQ posts!) that talk about similar scenarios and that describe (non-commercial) solutions are ... requested!