Hi Luis,
First you should setup a monitoring system (if possible) to verify your instance CPU/RAM usage. Optimizations you do on ingestion services should have a visible impact on these hardware resources. Whatever optimization you will do, you need to be able to understand what are its results.
Ref 1: I remember, though not 100% sure, that if in the service that requests that process you raise a (custom) event instead of processing directly the payload, you'll get that logic executed via the Event Subsystem (which is configurable in terms of threads etc.). You can try to modify your logic to do things in this pattern.
Ref. 2: async is not necessary a performance improver, because at the end of the day that logic will still be done. It just allows you to dispatch the request without waiting for response. So, if you mark your service as async, you can also say goodbye to potential responses you might want to send to the originator of that request. One very important thing to remember is that async threads are spawned as needed, with no enforced maximum limit. You could have your system slowing down more and more due to some async threads which for some reason did not finish execution, etc. That's why the Event subsystem is more desirable, since you can control the max number of tasks.
Ref 3.Yes, that's in the sizing tests we do with various loads. More information here. Please remember, that, as we are a platform, we can not guarantee these numbers, since you will always provide custom code that we can not predict.
Ref 4. The number of HTTP requests we get in the platform is not monitored by the platform. However, you most probably need the number of executions of that specific service, which the platform will monitor if you enable the Utilization Subsystem. However, note that this subsystem tracks all service executions in the platform, and it is not advisable to let it run forever. Another option you have is to increment a counter (Property) in your thing, so that you have an idea of how many executions happened.
