Sorry, couldn't resist to that message subject
I'm working on some performance improvements for my application and there is something I think is missing in Rails (as well as most other frameworks) that I'd like to discuss here.
For this application, the user can select multiple filters when querying a generic database. It is a live interface (like Google, for instance), so whenever the user selects a new filter the results are automatically updated. The request takes about 1s to deliver each search results but it can take more on complex queries.
But the problem is that usually when setting filters it may happen that the user will cancel the last request if it hasn't finished yet upon insertion of a new filter.
This is a problem because Rails doesn't provide any facilities for web servers that will inform you about that (the http connection close event). Ideally, I'd like to be able to set up this Rails application to behave this way (assuming my application is deployed as multi-thread with Puma, for instance):
- when a connection has been closed (user canceled the request or network was down, etc):
- if the route matches certain rules:
- kill that thread created to handle that connection
This would kill the PostgreSQL connection process for instance as any further Ruby processing happening on that thread.
If I could do that I would be able to handle more requests using the same resources as before.
Another useful feature to have built into Rails would be introducing some monitoring settings. For instance, if any thread handling certain route rules takes more than 3s the application could be able to handle that case. The application would be able to decide among those actions, for instance:
- kill the thread and render some response and status
- log the incident
- gracefully cancel the database request if this is possible or gracefully interrupt some processing in place
Please let me know if the description above is not quite clear.