У меня даже один телефон воткнутый в комп через USB хаб (недешевый, кстати) отваливается периодически — это выглядит, как будто телефон вытащили и воткнули обратно. ADB, естественно, при этом отваливается. Напрямую в комп тот же телефон работает нормально. Контейнеры мы тоже будем использовать, я вот буквально на этой неделе собирал похожий на ваш контейнер =)
Спасибо большое за статью!
А на чем у вас базируются сами тесты? Appium или что-то еще пробовали?
Не сталкивались ли с тем, что через USB хаб тесты работают нестабильно, а телефоны периодически отваливаются?
Глядя на одну и ту же заставку при запуске игры, воскрешении и быстром перемещении в Borderlands 2, возникает впечатление, что вас клонируют даже для такого пустяка, как телепортация.
Ну, один из предполагаемых способов телепортации и есть клонирование. На одном конце вас разбирают, передают информацию о квантовом состоянии частиц на ту сторону, а там собирают обратно.
Я бы предложил из линий складывать кружочки и замкнутые контуры. А по вложенности замкнутых контуров уже можно определить котика. Ну и слегка по форме. Палка-палка-огуречик — все знают, что это )
Disclaimer: я мало знаю про машинное обучение. Но хочу поделиться мыслями.
Есть такая книжка В. Турчина «Кибернетический подход к эволюции», которая перевернула мое мировоззрение однажды. Там есть глава (это оригинальный сайт, кодировка CP1251) про зрение. В ней утверждается, что понятия типа «пятно», «линия», «край», «общий фон освещения» распознаются еще в сетчатке глаза. В мозг поступают уже вот такие понятия, а не точки по отдельности. На следующем уровне из пятен, линий и краев (и, возможно, сигналов в форме базовых понятий от других органов чувств) формируются новые понятия типа «угроза», «добыча», «движущийся объект», «направление» итд. Потом еще один уровень, еще и еще.
Эти уровни и классификаторы формировались в процессе эволюции, а не в процессе обучения — поэтому у нас врожденные понятия прямых, точек, краев. И я думаю, что либо надо копировать природные классификаторы, либо использовать генетические алгоритмы для их построения. Пока компьютеры не научатся распознавать края и пятна и скармливать их на вход следующим уровням, людей они не опередят.
А я еще ждал про:
— Кулуарное общение и организация контактов на мероприятии.
— Фиксация результатов выступления — в течение 3-х дней после мероприятия.
Понял, в вашем случае распределенные тесты — действительно необходимость.
Мы в наших тестах стараемся исключить внешние факторы, поэтому чаще всего это машинки в одном ДЦ, а при больших нагрузках — в одном свитче. Даже есть кейсы, когда все тестируется в рамках одной машинки, а генератор и сервис раскидываются по ядрам.
10 Гбитный интерфейс между машинками, машинки в одном свитче. Не знаю, сколько в среднем у нас было на запрос при таких тестах, но вы учтите, что серваку еще распарсить полученный запрос надо. Это уж точно более затратно, чем просто отправить его, т.е. сервак ляжет раньше танка. А что, ваш сервис держит 100К запросов в секунду при 10-килобайтных запросах?
В процессе тестирования мы наблюдаем за нагрузкой на танк и следим за тем, чтобы проц, диск и сеть не кончились. Если есть сомнения, добавляем второй танк.
Число параллельных запросов и рейт связаны через среднее время ответа вот так:
L = λW (закон Литтла), где L — уровень параллелизма, λ — входящий рейт, W — среднее время ответа.
Т.е. при 100 000 запросов в сек и временах ответа 15 мс, будет 15 * 0.001 * 100 000 = 1500 параллельных запросов. Это меньше, чем 30 000.
Еще, паралельные юзеры != параллельные запросы. У юзеров есть еще think time между запросами.
50 К ядер на 50 К клиентов тоже не нужно, потому что клиент не требует постоянной работы проца. Ну и не надо забывать, что с противоположной стороны провода тоже не магический кристалл, а земная машинка с процессором, памятью и дисками. И ваши клиенты, сколько бы их ни было, встанут в очередь для того, чтобы пролезть через провод (один).
Ну так это особенности ОС, а не инструмента. В доках есть настройки, которые позволят свести к минимуму влияние этих особенностей. Кроме того, танк может стрелять с одной машинки с нескольких айпишников. Понятное дело, что если вы уперлись в сеть, то ничего из этого не поможет, но и никакой другой инструмент не сможет прокачать через сеть больше, чем через нее может пролезть.
На практике с одного танка получалось более 100 000 запросов в секунду. Это почти 9 миллиардов в сутки — немногие могут похвастаться такими рейтами. Опять же, на практике — очень редко, когда бывает нужно два и более танка. Иначе давно бы уже отладили распределенные тесты. А так в этом просто нет необходимости.
Есть.
Мы научили танк генерить локальные отчеты в виде html с графиками на базе highcharts. Данные лежат прямо внутри этих html-ек, включая данные мониторинга — при их использовании в графите нет необходимости.
Я думаю, что это круче, чем заливка в графит, поэтому модулем графита сейчас не занимаюсь (однако, графитовые отчеты теперь тоже с highcharts).
Если вам прямо очень нужны мониторинги в графите — воспользуйтесь Diamond и кастомным шаблоном.
Или опишите ваш кейс, возможно, я не прав, что не стоит заниматься графитом.
А я когда-то делал ДЗ по НАМ на языке РЕФАЛ. Очень удобно.
Потом еще с другом соревновались, у кого получится программа короче. Например, для возведения a в степень b.
Фичреквест про фильмы осуществим — пользователь хочет, чтобы в бэкап не попадали файлы с определенным типом данных. Может из определенной папки. Т.е. фильмы он может скачать заново из интернета, а всю систему восстанавливать вручную не хочет. По-моему, клевый кейс.
На ситилинке уже пару лет как работает система подбора и обмена комплектациями компьютеров наподобие той, что вы описываете. И реализацию системы про очередь в столовой я видел, только там qr-коды использовались. Проще.
А на чем у вас базируются сами тесты? Appium или что-то еще пробовали?
Не сталкивались ли с тем, что через USB хаб тесты работают нестабильно, а телефоны периодически отваливаются?
На Земле 2016.
Вот еще Pomegranate Tiger и Russian Circles
Ну, один из предполагаемых способов телепортации и есть клонирование. На одном конце вас разбирают, передают информацию о квантовом состоянии частиц на ту сторону, а там собирают обратно.
Есть такая книжка В. Турчина «Кибернетический подход к эволюции», которая перевернула мое мировоззрение однажды. Там есть глава (это оригинальный сайт, кодировка CP1251) про зрение. В ней утверждается, что понятия типа «пятно», «линия», «край», «общий фон освещения» распознаются еще в сетчатке глаза. В мозг поступают уже вот такие понятия, а не точки по отдельности. На следующем уровне из пятен, линий и краев (и, возможно, сигналов в форме базовых понятий от других органов чувств) формируются новые понятия типа «угроза», «добыча», «движущийся объект», «направление» итд. Потом еще один уровень, еще и еще.
Эти уровни и классификаторы формировались в процессе эволюции, а не в процессе обучения — поэтому у нас врожденные понятия прямых, точек, краев. И я думаю, что либо надо копировать природные классификаторы, либо использовать генетические алгоритмы для их построения. Пока компьютеры не научатся распознавать края и пятна и скармливать их на вход следующим уровням, людей они не опередят.
— Кулуарное общение и организация контактов на мероприятии.
— Фиксация результатов выступления — в течение 3-х дней после мероприятия.
Мы в наших тестах стараемся исключить внешние факторы, поэтому чаще всего это машинки в одном ДЦ, а при больших нагрузках — в одном свитче. Даже есть кейсы, когда все тестируется в рамках одной машинки, а генератор и сервис раскидываются по ядрам.
В процессе тестирования мы наблюдаем за нагрузкой на танк и следим за тем, чтобы проц, диск и сеть не кончились. Если есть сомнения, добавляем второй танк.
Число параллельных запросов и рейт связаны через среднее время ответа вот так:
L = λW (закон Литтла), где L — уровень параллелизма, λ — входящий рейт, W — среднее время ответа.
Т.е. при 100 000 запросов в сек и временах ответа 15 мс, будет 15 * 0.001 * 100 000 = 1500 параллельных запросов. Это меньше, чем 30 000.
Еще, паралельные юзеры != параллельные запросы. У юзеров есть еще think time между запросами.
50 К ядер на 50 К клиентов тоже не нужно, потому что клиент не требует постоянной работы проца. Ну и не надо забывать, что с противоположной стороны провода тоже не магический кристалл, а земная машинка с процессором, памятью и дисками. И ваши клиенты, сколько бы их ни было, встанут в очередь для того, чтобы пролезть через провод (один).
На практике с одного танка получалось более 100 000 запросов в секунду. Это почти 9 миллиардов в сутки — немногие могут похвастаться такими рейтами. Опять же, на практике — очень редко, когда бывает нужно два и более танка. Иначе давно бы уже отладили распределенные тесты. А так в этом просто нет необходимости.
Мы научили танк генерить локальные отчеты в виде html с графиками на базе highcharts. Данные лежат прямо внутри этих html-ек, включая данные мониторинга — при их использовании в графите нет необходимости.
Я думаю, что это круче, чем заливка в графит, поэтому модулем графита сейчас не занимаюсь (однако, графитовые отчеты теперь тоже с highcharts).
Если вам прямо очень нужны мониторинги в графите — воспользуйтесь Diamond и кастомным шаблоном.
Или опишите ваш кейс, возможно, я не прав, что не стоит заниматься графитом.
Потом еще с другом соревновались, у кого получится программа короче. Например, для возведения a в степень b.