How many concurrent users can a Resin server handle?

This is not a question that can be answered in a general way. It is very dependent on the particular application that Resin is used for. Factors such as database usage, how the session object is used, the use of server side caching, and application architecture in general have a significant effect on the capabilities of a website.

The best (and only practical) way to answer this question is to perform some benchmarking tests for your particular application on a server similar to the one that will host the website. The freely available httperf tool, as well as various others, are useful for this purpose.

When using testing tools, 500 "concurrent threads" does not mean the same thing as "500 concurrent users". A typical user is not constantly making requests to the server. Typical usage involves a request for a page (with possible subsequent requests for images), and then a period of inactivity as the user reads or watches the content that has been downloaded.

The ratio of number of users to number of threads again depends on the application involved. For example, it may be that the ratio for an application is 50:1, meaning that 2500 users will use at maximum 250 threads on the server.

Ideally, application benchmarks use "user scenario" scripts. The script imitates what a typical user wil do, including pauses between requests. This kind of script is useful for providing an accurate picture of web server usage.

The primary configuration item in Resin for handling a greater load is thread-max. The default in resin.conf can be adjusted upwards to handle increased load, the limit is determined by the underlying operating system.

If anticipated load overruns a Resin server, either with CPU usage or with encountering OS thread limitations, clustering can be used to add another server to share the load.

Does Resin use NIO for improved performance?

Resin does not use NIO - it uses JNI to handle low-level I/O calls with native code. The performance using this method was found to be much better than nio.

How does Resin use JNI?

The JNI code is compiled on the various Unix systems when the ./configure; make; make install step is performed during installation. Windows has precompiled dlls.

Resin uses JNI in certain critical performance areas, such as low level socket connections and file operations. JNI is also used to interface with the OpenSSL libraries.

A significant benefit in particular is in Resin's ability to handle keepalive's. With JNI, Resin does not need a thread for each keepalive connection. The low-level poll() (or select() if poll() is not available) functions are used. The end result is the possibility of many more keepalive's than if a thread was needed for each keepalive.

The fallback if JNI is not available is to use the JDK equivalents of the faster JNI calls. Also, OpenSSL is only available through JNI.

Resin indicates that JNI is being used with a log message at startup:

Loaded Socket JNI library.

If JNI is not available, the log message is:

Socket JNI library is not available.