Because JVM threads are expensive to create, the jetty web server that is used in Mendix to listen on the HTTP ports keeps a thread pool of inactive threads which can be used to handle HTTP requests arriving from the outside on e.g. requests from the web browser and web service requests.

The runtime-max-threads limits the amount of simultaneous requests the application can be processing. The runtime-min-threads ensures there will always be a number of threads available for new requests when there are currently no active threads.

Requests that cannot immediately be handled because there's no available free thread and the active number of threads is already equal to runtime-max-threads are queued and processed when a thread is available. That means the max value can also be used for throttling the amount of concurrent requests that enter the mendix runtime.

Monitoring thread usage, so you know the normal behaviour of your application is the best way to getting know the best values for these options in your specific situation. Setting the value too high will allow a run-away script or user to crash your application by issuing lots of simultaneous requests, setting it too low can cause request 'starvation' on busy applications.

To give an idea of the amount of threads you need, one of the documentation pages about monitoring has some examples of a medium-busy application with a few hundred users logged in, which shows an average active thread number of 1.4. :-)