Re: Тестирование

2016-09-30 Пенетрантность Sergey Pisanko 

Отваливаться начинают первые в списке. Сразу две учетки.

Не помню, писал ли... Но на релизе 3.1.1 в незащищенном соединении 
такого не наблюдалось. Сейчас решил перепроверить, установил 3.1.1 и 
полет нормальный при 18  - ти логинах.



30.09.2016 14:10, Maxim Solodovnik пишет:

ОК, пусть будет mysql
попробую на одном пользователе

по Вашим наблюдениям пользователи отваливаются в произвольном порядке?

2016-09-30 17:39 GMT+07:00 Sergey Pisanko :


на всякий случай перепускаем ОМ (дерби иногда странно себя ведёт сразу
Я использовал mysql.

одного пользователя (админа) хватит?
Я использовал двух, думаю, хватит и одного.

тип комнаты важен?
В моем случае - Public Conference room/32.

что надо делать после входа?
Входить повторно этим же пользователем, доводя количество логинов до 11.
Можно в одном браузере в разных вкладках, либо в разных браузерах. "Audio
only".



30.09.2016 13:21, Maxim Solodovnik пишет:

ОК

предлагаю зафиксировать шаги

1) скачиваем №384 отсюда
https://builds.apache.org/view/M-R/view/OpenMeetings/job/
Openmeetings%203.1.x/
2) ничего не меняем
3) запускаем
4) проходим инсталляцию, создаём пользователя
тут получили vanilla version
4.1) на всякий случай перепускаем ОМ (дерби иногда странно себя ведёт
сразу
после установки)
5) этим пользователем заходим в комнату

тут вопросы
1) одного пользователя (админа) хватит?
2) тип комнаты важен?
3) что надо делать после входа?

2016-09-30 13:49 GMT+07:00 Sergey Pisanko :

Добрый день.

Испытал релиз 3.1.3 на предмет описанной ниже ситуации. Проблема
повторяется. Ровно на 11 - м участнике, пользователи начинают
"отваливаться". Происходит как на tls/rtmps,  так и на незащищенном
соединении. Насколько я понимаю, кол - во участников зависит лишь от
объема
серверных ресурсов, и явных ограничений нет?!


24.06.2016 14:51, Sergey Pisanko пишет:

Добрый день.

Очередной "виток" тестирования.

*Hardware:*

CPU: Intel® Xeon® Processor E5430; 2,66 GHz x 4. RAM: 4 Gb

*Software:*

OS: Centos - 6,5-release. Java: jdk1.8.0_92. OM: 3.1.2

При вхождении в одну комнату > 10 участников, начинают "отваливаться"
другие участники, уже находящиеся в комнате (от 1 до 3). При этом для
"отвалившегося" нет явных признаков того, что он покинул комнату. На
фоне
этого:

1. При использовании TLS/RTMPS (native) доступа, сразу после "отвала"
участников и происходит описанный ранее overload CPU (до 100%) по 1 - 2
ядрам. Загрузка процессора продолжается вплоть до перезагрузки OM.
Данная
ситуация воспроизвелась 5 раз подряд на 11 - м участнике.

2. При использовании обычного/небезопасного доступа, участники также
начинают "отваливаться"примерно на том же количестве, загрузки CPU при
этом
не происходит.

Рекомендуется к воспроизведению.


17.06.2016 13:00, Sergey Pisanko пишет:

Уже именно это и сделал, перенес на "железо", тот же эффект. Может, где

- то в коде не все ладно? С версиями джавы экспериментировал - не
помогло.


17.06.2016 12:52, Maxim Solodovnik пишет:

у нас dedicated сервер

есть ли у вас возможность попробовать на "реальном" железе? может
виртуализация даёт такой эффект?

2016-06-17 15:08 GMT+06:00 Sergey Pisanko :

Нет, запускаю именно red5.sh. Уже позже обратил внимание, что не
всегда


overload CPU связан с количеством участников, замечал на 7 - 8. Где -
то
какое - то событие сильно нагружает проц и лечится сие только
рестартом
сервиса.


17.06.2016 11:11, Maxim Solodovnik пишет:

пускаете скриптом *highperfюыр?


обычным red5.sh не пробовали?

2016-06-09 18:12 GMT+06:00 Sergey Pisanko :

Выкладываю ссылку на скриншот по процессам и загрузке CPU в момент

