Блог

ОБНОВЛЕНИЕ 14 июня 2011

Быстрое обновление… Большинство респондентов сосредоточились на хитроумном методе обработки очереди сообщений, подлежащих регистрации, однако, хотя там, безусловно, не хватает оптимизации, это, безусловно, не корень проблемы. Мы переключили выход в короткий режим ожидания (да, выход действительно привел к 100%-му процессору после того, как система перестала работать), однако система по-прежнему не может следить за протоколированием, даже когда он и близко не подходит к этому режиму сна. Из того, что я вижу, отправка просто не очень эффективна. Один респондент прокомментировал, что мы должны заблокировать Send () вместе в to one send, и это казалось бы наиболее подходящим решением более крупной базовой проблемы, и именно поэтому я пометил это как ответ на исходный вопрос. Я, конечно, согласен, что модель очереди очень несовершенна, поэтому спасибо за отзыв по этому поводу, и я поддержал все ответы, которые внесли свой вклад в обсуждение.

Однако это упражнение заставило нас пересмотреть, почему мы используем внешнее ведение журнала через сокет, как сейчас, и хотя это вполне могло иметь смысл ранее, когда сервер ведения журнала выполнял большую обработку записей журнала… он больше не выполняет ничего из этого, и поэтому мы решили удалить весь этот модуль и перейти к прямому доступу к файлу с помощью какой-либо ранее существовавшей платформы ведения журнала, это должно полностью устранить проблему, а также устранить ненужную сложность в системе.

Еще раз спасибо за все отзывы.

ОРИГИНАЛЬНЫЙ ВОПРОС

В нашей системе у нас есть два компонента, важных для решения этой проблемы — один разработан на Visual C , а другой на Java (не спрашивайте, исторические причины).

Компонент C является основной службой и генерирует записи в журнале. Эти записи журнала отправляются через CSocket::Send в службу ведения журнала Java.

Проблема

Производительность отправки данных кажется очень низкой. Если мы ставим в очередь на стороне C , то резервное копирование очереди постепенно увеличивается в более загруженных системах.

Если я попаду на сервер ведения журнала Java с помощью простого приложения на C #, я смогу запустить его намного быстрее, чем мне когда-либо понадобится, с помощью инструмента C , и это прекрасно работает.

В мире C функция, которая добавляет сообщения в очередь, является:

 void MyLogger::Log(const CStringamp; buffer)
{
    struct _timeb timebuffer;
    _ftime64_s( amp;timebuffer );

    CString message;
    message.Format("%dd,d,%srn", (int)timebuffer.time, (int)timebuffer.millitm, GetCurrentThreadId(), (LPCTSTR)buffer);

    CString* queuedMessage = new CString(message);
    sendMessageQueue.push(queuedMessage);
}
  

Функция, запускаемая в отдельном потоке, который отправляет в сокет, является:

 void MyLogger::ProcessQueue()
{
    CString* queuedMessage = NULL;
    while(!sendMessageQueue.try_pop(queuedMessage))
    {
        if (!running)
        {
            break;
        }
        Concurrency::Context::Yield();
    }

    if (queuedMessage == NULL)
    {
        return;
    }
    else
    {
        socket.Send((LPCTSTR)*queuedMessage, queuedMessage->GetLength());
        delete queuedMessage;
    }
}
  

Обратите внимание, что ProcessQueue многократно запускается самим потоком внешнего цикла, что исключает кучу бессмысленной преамбулы:

 while(parent->running)
{
    try
    {
        logger->ProcessQueue();
    }
    catch(...)
    {
    }
}
  

Очередь:

 Concurrency::concurrent_queue<CString*> sendMessageQueue;
  

Итак, эффект, который мы наблюдаем, заключается в том, что очередь становится все больше и больше, записи журнала отправляются в сокет, но с гораздо меньшей скоростью, чем они поступают.

Является ли это ограничением CSocket:: Send, которое делает его менее полезным для нас? Неправильное его использование? Или это отвлекающий маневр, и проблема кроется в другом?

Я очень ценю ваш совет.

С уважением

Мэтт Педдлсден

Что ж, вы могли бы начать с использования блокирующей очереди производитель-потребитель и избавиться от «Выхода». Я не удивлен, что сообщения блокируются — когда одно из них публикуется, поток регистратора обычно находится в загруженной системе, готов, но не запущен. Это приведет к значительной задержке, которой можно избежать, прежде чем любое сообщение в очереди сможет быть обработано. Фоновый поток than имеет возможность попытаться избавиться от всех сообщений, которые накопились в очереди. Если в загруженной системе много готовых потоков, вполне может быть, что потоку просто не хватает времени для обработки сообщений. особенно, если много накопилось и в розетке.отправляйте блоки.

Кроме того, почти полная трата одного ядра процессора на опрос очереди не может быть хорошей для общей производительности.

Rgds, Мартин

На мой взгляд, вы определенно смотрите не на самое эффективное решение. Вам обязательно следует вызвать Send() один раз. Для всех сообщений. Объедините все сообщения в очереди на стороне пользователя, отправьте их все сразу с помощью Send(), затем выдайте.

Кроме того, на самом деле это не так, как вы должны это делать. PPL содержит конструкции, явно предназначенные для асинхронных обратных вызовов — например, call object . Вы должны использовать это вместо того, чтобы сворачивать вручную самостоятельно.

Здесь есть вещи, которые могут замедлить вас:

• Используемая вами очередь.Я думаю, что это классический пример преждевременной оптимизации. Здесь нет причин использовать класс Concurrency::concurrent_queue, а не обычную очередь сообщений с блокирующим методом pop(). Если я правильно понимаю, классы параллелизма используют неблокирующие алгоритмы, когда в этом случае вы хотите заблокировать, пока очередь пуста, и освободить процессор для использования другими потоками.
• Использование new и delete для каждого сообщения и внутренних распределений класса CString. Вам следует попробовать и посмотреть, поможет ли повторное использование сообщений и строк (с использованием пула) повысить производительность по двум причинам: 1. Распределение и освобождение объектов messages и string. 2. Распределений и освобождений, выполняемых внутри строк, возможно, можно избежать, если класс string будет внутренне перерабатывать свои буферы.

Вы пробовали профилировать, чтобы увидеть, где у вашего приложения проблемы? Проблемы с отправителем возникают только при регистрации? Это связано с процессором или блокируется?

Единственное, что я вижу, это то, что вы не защищаете очередь сообщений какой-либо блокировкой, поэтому состояние контейнера может стать странным, вызывая всевозможное неожиданное поведение.