Questions About the JDBCJobStore
How do I improve the performance of JDBC-JobStore?
There are a few ways to speed up JDBC-JobStore, only one of which is very practical.
First, the obvious, but not-so-practical:
Buy a faster network between the machine that runs Quartz, and the machine that runs your RDBMS.
Buy a more powerful machine to run your database on.
Buy a different RDBMS.
Now for something simple, but effective: build indexes on the Quartz tables.
Most database systems automatically index the primary-key fields. Many will also index a foreign-key field. Make sure yours does this, or make the indexes on all key fields of every table manually.
Next, manually add some additional indexes to the Quartz tables. Most important to index are the TRIGGER table's "next_fire_time" and "state" fields. Last (but not as important), add indexes to every column on the FIRED_TRIGGERS table.
create index idx_qrtz_t_next_fire_time on qrtz_triggers(NEXT_FIRE_TIME);
create index idx_qrtz_t_state on qrtz_triggers(TRIGGER_STATE);
create index idx_qrtz_t_nf_st on qrtz_triggers(TRIGGER_STATE,NEXT_FIRE_TIME);
create index idx_qrtz_ft_trig_name on qrtz_fired_triggers(TRIGGER_NAME);
create index idx_qrtz_ft_trig_group on qrtz_fired_triggers(TRIGGER_GROUP);
create index idx_qrtz_ft_trig_name on qrtz_fired_triggers(TRIGGER_NAME);
create index idx_qrtz_ft_trig_n_g on \
qrtz_fired_triggers(TRIGGER_NAME,TRIGGER_GROUP);
create index idx_qrtz_ft_trig_inst_name on qrtz_fired_triggers(INSTANCE_NAME);
create index idx_qrtz_ft_job_name on qrtz_fired_triggers(JOB_NAME);
create index idx_qrtz_ft_job_group on qrtz_fired_triggers(JOB_GROUP);
create index idx_qrtz_t_next_fire_time_misfire on \
qrtz_triggers(MISFIRE_INSTR,NEXT_FIRE_TIME);
create index idx_qrtz_t_nf_st_misfire on \
qrtz_triggers(MISFIRE_INSTR,NEXT_FIRE_TIME,TRIGGER_STATE);
create index idx_qrtz_t_nf_st_misfire_grp on \
qrtz_triggers(MISFIRE_INSTR,NEXT_FIRE_TIME,TRIGGER_GROUP,TRIGGER_STATE);
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 (1 second) jobs, consider partitioning the set of jobs by using multiple distinct schedulers (and hence multiple sets of tables, with distinct prefixes). Using one scheduler forces the use of a cluster-wide lock, a pattern that degrades performance as you add more clients.
My DB Connections do not recover properly if the database server is restarted.
If you're having Quartz create the connection DataSource (by specifying the connection parameters in the quartz properties file) make sure you have a connection validation query specified, such as:
org.quartz.dataSource.myDS.validationQuery=select 0 from dual
This particular query is extremely efficient for Oracle. For other databases, you'll need to think of an efficient query that always works as long as the connection is good.
If you're DataSource is managed by your application server, make sure the DataSource is configured in such a way that it can detect failed connections.
|
Feedback