This is a tough question to answer, because the is basically "it depends."

First off, the JobStore that you use plays a significant factor. The RAM-based JobStore is MUCH (1000x) faster than the JDBC-based JobStore. The speed of JDBC-JobStore depends almost entirely on the speed of the connection to your database, which data base system that you use, and what hardware the database is running on. Quartz actually does very little processing itself, nearly all of the time is spent in the database. Of course RAMJobStore has a more finite limit on how many jobs and triggers can be stored, as you are sure to have less RAM than hard-drive space for a database. You may also look at the FAQ How do I improve the performance of JDBC-JobStore? .

So, the limiting factor of the number of triggers and jobs that Quartz can store and monitor is really the amount of storage space available to the JobStore (either the amount of RAM or the amount of disk space).

Now, aside from "how many can I store?" is the question of "how many jobs can Quartz be running at the same moment in time?"

One thing that can slow down Quartz itself is using a lot of listeners (TriggerListeners, JobListeners, and SchedulerListeners). The time spent in each listener obviously adds into the time spent "processing" a job's execution, outside of actual execution of the job. This does not mean you avoid using listeners, it just means that you should use them judiciously. Do not create "global" listeners if you can make more specialized ones. Also do not perform "expensive" things in the listeners unless you really need to. Also be mindful that many plug-ins (such as the history plugin) are actually listeners.

The actual number of jobs that can be running at any moment in time is limited by the size of the thread pool. If there are five threads in the pool, no more than five jobs can run at a time. Be careful of creating a lot of threads though, as the JVM, the operating system, and the CPU all have a hard time juggling lots of threads. Performance degrades as the system spends time managing threads. In most cases, performance plunges when you get into the several hundreds of threads (or fewer if the code being executed on the threads is intensive). Be mindful that if you are running within an application server, it probably has several dozen threads of its own.

Aside from those factors, it really comes down to what your jobs do. If your jobs take a long time to complete their work or are very CPU-intensive, you should obviously not run very many jobs at once, nor very many in a given span of time.

Finally, if you cannot get enough horse-power out of one Quartz instance, you can always load-balance many Quartz instances on separate machines. Each instance will run the jobs out of a shared database on a first-come, first-serve basis, as quickly as the triggers fire.

The clustering feature works best for scaling out long-running and/or CPU-intensive jobs (distributing the work-load over multiple nodes). If you need to scale out to support thousands of short-running (e.g, 1 second) jobs, consider partitioning the set of jobs by using multiple distinct schedulers. Using one scheduler forces the use of a cluster-wide lock, which is a pattern that degrades performance as you add more clients.

So it is difficult to specifically answer the question of "how many." However, there are installments of Quartz that are managing hundreds-of-thousands of jobs and triggers, and are, at any given moment executing several dozens of jobs without even utilizing Quartz load-balancing capabilities. With this in mind, users should feel confident that they can get the performance out of Quartz that they need.

RMI can be a problematic, especially if you do not have an understanding of how class loading via RMI works. You can familiarize yourself with RMI by reading all of the Javadoc about RMI. You can also review the following references, which were provided by Quartz user, Mike Curwen,

For a description of RMI and codebase, see: http://www.kedwards.com/jini/codebase.html. One of the important points is to realize is that codebase is used by the client.

For an overview of security managers, see: http://gethelp.devx.com/techtips/java_pro/10MinuteSolutions/10min0500.asp.

Finally, the important 'take away' of the Java API is that the RMI class loader will not download any classes from remote locations if no security manager has been set.