Re[3]: WCF: UserNamePasswordValidator concurrency - .NET

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, perekrestov, Вы писали:

P>>Да, и стрейсить сервис не мешало бы. Было бы понятно, что там происходит.
А>делаю простой тест, создаю 30 каналов с разными credentials (итого разные фабрики каналов) и вызываю асинхронно метод. метод — пустой. настройки оптимальные (Concurrency) и т.д. Получаю следующую картину ответов: отправлено 30 запросов и через
А>30(!) секунд начинают приходить ответы с интервалом паузы в указанной Validate!
А с чего ты взял что ququing у тебя на сервере а не на клиенте?

Здравствуйте, 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'е, а как только эту саму паузу переносят в тело метода сервиса куинг пропадает.

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

 ServicePointManager.DefaultConnectionLimit = int.MaxValue;

и далее я сие выделил в тексте

всетаки ты не прочитал

кстати, автор той темы не я, но там есть и мои ответы, в том числе (цитирую):

It's a simple test:

sealed class MyPasswordValidator : UserNamePasswordValidator
{
        public override void Validate(string userName, string password)
        {
            Thread.Sleep(1000);
        }
    }

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall, ConcurrencyMode = ConcurrencyMode.Multiple)]
    public sealed class MyService : IMyService
    {
        public int Get(int i)
        {
            return i;
        }
    }
}

Binding:

<basicHttpBinding>
            <binding name="SubscriberBasicTransportWithMessageCredential">
              <security mode="TransportWithMessageCredential">
                <message clientCredentialType="UserName" />
              </security>
            </binding>

Throttling:

<serviceThrottling maxConcurrentCalls="350" maxConcurrentSessions="350" maxConcurrentInstances="350" />

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 запросов приняты сервером остановить его по брейкпоинту и посмотреть где каждый поток ожидает. Может быть это даст информацию к размышлению. Мне на самом деле интересен результат ибо у нас точно такой же высоко нагруженный сервер и кастом валидаторы. Просто пока они работаю быстро — мы не столкнулись с подобными проблемами, либо просто пока их не заметили.

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

АВТОР! Убил

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

Если так — просто жесть.

Здравствуйте, OTMOP, Вы писали:

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

очень жду результатов ваших тестов.

OTM>Если так — просто жесть.
не то слово

Здравствуйте, Аноним, Вы писали:

А>очень жду результатов ваших тестов.

Ну что Вам сказать. Результаты неутешительны. Действительно, валидация проходит в один поток и не параллелится

Мой проект от этой свиньи, которую нам подложили, спасает то, что я использую wsHttpBinding и сервисы PerSession, т.к. постоянно идёт обмен данными. Таким образом получается валидация проходит единожды при подключении.

НО НА БУДУЩЕЕ придётся это учесть. Заодно, наверное, стоит ещё на багтрэкер куда-нибудь закинуть эту информацию.

Здравствуйте, 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?

Здравствуйте, Tom, Вы писали:

Tom>А почему не создать баг на msconnect?

наверное потому, что я не в курсе что это

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Tom, Вы писали:

Tom>>А почему не создать баг на msconnect?

А>наверное потому, что я не в курсе что это

http://connect.microsoft.com/

Создаш баг — кинь ссылку сюда, будем голосовать.
Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.

А>>наверное потому, что я не в курсе что это

Tom>http://connect.microsoft.com/

Tom>Создаш баг — кинь ссылку сюда, будем голосовать.
Tom>Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.

Конкретно для WCF — ссылка: https://connect.microsoft.com/wcf

Здравствуйте, Tom, Вы писали:

Tom>>http://connect.microsoft.com/
создал. насколько позволяет знание англ языка )

Tom>>Создаш баг — кинь ссылку сюда, будем голосовать.
здесь

Tom>>Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.
в форму создания бага скопипастил из social.msdn

Tom>Конкретно для WCF — ссылка: https://connect.microsoft.com/wcf
пасип

Tom>>>Но в идеале — создать минимаолтный пример на котором это можно воспроизвести.
А>в форму создания бага скопипастил из social.msdn
лучше было бы пример сделать и убедиться что там есть проблема.
Ответили бы я думаю намного быстрее.

Здравствуйте, Tom, Вы писали:

Tom>лучше было бы пример сделать и убедиться что там есть проблема.

это изначально сложно — и не пример сделать, а
1. сертификат создать
2. добавить его в хранилище
3. привязать к порту

т.к. используется HTTPS а без защищенного транспорта wcf нe даст передавать credentials

поэтому вряд ли поможет )

Здравствуйте, Аноним, Вы писали:

А>[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall, ConcurrencyMode = ConcurrencyMode.Multiple)]
А> public sealed class MyService : IMyService
А> {
А> public int Get(int i)
А> {
А> return i;
А> }
А> }
А>}
А>[/c#]

А>Binding:
А>

А><basicHttpBinding>
А>            <binding name="SubscriberBasicTransportWithMessageCredential">
А>              <security mode="TransportWithMessageCredential">
А>                <message clientCredentialType="UserName" />
А>              </security>
А>            </binding>
А>

А>Throttling:
А>

А><serviceThrottling maxConcurrentCalls="350" maxConcurrentSessions="350" maxConcurrentInstances="350" />
А>

Я могу ошибаться, но, кажется,

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall, ConcurrencyMode = ConcurrencyMode.Multiple)]

особо не имеет смысла

В этом случае уж лучше InstanceContextMode.Single использовать.

	От:	vf
	Дата:	22.04.11 17:16
	Оценка:

	От:	Аноним
	Дата:	23.04.11 06:49
	Оценка:

От:	Tom	http://www.RSDN.ru
Дата:	23.04.11 20:26
Оценка:

	От:	Аноним
	Дата:	24.04.11 05:49
	Оценка:

От:	Tom	http://www.RSDN.ru
Дата:	24.04.11 10:13
Оценка:

	От:	OTMOP
	Дата:	25.04.11 11:00
	Оценка:

	От:	OTMOP
	Дата:	25.04.11 15:16
	Оценка:

	От:	perekrestov
	Дата:	26.04.11 14:15
	Оценка: