Ограничение частоты обновления / очистки кэша обновлений - PullRequest
Новая
       20

Ограничение частоты обновления / очистки кэша обновлений

0 голосов
/ 26 января 2012

У меня есть пользовательский интерфейс, который получает асинхронные уведомления от службы, которая предлагает ему перечитать информацию из базы данных. Асинхронные уведомления содержат первичный ключ, который можно использовать для получения измененной записи. Под нагрузкой я могу получать 10 или 15 уведомлений в секунду, но часто с дублированными идентификаторами. Примерно так: 

{u'callback': u'job.modify', u'job-id': 1090, u'timestamp': u'2012-01-26 09:50:04.766'}
{u'callback': u'job.modify', u'job-id': 1091, u'timestamp': u'2012-01-26 09:50:04.767'}
{u'callback': u'job.modify', u'job-id': 1090, u'timestamp': u'2012-01-26 09:50:04.780'}
{u'callback': u'job.modify', u'job-id': 1091, u'timestamp': u'2012-01-26 09:50:04.808'}
{u'callback': u'job.modify', u'job-id': 1090, u'timestamp': u'2012-01-26 09:50:04.812'}
{u'callback': u'job.modify', u'job-id': 1090, u'timestamp': u'2012-01-26 09:50:04.829'}
{u'callback': u'job.modify', u'job-id': 1088, u'timestamp': u'2012-01-26 09:50:04.831'}
{u'callback': u'job.modify', u'job-id': 1088, u'timestamp': u'2012-01-26 09:50:04.836'}
{u'callback': u'job.modify', u'job-id': 1091, u'timestamp': u'2012-01-26 09:50:04.846'}

Казалось бы, стоит пропустить несколько операций чтения из базы данных в подобных случаях. Я работаю с классом, поэтому я подумал о настройке некоторого интервала обновления. Это то, что я до сих пор: 

class myClass():
  def __init__(self):
    self.modified = set([])
    self.lastrefresh = datetime.datetime.now()
    self.refreshinterval = datetime.timedelta(milliseconds = 250)

  def onModify(self, data):
    self.modified.add(data['job-id'])
    if datetime.datetime.now() - self.lastrefresh < self.refreshinterval:
      return
    self.doModify()

  def doModify():
    ids = list(self.modified)
    self.lastrefresh = datetime.datetime.now()
    self.modified.clear()

Который работает (в основном), но потенциально может иметь несколько обновлений. Поскольку эти обновления принимаются асинхронно, я никогда не знаю, сколько и как часто они будут появляться. Все ожидающие обновления обрабатываются в следующем уведомлении, но если следующее уведомление не приходит своевременно, то идентификаторы сидят в измененном наборе намного дольше, чем желаемый интервал 250 мс. Любые предложения приветствуются.

1 Ответ

1 голос
/ 26 января 2012

Я думаю, что нашел способ заставить эту работу. Требует следующих модификаций для класса: 

class myClass():
  def __init__(self):
    self.modified = set([])
    self.lastrefresh = datetime.datetime.now()
    self.refreshinterval = datetime.timedelta(milliseconds = 250)

  def onModify(self, data):
    self.modified.add(data['job-id'])
    if datetime.datetime.now() - self.lastrefresh < self.refreshinterval:
      return
    self.doModify()

  def doModify():
    if not self.modified:
      return
    ids = list(self.modified)
    self.lastrefresh = datetime.datetime.now()
    self.modified.clear()
    wx.CallAfter(self.purgeModifies)

  def purgeModifies(self):
    wx.CallLater(250, self.doModify)

Это немного подозрительно для использования wx.CallAfter и немедленного вызова wx.CallLater, но onModify происходит в фоновом потоке, что означает, что wx.CallLater выдает ошибку подтверждения C ++. wx.CallAfter возвращает управление главному потоку, что позволяет wx.CallLater работать. Это дает мне «еще один запуск» для обработки любых ожидающих обновлений.

...