тестирования конференции в кол - ве не более 10 участников. Стойкое

впечатление, что в процессах не все красиво.
http://my-files.ru/4z6ybr


09.06.2016 7:55, Vasiliy Degtyarev пишет:

Добрый день, Сергей!

Что значит - - при оверлоаде CPU слетают админские права в комнате?

С уважением,
Василий Дегтярев

On 08.06.2016 20:14, Sergey Pisanko wrote:

Добрый день, коллеги.

Евгений, спасибо за отзыв.

Что бы сервер openmeetings съедал всю память я не припомню.
Василий, не RAM - ресурсы, а CPU. С использованием памяти ОК.
Проявилась
особенность - при оверлоаде CPU слетают админские права в
комнате.

А какую java Вы используете?
Пакет jdk-8u77 Oracle. Попробую обновиться.


08.06.2016 6:52, Евгений Хрянин пишет:

Здравствуйте, коллеги.

У меня OM на не очень сильном сервере HP DL120 G7. 4 ядра, 8гб

озу.
Проводим видео конференции 5-6 точек 320*240, или аудио 10-12.
Нагрузка на сервере не выше 15-20%
ОС Centos 7 (минималка). JRE от оракла. OM 3.1.1
Рядом еще установлен openfire на 100 человек.
Задержек и зависаний нет.
Раньше были на клиентской стороне, но решили их расширением
канала
связи и
обновлением железа ПК
8 Июн 2016 г. 6:31 пользователь "Vasiliy Degtyarev"<
va...@unipro.ru>
написал:

Добрый день, Сергей!

Максим сейчас в отпуске, будет 20 июня.


Опыт проведения конференций показывает что можно проводить
конференцию
с
видео 120х90 до 20

Re: Тестирование

2016-09-30 Пенетрантность Maxim Solodovnik 
ОК
предлагаю зафиксировать шаги

1) скачиваем №384 отсюда
https://builds.apache.org/view/M-R/view/OpenMeetings/job/Openmeetings%203.1.x/
2) ничего не меняем
3) запускаем
4) проходим инсталляцию, создаём пользователя
тут получили vanilla version
4.1) на всякий случай перепускаем ОМ (дерби иногда странно себя ведёт сразу
после установки)
5) этим пользователем заходим в комнату

тут вопросы
1) одного пользователя (админа) хватит?
2) тип комнаты важен?
3) что надо делать после входа?

2016-09-30 13:49 GMT+07:00 Sergey Pisanko :

> Добрый день.
>
> Испытал релиз 3.1.3 на предмет описанной ниже ситуации. Проблема
> повторяется. Ровно на 11 - м участнике, пользователи начинают
> "отваливаться". Происходит как на tls/rtmps,  так и на незащищенном
> соединении. Насколько я понимаю, кол - во участников зависит лишь от объема
> серверных ресурсов, и явных ограничений нет?!
>
>
> 24.06.2016 14:51, Sergey Pisanko пишет:
>
>> Добрый день.
>>
>> Очередной "виток" тестирования.
>>
>> *Hardware:*
>>
>> CPU: Intel® Xeon® Processor E5430; 2,66 GHz x 4. RAM: 4 Gb
>>
>> *Software:*
>>
>> OS: Centos - 6,5-release. Java: jdk1.8.0_92. OM: 3.1.2
>>
>> При вхождении в одну комнату > 10 участников, начинают "отваливаться"
>> другие участники, уже находящиеся в комнате (от 1 до 3). При этом для
>> "отвалившегося" нет явных признаков того, что он покинул комнату. На фоне
>> этого:
>>
>> 1. При использовании TLS/RTMPS (native) доступа, сразу после "отвала"
>> участников и происходит описанный ранее overload CPU (до 100%) по 1 - 2
>> ядрам. Загрузка процессора продолжается вплоть до перезагрузки OM. Данная
>> ситуация воспроизвелась 5 раз подряд на 11 - м участнике.
>>
>> 2. При использовании обычного/небезопасного доступа, участники также
>> начинают "отваливаться"примерно на том же количестве, загрузки CPU при этом
>> не происходит.
>>
>> Рекомендуется к воспроизведению.
>>
>>
>> 17.06.2016 13:00, Sergey Pisanko пишет:
>>
>>> Уже именно это и сделал, перенес на "железо", тот же эффект. Может, где
>>> - то в коде не все ладно? С версиями джавы экспериментировал - не помогло.
>>>
>>>
>>> 17.06.2016 12:52, Maxim Solodovnik пишет:
>>>
 у нас dedicated сервер
 есть ли у вас возможность попробовать на "реальном" железе? может
 виртуализация даёт такой эффект?

 2016-06-17 15:08 GMT+06:00 Sergey Pisanko :

 Нет, запускаю именно red5.sh. Уже позже обратил внимание, что не всегда
