3.4 Quartz可以运行多少任务？
看它依赖于什么环境。
首先，JobStore对性能有重要的影响.基于RAM的JobStore要比基于JDBC的JobStore快的多。基于JDBC的JobStore的速度几乎完全取决于对数据库连接的速度，以及使用的数据系统以及数据库运行的硬件。Quartz本身实际上只做很少的处理，差不多所有的时间都花费在数据库上。当然，RAMJobStore对于有多少“任务”或者“触发器”可以存储是有数量限制的，因为，内存的数量要比数据库的硬盘空间小的多。
因此，对于Quartz能存储和监控的触发器和任务的数量限制因素时间上是JobStore有多少可用的存储空间的数量。（内存数量或者是硬盘数量）。
能够使Quartz本身运行变慢的就是使用大量的监听器（TriggerListeners, JobListeners, 和 SchedulerListeners），除了任务本身实际的运行时间外，花费在每个监听器上的时间会直接记入“处理”任务的执行时间上。这不意味着因此而害怕使用监听器，而是说要明智地使用监听器。如果能够使用特定的监听器就不要创建大量“全局”监听器，也不要使用监听器作“耗时”的工作，除非必须做。
同时能够运行多少个任务受限于线程池的大小。如果池中有5个线程，则同时可运行的任务不超过5个。使用大量线程时要小心，因为JVM,操作系统和CPU处理大量线程时很耗时，并且，线程管理也会导致性能下降。在多数情况下，性能开始下降是因为使用多达数百个线程。如果在应用服务器中运行程序，要留心应用服务器本身已经创建了不少的线程。
除了这些因素外，还同要执行的任务有关，如果任务需要花费很长时间才能完成它们的工作，并且（或者）它们的工作很消耗CPU,那么很明显不要同时运行多个任务，也不要在一个时间段内运行过多这样的任务。
3.5 Job Scheduling（任务日程安排）
任务在给定的触发器（Trigger）触发时执行。触发器可以通过几乎以下所有形式的组合方式进行创建：
在一天中的任意时刻（可以精确到毫秒）。
一周中特定的一些天。
一个月中特定的一些天。
一年中特定的一些天
不在日历列表中注册的一些天（比如节假日）。
循环特定的次数
循环到特定的时间。
无限循环
按照一定的时间间隔循环。
任务需给定名字，可以加入到给定名称的任务组中。为了简化触发器在日程中的管理，触发器也可以被给定名字和分组。任务只能加入到日程中一次，但是可以为其注册多个触发器。在J2EE环境中，任务可以作为分布(XA)事务的一部分执行。