C # - Улучшение многопоточного дизайна приложений - PullRequest
Новая
       14

C # - Улучшение многопоточного дизайна приложений

0 голосов
/ 07 июля 2010

Спецификация

  • Распределенное приложение C #.
  • Клиент / Сервер дизайн.
  • Клиент (Winforms), Сервер (Служба Windows), Связь через .Net Remoting.
  • Следующий вопрос относится к стороне сервера приложения.
  • (РЕДАКТИРОВАТЬ) Серверная часть приложения работает на сервере с 8 ядрами и 12 Гбайт оперативной памяти
  • (РЕДАКТИРОВАТЬ) ЦП этого сервера всегда работает примерно на 80% Использование из-за большого количества других запущенных служб на этом же сервере.

Сценарий

  • Я унаследовал большое устаревшее приложение.
  • Он выполняет кучу задач, некоторые из них независимо, а другие нет.
  • Текущий дизайн этого приложения предусматривает создание 14 потоков, каждый из которых выполняет либо 1 задачу, либо несколько задач.
  • Проблема в том, что мне кажется, что этот элемент дизайна влияет на производительность .

Примеры кода - как создается и выполняется каждый класс / поток 

public class ManageThreads
{
    private Thread doStuffThread = null;

    //Inside the constructor EVERY thread is instantiated and run.
    //(I am aware that this example only shows the use of 1 thread).
    public ManageThreads()
    {
       doStuffThread = new Thread(new ThreadStart(DoSomeStuff.Instance.Start));
       doStuffThread.Start();

       //Instantiate and run another thread.....
       //Instantiate and run another thread.....
       //Instantiate and run another thread.....etc.
    }

}

public class DoSomeStuff
{
    void Start()
    { 
        while(true)
        {
          //Repeatedly do some tasks.....

          Thread.Sleep(5000);
        }
     }   
 }

Мысли

  • Я хотел бы сохранить существующий код, но изменить способ его работы.
  • Я думал об использовании Thread Pool для решения этой проблемы, но, учитывая текущую архитектуру, я не уверен, как бы я поступил так.

Вопросы

  • Заметно ли повлияет этот текущий дизайн на производительность?
  • Могу ли я улучшить производительность этого приложения, не меняя базовые функции, но слегка изменив дизайн?
  • Кто-нибудь может порекомендовать что-нибудь / посоветовать мне правильный путь для улучшения этого?

Помощь с благодарностью.

Ответы [ 2 ]

4 голосов
/ 07 июля 2010

«У меня такое ощущение, что этот элемент дизайна влияет на производительность.»

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

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

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

0 голосов
/ 07 июля 2010

если все ваши потоки работают, и у вас больше активных потоков, чем у процессоров, вы потратите время на переключение контекста.

Если у вас двухъядерный процессор, не рассчитывайте на отличную производительность с более чем 4 активными рабочими потоками.

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

Следовательно, использование пула потоков вместе с профилировщиком позволяет определить оптимальное количество потоков, доступных для пула потоков.

В большинстве случаев, когда люди назначают пул потоков, большинство потоков ничего не делает большую часть времени или поток спит / блокируется, в то время как некоторая медленная операция или внешняя зависимость ожидают ответа.

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

На двухъядерном процессоре я не решился бы использовать более 3 потоков, если они все работают 100% времени

...