> overload CPU связан с количеством участников, замечал на 7 - 8. Где -
> то
> какое - то событие сильно нагружает проц и лечится сие только рестартом
> сервиса.
>
>
> 17.06.2016 11:11, Maxim Solodovnik пишет:
>
> пускаете скриптом *highperfюыр?
>> обычным red5.sh не пробовали?
>>
>> 2016-06-09 18:12 GMT+06:00 Sergey Pisanko :
>>
>> Выкладываю ссылку на скриншот по процессам и загрузке CPU в момент
>>
>>> тестирования конференции в кол - ве не более 10 участников. Стойкое
>>> впечатление, что в процессах не все красиво.
>>> http://my-files.ru/4z6ybr
>>>
>>>
>>> 09.06.2016 7:55, Vasiliy Degtyarev пишет:
>>>
>>> Добрый день, Сергей!
>>>

 Что значит - - при оверлоаде CPU слетают админские права в комнате?

 С уважением,
 Василий Дегтярев

 On 08.06.2016 20:14, Sergey Pisanko wrote:

 Добрый день, коллеги.

> Евгений, спасибо за отзыв.
>
> Что бы сервер openmeetings съедал всю память я не припомню.
> Василий, не RAM - ресурсы, а CPU. С использованием памяти ОК.
> Проявилась
> особенность - при оверлоаде CPU слетают админские права в комнате.
>
> А какую java Вы используете?
> Пакет jdk-8u77 Oracle. Попробую обновиться.
>
>
> 08.06.2016 6:52, Евгений Хрянин пишет:
>
> Здравствуйте, коллеги.
>
>> У меня OM на не очень сильном сервере HP DL120 G7. 4 ядра, 8гб
>> озу.
>> Проводим видео конференции 5-6 точек 320*240, или аудио 10-12.
>> Нагрузка на сервере не выше 15-20%
>> ОС Centos 7 (минималка). JRE от оракла. OM 3.1.1
>> Рядом еще установлен openfire на 100 человек.
>> Задержек и зависаний нет.
>> Раньше были на клиентской стороне, но решили их расширением канала
>> связи и
>> обновлением железа ПК
>> 8 Июн 2016 г. 6:31 пользователь "Vasiliy Degtyarev"<
>> va...@unipro.ru>
>> написал:
>>
>> Добрый день, Сергей!
>>
>> Максим сейчас в отпуске, будет 20 июня.
>>> Опыт проведения конференций показывает что можно проводить
>>> конференцию
>>> с
>>> видео 120х90 до 20 участников.
>>> Основные проблемы обычно возникали из-за пропускной способности
>>> сети
>>> и
>>> из-за flash. Что бы сервер openmeetings

Re: Тестирование

2016-09-30 Пенетрантность Sergey Pisanko 

Добрый день.

Испытал релиз 3.1.3 на предмет описанной ниже ситуации. Проблема 
повторяется. Ровно на 11 - м участнике, пользователи начинают 
"отваливаться". Происходит как на tls/rtmps,  так и на незащищенном 
соединении. Насколько я понимаю, кол - во участников зависит лишь от 
объема серверных ресурсов, и явных ограничений нет?!



24.06.2016 14:51, Sergey Pisanko пишет:

Добрый день.

Очередной "виток" тестирования.

*Hardware:*

CPU: Intel® Xeon® Processor E5430; 2,66 GHz x 4. RAM: 4 Gb

*Software:*

OS: Centos - 6,5-release. Java: jdk1.8.0_92. OM: 3.1.2

При вхождении в одну комнату > 10 участников, начинают "отваливаться" 
другие участники, уже находящиеся в комнате (от 1 до 3). При этом для 
"отвалившегося" нет явных признаков того, что он покинул комнату. На 
фоне этого:


