By default, and it can't be changed, the SQL and File rules are run/processed one-at-a-time.
So, if you have for example, a SQL rule that triggers a batch/XML that runs for one hour, no additional SQL rules will process until that batch is complete.
What-the-heck? I know, right. Well, this is by design to ensure a previously triggered event does not "step on" a later event. In a perfect world, you could add dependencies to rules like "make sure process X isn't running" or "make sure process X runs first". This just adds to the complexity of running and watching SQL and File rules, and we're trying to keep Event Server's "decision making" as simple as possible (or no more complex than it already is).
So, what's the workaround to trigger multiple SQL and File rules and processes at once? Use a "dummy" Superbatch that runs immediately and triggers a longer running "real" batch.
---
What's a SuperBatch?
https://help.reportrunner.com/knowledgebase/article/whats-a-superbatch
---
What's a "dummy" SuperBatch?
The "dummy" refers to a job or batch that's not really outputting any real work. In the System Reports that we make available, there is a Batch Message Report. Follow these instructions to make a "dummy" SuperBatch.
You can test this batch manually, and you'll see it runs immediately, creates no output, and simulates the trigger of your next batch (a manually-run SuperBatch only displays what would trigger --- it does not actually trigger it until it's non-manually run).
TIP: If you want to be notified when this process triggers... simply convert the job in the "dummy" batch to send an email or an SMS message... and uncheck the option to cancel if zero records. That way, everytime this process triggers, you'll be notified, and it still runs really quick.
---
And lastly, just to finish explaining how this works with your SQL or File rules in speeding up rules and triggers...
Instead of triggering a long running batch directly from the SQL or File rules, you configure the rule to trigger THIS "dummy" batch, which triggers the actual long running batch. The benefit is THIS "dummy" batch runs immediately, the rule is finished immediately, and the next rule can process immediately. You would configure these "dummy" batches for any rules that trigger batches that run a long time. If you do this for all long running rule batches, you'll have zero delays, because all rules would then run within a second or two.