Есть плагины для jmeter на гуглокоде, там насколько знаю есть возможность хватать метрики с нагружаемых серваков. Хотя никогда по этому поводу не заморачивался, и использовал метрики, записанные осью или сторонним софтом.
Миллион юзеров нужен почти никогда. Софт каждого виртуального юзера представляет одним потоком. Когда он выполнил свое действие, то поток не убивается, а используется повторно. Убивать сам поток смысла не имеет раз, а затраты системы на создание нового довольно существенны (вне зависимости от языка) — это два. Поэтому разговор при нагрузке идет не о миллионах пользователей, а о количестве запросов в единицу времени. Могу на личном опыте привести пример. SFTP протокол (шифрование, это дополнительная нагрузка на систему), файлы генерируются на лету и имеют размер около 5кб. С рабочего ноута нагрузку можно было создавать 200-250 запросов в секунду. Обычный хттп уходит за тысячу, максимум не смотрел, ибо и тысячи не надо было.
Ну если он еще с открытыми исходниками, то конечно в теории можно, вопрос насколько это просто)
Про генерацию на лету, самый простой пример. Как вы без неё будете логинить юзера? Вы же не подсунете ему идентификатор сессии в запрос.
Разный IP нужен крайне редко при нагрузке, по словам коллег еще ни разу не пришлось пользоваться в работе. А вот использовать разные данные в запросе надо часто.
У Jmeter ограничения только ресурсы машины, но даже несмотря на несколько большие требования (с тем же LoadRunner в сравнении он вообще дистрофик) проблем с этим не было ни разу даже при тестировании высоконагруженных промышленных систем. В крайнем случае можно использовать распределенный режим нагрузки.
Расширяемость это значит к примеру написать свой протокол, или сложную реализацию сценария. В jmeter к примеру есть для этого специальный интерфейс. Пока из описания продукта вижу, что он написан на функциональном языке что в теории даст большую производительность. Все остальное, что могут предоставить другие инструменты, либо не превосходит либо совсем отсутствует (отсутствие генерации разных запросов это гигантский минус). Да и высокая производительность плюс с натягом. Это разве что тестировать со слабой машины продукты, предназначенные для высокой нагрузки (сотни тысяч запросов в час). В общем, софтина получается применима далеко не везде и не всегда.
Ну и еще вопрос, оно сохраняет данные по запросам (цифры хотя б) в файлы или только графики само строит?
Какая там проводится оптимизация, и проводится ли она, мне не ведомо (авторы забугорные и прямого доступа к ним у меня не было). Но для тех целей, для которых её создали, аппетиты избыточны изначально, не говоря про протекания. Я привел пример с промышленных сред лишь потому, что вы слишком яро отрицаете влияние казалось бы таких мелочей. Часто в проме используются системы, которые должны обрабатывать неимоверное количество запросов, так что на производительности сказывается всё.
Доводилось тестировать банковское ПО, написанное программистами с вашим подходом. В системных требованиях сотни мегабайт ОЗУ и прочее. Под неполной нагрузкой ведет себя черте как. В чем проблема написать хотя бы для конкатенации строк в цикле более быстрый вариант вместо «ленивого» короткого? Не будут плодиться лишние сущности и задирать планку требований. На хабре кстати была статья именно про оптимизацию работы со строками на примере пром приложения.
При чем тут малошумность? Картинка как раз и свидетельствует о том что вопрос на данном этапе упирается в оптику и что разрабы это понимают. Не понимают это остальные к сожалению.
Я за эпплом не слежу, так что сужу только с ваших слов. Они доходчиво вешают лапшу на уши. Что значит делать линзу светлее? Менять её коэффициент преломления и соответственному форму? Или осветление нанесением покрытий, цель у которого несколько иная? Проблема шумов вообще не в оптической, а в электронной части. Как в матрице, так и в обрабатывающем канале. Более чувствительная матрица будет и шумов регистрировать больше. В чем суть то? Да и камеры у эппл, если я правильно помню, не 8 и не 12Мп как некоторые хотят, а только 5.
Возможно в микрооптике найдутся варианты (с световодами чтобы ужать в пространстве и изменить геометрию, может новые материалы появятся). Точнее не скажу ничего, в нашей стране этой областью по-моему вообще никто не занимается.
1) Примитивная линза.
У неё есть определенный радиус кривизны, значит при увеличении диаметра зрачка будет расти толщина.
2) Несколько линз.
Тут и говорить нечего что оно будет не худым.
Про генерацию на лету, самый простой пример. Как вы без неё будете логинить юзера? Вы же не подсунете ему идентификатор сессии в запрос.
Ну и еще вопрос, оно сохраняет данные по запросам (цифры хотя б) в файлы или только графики само строит?
У неё есть определенный радиус кривизны, значит при увеличении диаметра зрачка будет расти толщина.
2) Несколько линз.
Тут и говорить нечего что оно будет не худым.