Один из его методов может выполнять "тяжелую" работу, в процессе которой отжирает существенное количество оперативки и процессорного времени. Соответственно, пока метод выполняется, остальным процессам на сервере приходится довольно туго.
Нужно избавиться от этого эффекта.
С жором памяти разберусь — там все очевидно. Проблема в изменении приоритета потока, в котором выполняется метод. Насколько я понимаю, ремоутинг использует потоки из пула, а в документации к пулу указано, что если поток должен иметь определенный приоритет, то пул использовать не стОит.
Решение "в лоб" — в ремоутинг-методе создавать поток, назначать ему приоритет, в его контексте выполнять всю работу и затем забирать результат.
Какие варианты могут быть использованы еще? Судя по всему, такая же проблема будет характерна и для WCF-сервисов. Есть ли для них какое-то более специфическое и более красивое решение?
Re: Вызов на стороне сервера и приоритет потока
От:
Аноним
Дата:
09.07.09 11:48
Оценка:
Здравствуйте, HowardLovekraft, Вы писали:
HL>Есть ремоутинг-сервер.
HL>Решение "в лоб" — в ремоутинг-методе создавать поток, назначать ему приоритет, в его контексте выполнять всю работу и затем забирать результат.
И чем вас этот вариант не устраивает?
Единственный момент — поток создавать не в "ремоутинг-методе", а реализовать отдельную инфраструктуру (синглтон), которая будет крутить таски. Соответственно в "ремоутинг-методе" создавать таск и отдавать на обработку инфраструктуре.
--
Re[2]: Вызов на стороне сервера и приоритет потока
Здравствуйте, Аноним, Вы писали:
А>И чем вас этот вариант не устраивает?
Кажется стрельбой из пушки по воробьям.
Тем более, что на 100 вызовов метода приходится 10 случаев, когда он обрабатывает большой объем данных и создает описанный выше эффект. Остальные 90 вызовов работают с меньшим объемом данных и такой проблемы нет.
Re[3]: Вызов на стороне сервера и приоритет потока
Здравствуйте, HowardLovekraft, Вы писали:
HL>Тем более, что на 100 вызовов метода приходится 10 случаев, когда он обрабатывает большой объем данных и создает описанный выше эффект. Остальные 90 вызовов работают с меньшим объемом данных и такой проблемы нет.
Стандартного подхода тоже не знаю.
Но почему бы инфрастуктура не решила стоит ли создавать поток для таска или нет использую его объём?!
Ну если же объём отследить сложно, что выхода нет.
