You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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/1
method 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
The text was updated successfully, but these errors were encountered: