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
Some datanommer queries are too long to be practical, for example querying the number of messages with topic org.fedoraproject.prod.buildsys.build.state.change for user foobar in the entire datanommer DB takes about 2 minutes. It's unrealistic to run this on each incoming buildsys.state.change message. As a result, fedbadges is unable to cope with the amount of messages coming in.
I think fedbadges (or maybe datanommer.models) should develop a form of cached values. Fedbadges could cache the number of messages with a given topic and a given username, and this would go a looong way to make it faster. It would increase this number when a message comes in, and optionally rebuild the cache periodically. This cache could be stored in a Redis or memcached instance (in the same Openshift project or shared).
The text was updated successfully, but these errors were encountered:
Some datanommer queries are too long to be practical, for example querying the number of messages with topic
org.fedoraproject.prod.buildsys.build.state.change
for user foobar in the entire datanommer DB takes about 2 minutes. It's unrealistic to run this on each incomingbuildsys.state.change
message. As a result, fedbadges is unable to cope with the amount of messages coming in.I think fedbadges (or maybe datanommer.models) should develop a form of cached values. Fedbadges could cache the number of messages with a given topic and a given username, and this would go a looong way to make it faster. It would increase this number when a message comes in, and optionally rebuild the cache periodically. This cache could be stored in a Redis or memcached instance (in the same Openshift project or shared).
The text was updated successfully, but these errors were encountered: