R>>А куда Вам больше? А>есть куда. во время выполнения запросов к БД проц фактически простаивает большую часть времени. создание параллельных запросов увеличивает пропускную сопсобность в разы.
Отсюда вывод — работать с базой асинхронно.
В случае с множеством потоков большая часть из них будет простаивать, а поток — не бесплатный ресурс.
WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
21.04.11 11:13
Оценка:
Возникла следующая проблема с сабжем: вызовы Validate выполняются последовательно независимо от параллельных вызовов со стороны многих клиентов. Т.е. подключилось скажем 1000 клиентов и каждый последовательно проходит валидацию. Это ооочень сильно бьет по производительности в случае параллельных вызовов методов службы от многих клиентов.
Это такой баг или чем-то обусловлено? Как победить? Как вообще можно хостить службу ожидающую высокой нагрузки?
У службы настроен ConcurrencyMode.
Я в p.s. исходного сообщения указал ссылку, где подробно описаны мытарства, там было проделано вообще все, что только можно. Стивен Чен из MSFT сначала откликнулся на вопрос, а потом позорно слился.
Здравствуйте, perekrestov, Вы писали:
P>но тогда вам прийдется добавить логику синхронизации в классе сервиса.
А что если поставить InstanceContextMode в Single...
Конечно, для уменьшения кол-ва проверок креденшиалзов можно использовать сессию, но там уже, определенно, не basicHttpBinding
Это существенно позволит вам снизить кол-во обращений вашего кастомного валидатора в базу
[ServiceContract(SessionMode = SessionMode.Required)] //Required будет давать вам "отлуп" в виде экзепшена, если будете использовать несоотв. биндинг (например, basicHttpBinding)public interface IMyContract
{
}
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession, /*опционально, если вам нужно*/ ConcurrencyMode=ConcurrencyMode.Multiple)]
public class MyContract:IMyContract
{
}
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, perekrestov, Вы писали:
Да, и код валидатора в студию. Авось, вы там локами балуетесь
Re[4]: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
21.04.11 12:57
Оценка:
Здравствуйте, perekrestov, Вы писали:
P>Да, и код валидатора в студию. Авось, вы там локами балуетесь
код валидатора
Thread.Sleep(1000);
никаких локов нигде вообще не в теле службы ни в коде валидатора. более того как только выключаю валидатор вызовы сразу становятся параллельными
Re[3]: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
21.04.11 13:02
Оценка:
Здравствуйте, perekrestov, Вы писали:
P>А что если поставить InstanceContextMode в Single... P>Конечно, для уменьшения кол-ва проверок креденшиалзов можно использовать сессию, но там уже, определенно, не basicHttpBinding P>Это существенно позволит вам снизить кол-во обращений вашего кастомного валидатора в базу
это тоже было проделано — см. ссылку.
P>
P>[ServiceContract(SessionMode = SessionMode.Required)] //Required будет давать вам "отлуп" в виде экзепшена, если будете использовать несоотв. биндинг (например, basicHttpBinding)
P>public interface IMyContract
P>{
P>}
и это нам не поможет. речь идет о высоконагруженном сервере со многими клиентами - грубо сотни запросов в секунду, не с одного клиента, а с разных.
P>[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession, /*опционально, если вам нужно*/ ConcurrencyMode=ConcurrencyMode.Multiple)]
P>public class MyContract:IMyContract
P>{
P>}
P>
ну можно вообще обойтись без сессии в таком случае — использовать WSBinding — он устанавливает логическую сессию и производит аутентификацию единожды. но проблемы это не решает когда пользователи работают по схеме: подключился, вызвал метод-два, отключился.
Re: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
21.04.11 13:23
Оценка:
Здравствуйте, Аноним, Вы писали:
честно говоря я не ожидал подобного — это просто хэдшот любому highload серверу на wcf. неужели никто не разрабатывает ничего серьезного (высоконагруженного) на wcf раз не наткнулся на такой нехилый bottlneck'и?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, perekrestov, Вы писали:
P>>Да, и код валидатора в студию. Авось, вы там локами балуетесь
А>код валидатора
А>
А>Thread.Sleep(1000);
А>
А>никаких локов нигде вообще не в теле службы ни в коде валидатора. более того как только выключаю валидатор вызовы сразу становятся параллельными
Log4Net appender, который вы используете не тормозит, параллельно "лоча" потоки?
Да, и стрейсить сервис не мешало бы. Было бы понятно, что там происходит.
+ Антонелло интересно высказался по поводу физических параметров сервера (кол-во ядер и т.п.).
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>честно говоря я не ожидал подобного — это просто хэдшот любому highload серверу на wcf. неужели никто не разрабатывает ничего серьезного (высоконагруженного) на wcf раз не наткнулся на такой нехилый bottlneck'и?
Балансировка с WCF работает, но там есть серьезные ограничения на биндинги и бихейворы
Re[6]: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
21.04.11 13:53
Оценка:
Здравствуйте, perekrestov, Вы писали:
P>Да, и стрейсить сервис не мешало бы. Было бы понятно, что там происходит.
делаю простой тест, создаю 30 каналов с разными credentials (итого разные фабрики каналов) и вызываю асинхронно метод. метод — пустой. настройки оптимальные (Concurrency) и т.д. Получаю следующую картину ответов: отправлено 30 запросов и через
30(!) секунд начинают приходить ответы с интервалом паузы в указанной Validate!
P>+ Антонелло интересно высказался по поводу физических параметров сервера (кол-во ядер и т.п.).
Антоннело высказал извиняюсь полный бред тупо набивая посты. Ему разжевали, что вызовы Validate выполняются последовательно в то время как методы службы параллельно, но считает уместным сумничать на тему занятых ядер...
Re[3]: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
21.04.11 13:59
Оценка:
Здравствуйте, perekrestov, Вы писали:
P>Балансировка с WCF работает, но там есть серьезные ограничения на биндинги и бихейворы
балансировка ? throttling? да, работает, но распространяется только методы служб. а на PasswordValidator's сие как оказалось не рапространяется. итого полезность wcf я для себя на сегодня вижу только в решении следующем: подключилось дофига клиентов, прошли по очереди(!) аутентификацию и наконец-то заработали параллельно ну это очевидный баг, почему мелкософт так позорно слился в той теме мало того, что не пофиксив, так еще и не отписавшись. сразу скажу: автор той темы — не я, я наткнулся на сей баг вчера. гугля нашел только одну такую тему с подобной проблемой.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, perekrestov, Вы писали:
P>>Да, и стрейсить сервис не мешало бы. Было бы понятно, что там происходит. А>делаю простой тест, создаю 30 каналов с разными credentials (итого разные фабрики каналов) и вызываю асинхронно метод. метод — пустой. настройки оптимальные (Concurrency) и т.д. Получаю следующую картину ответов: отправлено 30 запросов и через А>30(!) секунд начинают приходить ответы с интервалом паузы в указанной Validate!
P>>+ Антонелло интересно высказался по поводу физических параметров сервера (кол-во ядер и т.п.). А>Антоннело высказал извиняюсь полный бред тупо набивая посты. Ему разжевали, что вызовы Validate выполняются последовательно в то время как методы службы параллельно, но считает уместным сумничать на тему занятых ядер...
Хм, да точно. Невнимательно прочитал. Сорри.
Остается только повторить тоже самое у себя на машине. А, все-таки, трейс не помешал бы.
Вероятно очередь запросов строится одним потоком и там же происходит аутентификация.
А WCF рантайм, в зависомости от настроек сервиса (InstanceContextMode, SessionMode, Concurency, Binding и прочего) выгребает реквесты с этой очереди.
Но это только догадки, нужно в литературу посмотреть, и, конечно, рефлектором.
Re[8]: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
21.04.11 14:38
Оценка:
Здравствуйте, perekrestov, Вы писали:
Вобщем перебирая варианты обнаружил, что таки Validate выполняется параллельно — порциями по ~10. Откуда эта цифра и как на нее влиять пока не понял.
А>Вобщем перебирая варианты обнаружил, что таки Validate выполняется параллельно — порциями по ~10. Откуда эта цифра и как на нее влиять пока не понял.
А куда Вам больше?
Увеличение одновременно выполняемых потоков только увеличит накладные расходы на переключение контекстов, а быстрее выполнятся всё равно не будет, т.к. число физических процессоров ограничено.
Здравствуйте, rumatavz, Вы писали:
R>А куда Вам больше?
есть куда. во время выполнения запросов к БД проц фактически простаивает большую часть времени. создание параллельных запросов увеличивает пропускную сопсобность в разы.
R>Увеличение одновременно выполняемых потоков только увеличит накладные расходы на переключение контекстов, а быстрее выполнятся всё равно не будет, т.к. число физических процессоров ограничено.
не в кассу
з.ы. провел несколько раз еще простейшие тесты и таки выполняется все последовательно. в ветке мелкософта отписался если кому интересно
Здравствуйте, rumatavz, Вы писали:
R>Отсюда вывод — работать с базой асинхронно.
как вы пришли к этому выводу? WCF вызывает метод Validate который должен выдать "результат". О какой асинхронности доступа к БД вы говорите? что она даст нам в этом случае?
R>В случае с множеством потоков большая часть из них будет простаивать, а поток — не бесплатный ресурс.
все эти банальности как бы общеизвестны.
раскройте тему применительно к топику
R>>Отсюда вывод — работать с базой асинхронно. А>как вы пришли к этому выводу? WCF вызывает метод Validate который должен выдать "результат". О какой асинхронности доступа к БД вы говорите? что она даст нам в этом случае?
Я имел ввиду, что если есть пул потоков, из которых выполняется одновременно выполняется только 10, то асинхронный вызов — в духе BeginRead позволил бы потоку вернуться в пул и обрабатывать другой вызов во время работы с БД(даже если WCF просто вызывает какой то метод, который выдаёт результат).
В данном случае признаю неуместность совета, т.к. даже если поток спит остальные запросы всё равно ожидают .
Здравствуйте, rumatavz, Вы писали:
R>Я имел ввиду, что если есть пул потоков, из которых выполняется одновременно выполняется только 10, то асинхронный вызов — в духе BeginRead позволил бы потоку вернуться в пул и обрабатывать другой вызов во время работы с БД(даже если WCF просто вызывает какой то метод, который выдаёт результат).
это понятно. проблема в том, что итого нет и 10 параллельных вызовов, есть последовательное выполнение. более того, я руками делал ThreadPool.SetMinThreads(350, 350), тротлинг тоже задан в такие значения, но все тщетно. судя по молчанию мелкософта — все очень плохо и баг имеет место быть. самое ужасное, что автор подобного топика на msdn создал тему пол года назад, а ответа все нет. они просто тупо тихо слились — не икомментировать, не исправлять
Здравствуйте, Аноним, Вы писали:
А>Как вообще можно хостить службу ожидающую высокой нагрузки?
Реализовать авторизацию через ж.. на другом уровне, добавать user/password/token в каждый метод сервиса?!
Re[2]: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
23.04.11 06:49
Оценка:
Здравствуйте, vf, Вы писали:
vf>Реализовать авторизацию через ж.. на другом уровне, добавать user/password/token в каждый метод сервиса?!
да, уже думал об этом, других вариантов действительно нет ну, разве, кроме, что Java
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, perekrestov, Вы писали:
P>>Да, и стрейсить сервис не мешало бы. Было бы понятно, что там происходит. А>делаю простой тест, создаю 30 каналов с разными credentials (итого разные фабрики каналов) и вызываю асинхронно метод. метод — пустой. настройки оптимальные (Concurrency) и т.д. Получаю следующую картину ответов: отправлено 30 запросов и через А>30(!) секунд начинают приходить ответы с интервалом паузы в указанной Validate!
А с чего ты взял что ququing у тебя на сервере а не на клиенте?
Народная мудрось
всем все никому ничего(с).
Re[8]: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
24.04.11 05:49
Оценка:
Здравствуйте, Tom, Вы писали:
Tom>А с чего ты взял что ququing у тебя на сервере а не на клиенте?
прочти внимательно. там все описано в подробностях и приведен тест. что это ququing который повляется только когда пауза имитируется в password validator'е, а как только эту саму паузу переносят в тело метода сервиса куинг ))) пропадает.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Tom, Вы писали:
Tom>>А с чего ты взял что ququing у тебя на сервере а не на клиенте?
А>прочти внимательно. там все описано в подробностях и приведен тест. что это ququing который повляется только когда пауза имитируется в password validator'е, а как только эту саму паузу переносят в тело метода сервиса куинг ))) пропадает.
Нужен конфиг сервера и клиента. Если то что ты описал в посте действительно так — т.е. "and figured out that there is no new "http request" in process until previous one passed", то куинг происходит на клиенте а не на сервере. Предпологаю что проблема в том, что ты не поменял дефолтное значение MaxConnections которое по умолчанию 2.
Здравствуйте, Tom, Вы писали:
Tom>Предпологаю что проблема в том, что ты не поменял дефолтное значение MaxConnections которое по умолчанию 2.
и как ты объяснишь мое: что это за ququing который повляется только когда пауза имитируется в password validator'е, а как только эту саму паузу переносят в тело метода сервиса куинг пропадает.
From client i create 30 ChannelFactory with different credetials and 30 channels. Then starts parallel asyncrhonous calls (i see 30 different https sessions). In the result responses comes sequentially with interval of 1 second (Thread.Sleep(1000) in the Validate) — 1 response per second! But in real parallel validation it must be 30 per second and grow up in in accordance with parallel requests!
Where is parallel password validagion? %)
What i'm doing wrong?
p.s. sorry fo my poor english )))
p.s1. and one more thing: if i move Thread.Sleep(1000) from Validate to the service method body — Get — i see 30 responses per second ))) i.e. service method calls is parallel but not Validate
не нужно упрощать проблему невнимательно читая мои ответы. в них уже содержаться ответы на твои вопросы.
А>всетаки ты не прочитал кстати, автор той темы не я, но там есть и мои ответы, в том числе (цитирую):
Я понял, остаётся только после того как 30 запросов приняты сервером остановить его по брейкпоинту и посмотреть где каждый поток ожидает. Может быть это даст информацию к размышлению. Мне на самом деле интересен результат ибо у нас точно такой же высоко нагруженный сервер и кастом валидаторы. Просто пока они работаю быстро — мы не столкнулись с подобными проблемами, либо просто пока их не заметили.
Здравствуйте, Tom, Вы писали:
Tom>Я понял, остаётся только после того как 30 запросов приняты сервером остановить его по брейкпоинту и посмотреть где каждый поток ожидает. Может быть это даст информацию к размышлению. Мне на самом деле интересен результат ибо у нас точно такой же высоко нагруженный сервер и кастом валидаторы. Просто пока они работаю быстро — мы не столкнулись с подобными проблемами, либо просто пока их не заметили.
надо попробовать.
проблема всплыла когда я стал делать стресс-тест для выяснения пропускной способности моих сервисов... и результаты меня прямо скажем не просто огорчили, а шокировали
АВТОР! Убил
Пойду свои валидаторы тестить. Пока также не сталкивался с проблемой производительности, т. к. пока что нагрузки невелики, но скоро надо подключать остальные офисы.
Если так — просто жесть.
Viva la Resistance!
Re[2]: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
25.04.11 13:09
Оценка:
Здравствуйте, OTMOP, Вы писали:
OTM>Пойду свои валидаторы тестить. Пока также не сталкивался с проблемой производительности, т. к. пока что нагрузки невелики, но скоро надо подключать остальные офисы.
очень жду результатов ваших тестов.
OTM>Если так — просто жесть.
не то слово
Здравствуйте, Аноним, Вы писали:
А>очень жду результатов ваших тестов.
Ну что Вам сказать. Результаты неутешительны. Действительно, валидация проходит в один поток и не параллелится
Мой проект от этой свиньи, которую нам подложили, спасает то, что я использую wsHttpBinding и сервисы PerSession, т.к. постоянно идёт обмен данными. Таким образом получается валидация проходит единожды при подключении.
НО НА БУДУЩЕЕ придётся это учесть. Заодно, наверное, стоит ещё на багтрэкер куда-нибудь закинуть эту информацию.
Viva la Resistance!
Re[4]: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
26.04.11 07:34
Оценка:
Здравствуйте, OTMOP, Вы писали:
OTM>Ну что Вам сказать. Результаты неутешительны. Действительно, валидация проходит в один поток и не параллелится OTM>Мой проект от этой свиньи, которую нам подложили, спасает то, что я использую wsHttpBinding и сервисы PerSession, т.к. постоянно идёт обмен данными. Таким образом получается валидация проходит единожды при подключении.
как я и ожидал. кстати с WS биндингом PerSession совсем необязателен для обхода этой проблемы — он и так проводит разовую аутентификаццию эмулируя логическую сессию — у меня и c PerCall прексрасно работает в рамках одного канала .
OTM>НО НА БУДУЩЕЕ придётся это учесть. Заодно, наверное, стоит ещё на багтрэкер куда-нибудь закинуть эту информацию.
да что там багтрекер, вы посмотрите первоначальный пост, там есть ссылка на social.msdn.com. как я уже писал, другой чел поднял эту проблему полгода назад, на нее откликнулись сразу два MSFT и оба слились без каких-либо комментариев, признаний бага, воркэраундов и т.д и т.п. Вы почитайте последний пост там, как я взываю к справедливости , а они полчат уже неделю. свинью подложили натуральные свиньи )))
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, OTMOP, Вы писали:
OTM>>Ну что Вам сказать. Результаты неутешительны. Действительно, валидация проходит в один поток и не параллелится OTM>>Мой проект от этой свиньи, которую нам подложили, спасает то, что я использую wsHttpBinding и сервисы PerSession, т.к. постоянно идёт обмен данными. Таким образом получается валидация проходит единожды при подключении. А>как я и ожидал. кстати с WS биндингом PerSession совсем необязателен для обхода этой проблемы — он и так проводит разовую аутентификаццию эмулируя логическую сессию — у меня и c PerCall прексрасно работает в рамках одного канала .
OTM>>НО НА БУДУЩЕЕ придётся это учесть. Заодно, наверное, стоит ещё на багтрэкер куда-нибудь закинуть эту информацию. А>да что там багтрекер, вы посмотрите первоначальный пост, там есть ссылка на social.msdn.com. как я уже писал, другой чел поднял эту проблему полгода назад, на нее откликнулись сразу два MSFT и оба слились без каких-либо комментариев, признаний бага, воркэраундов и т.д и т.п. Вы почитайте последний пост там, как я взываю к справедливости , а они полчат уже неделю. свинью подложили натуральные свиньи )))
А почему не создать баг на msconnect?
Народная мудрось
всем все никому ничего(с).
Re[6]: WCF: UserNamePasswordValidator concurrency
От:
Аноним
Дата:
26.04.11 09:17
Оценка:
Здравствуйте, Tom, Вы писали:
Tom>А почему не создать баг на msconnect?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Tom, Вы писали:
Tom>>А почему не создать баг на msconnect?
А>наверное потому, что я не в курсе что это http://connect.microsoft.com/
Создаш баг — кинь ссылку сюда, будем голосовать.
Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.
А>>наверное потому, что я не в курсе что это Tom>http://connect.microsoft.com/
Tom>Создаш баг — кинь ссылку сюда, будем голосовать. Tom>Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.
Здравствуйте, Tom, Вы писали:
Tom>>http://connect.microsoft.com/
создал. насколько позволяет знание англ языка )
Tom>>Создаш баг — кинь ссылку сюда, будем голосовать. здесь
Tom>>Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.
в форму создания бага скопипастил из social.msdn
Tom>Конкретно для WCF — ссылка: https://connect.microsoft.com/wcf
пасип
Tom>>>Но в идеале — создать минимаолтный пример на котором это можно воспроизвести. А>в форму создания бага скопипастил из social.msdn
лучше было бы пример сделать и убедиться что там есть проблема.
Ответили бы я думаю намного быстрее.
Здравствуйте, perekrestov, Вы писали:
P>Я могу ошибаться, но, кажется,
нет, вы не ошибаетесь, я перестраховался исключительно для форума — в других местах люди сходу тыкают в отсутствие Multiple не зная что он у PerSession по дефолту включен. Т.е. я упредил такие вопросы
А>поэтому вряд ли поможет )
А причём тут вообще сертификаты и HTTPS ?
Как я понял проблкема в кастом валидаторе, точнее в его вызове, тогда она должна проявляться в обычном wshttpbinding/basichttpbinding-е?
Здравствуйте, Tom, Вы писали:
А>>поэтому вряд ли поможет ) Tom>А причём тут вообще сертификаты и HTTPS ? Tom>Как я понял проблкема в кастом валидаторе, точнее в его вызове, тогда она должна проявляться в обычном wshttpbinding/basichttpbinding-е?
>>без защищенного транспорта wcf нe даст передавать credentials
Здравствуйте, perekrestov, Вы писали:
P>Даст, если подсунуть соотв. биндинг (только передавайте все поверх https):
ну я имел ввиду стандартные привязки.
чем сложнее (нестандартнее) код постишь на форумах/багтрекерах, тем больше отвлеченных от темы вопросов и "решений" дают, и ложных ошибок находят
запостишь вот с кастомным биндингом в багтрекер, а они тебе напишут, что: проблема в ваших биндингах и вообще не надо использовать небезопасные транспорты с открытыми удостоверениями, и "вообще микрософт так не рекомедует... поэтому у вас ниче и не работает" (С)
P>