The ChannelBroker.count_active_contacts/1 method makes a SUM() query to the SQL database. Aggregates are usually slow in SQL databases, and we make a lot of these calls: one before each attempt to queue a new contact, in order to know whether we're under or over capacity.
This may not be a problem with a single survey (there are indexes and it should avoid a sequence scan), but it may become one with multiple large surveys running in parallel.
A potential solution could be to add a counter in ChannelBrokerState for the number of active contacts, and mutate it as we activate / increment / decrement / deactivate / reenqueue / ... instead of counting all the time. We'd only count from the database on init/1 (the complexity lies in making sure the count is always correct).
The
ChannelBroker.count_active_contacts/1method makes aSUM()query to the SQL database. Aggregates are usually slow in SQL databases, and we make a lot of these calls: one before each attempt to queue a new contact, in order to know whether we're under or over capacity.This may not be a problem with a single survey (there are indexes and it should avoid a sequence scan), but it may become one with multiple large surveys running in parallel.
A potential solution could be to add a counter in ChannelBrokerState for the number of active contacts, and mutate it as we activate / increment / decrement / deactivate / reenqueue / ... instead of counting all the time. We'd only count from the database on
init/1(the complexity lies in making sure the count is always correct).See https://github.com/instedd/surveda/pull/2297/files#r1308375626