1. При использовании TLS/RTMPS (native) доступа, сразу после "отвала" 
участников и происходит описанный ранее overload CPU (до 100%) по 1 - 
2 ядрам. Загрузка процессора продолжается вплоть до перезагрузки OM. 
Данная ситуация воспроизвелась 5 раз подряд на 11 - м участнике.


2. При использовании обычного/небезопасного доступа, участники также 
начинают "отваливаться"примерно на том же количестве, загрузки CPU при 
этом не происходит.


Рекомендуется к воспроизведению.


17.06.2016 13:00, Sergey Pisanko пишет:
Уже именно это и сделал, перенес на "железо", тот же эффект. Может, 
где - то в коде не все ладно? С версиями джавы экспериментировал - не 
помогло.



17.06.2016 12:52, Maxim Solodovnik пишет:

у нас dedicated сервер
есть ли у вас возможность попробовать на "реальном" железе? может
виртуализация даёт такой эффект?

2016-06-17 15:08 GMT+06:00 Sergey Pisanko :

Нет, запускаю именно red5.sh. Уже позже обратил внимание, что не 
всегда
overload CPU связан с количеством участников, замечал на 7 - 8. Где 
- то
какое - то событие сильно нагружает проц и лечится сие только 
рестартом

сервиса.


17.06.2016 11:11, Maxim Solodovnik пишет:


пускаете скриптом *highperfюыр?
обычным red5.sh не пробовали?

2016-06-09 18:12 GMT+06:00 Sergey Pisanko :

Выкладываю ссылку на скриншот по процессам и загрузке CPU в момент

тестирования конференции в кол - ве не более 10 участников. Стойкое
впечатление, что в процессах не все красиво.
http://my-files.ru/4z6ybr


09.06.2016 7:55, Vasiliy Degtyarev пишет:

Добрый день, Сергей!


Что значит - - при оверлоаде CPU слетают админские права в комнате?

С уважением,
Василий Дегтярев

On 08.06.2016 20:14, Sergey Pisanko wrote:

Добрый день, коллеги.

Евгений, спасибо за отзыв.

Что бы сервер openmeetings съедал всю память я не припомню.
Василий, не RAM - ресурсы, а CPU. С использованием памяти ОК.
Проявилась
особенность - при оверлоаде CPU слетают админские права в комнате.

А какую java Вы используете?
Пакет jdk-8u77 Oracle. Попробую обновиться.


08.06.2016 6:52, Евгений Хрянин пишет:

Здравствуйте, коллеги.
У меня OM на не очень сильном сервере HP DL120 G7. 4 ядра, 8гб 
озу.

Проводим видео конференции 5-6 точек 320*240, или аудио 10-12.
Нагрузка на сервере не выше 15-20%
ОС Centos 7 (минималка). JRE от оракла. OM 3.1.1
Рядом еще установлен openfire на 100 человек.
Задержек и зависаний нет.
Раньше были на клиентской стороне, но решили их расширением 
канала

связи и
обновлением железа ПК
8 Июн 2016 г. 6:31 пользователь "Vasiliy 
Degtyarev"

написал:

Добрый день, Сергей!


Максим сейчас в отпуске, будет 20 июня.
Опыт проведения конференций показывает что можно проводить
конференцию
с
видео 120х90 до 20 участников.
Основные проблемы обычно возникали из-за пропускной 
способности сети

и
из-за flash. Что бы сервер openmeetings съедал всю память я не
припомню. А
какую java Вы используете?

С уважением,
Василий Дегтярев


On 07.06.2016 19:24, Sergey Pisanko wrote:

Добрый день, Максим.

Провели пробное тестирование с участием 15 - 20 чел, только 
аудио.

При
таком количестве, сервер сваливается по ресурсам CPU, съедаемых
java.
Днем
ранее, 5 участников с видео 240х180 сервер вполне нормально 
тянул.

Сервер
виртуализирован на xsphere-5.5, ОС - Centos- 6.5, в системе 8
виртуальных
CPU 3,5 GHz, openmeetings-3.1.2. Что характерно, при 
освобождении

комнаты
участниками, java продолжала грузить проц до полного ее 
перезапуска.


Максим, каковы, вообще, требования по CPU, каков максимум
участников с
позитивным опытом, что может быть причиной, и в сторону чего
смотреть?




--

-
С Уважением,
Сергей Писанко.




--
-
С Уважением,
Сергей Писанко.










--
-
С Уважением,
Сергей Писанко.