было бы идеально, если бы JB вкладывалась в скалу, только слабо себе представляю как: использвание скалы вместо своего языка? Боюсь тогда бы качество их продуктов зависело бы от сторонней организации (Кто там скалу сейчас разрабатывает, все еще тот институт в Швейцарии?).
Если только jetbrains сделали бы партнером, включили бы в стостав основателей и т.д. (или как там это делается), чтобы они тоже могли ее разрабатывать или фиксить, тогда еще ладно. Все таки JB контора известная своим качеством в первую очередь, поэтому лишние стороннние баги им ни к чему.
такие же мысли: так и не увидел до сих пор удачного использования js движка в жава коде. Как только заходит разговор о скриптах, обычно советуют python или groovy
Какие управляющие слои и слои инфраструктуры новейших технологий будут использоваться для обеспечения функционирования облачных сервисов? В течение двух лет большинство из них будет написано на Go
выходит гугл для инфраструктуры в основном go собирается использовать? т.е. та ниша на которой erlang сейчас развивается.
Так понял что андройд на go вряд переводить будут.
разница в том что эти 6% уйдут из под вашего контроля в страховую часть пенсии которой государство покроет текущую дыру в фонде. И вот что с ними будет через 20-30 лет и не выйдет ли еще какой-нибудь закон касательно уменьшения страховой части — вот это вопрос.
Думаете стали бы в думе так законы плодить если размеры выплат не меняются?
лоджию стены и пол утеплил, остались окна: интересует цена вопроса и у каких контор такое остекление лучше заказывать.
Вы пишите 30 тыщ на окна ушло? Если вместе с работой то довольно бюджетно даже несмотря что 3 года назад было. А какая контора делала если не секрет?
а у него экран как то отличается чтоль?
Смотрел характеристики — вроде такой же: «сенсорный экран мультитач (емкостный)», почему у остальных нет такой функции («режим перчаток» вроде называется).
Чтобы не создавалось впечатления, что «Оракл во всём виновата» замечу, что Java конечно популярна не только потому что это Оракл (или ранее Sun) продавила — если бы в Java не было бы кое-каких действительно революционных для совего времени технологий, то как бы Sun не пыжилась — ничего бы не получилось.
именно, ну собственно эти революционные технологии появились на java просто потому что на ней проще и быстрее было их создавать и развивать как опенсорс, чем например на cpp, который конечно и мощнее и быстрее и т.д.
даже DAG в каком-то виде используется )
Спасибо за обзор, но хотелось бы побольше аналогий с хадупом, технологии то параллельные, поэтому интересно есть ли аналоги фич одного в другом и т.д. чтобы как то потом сравнивать их.
Почитал исходный код. Если вы получаете 30Krps на таком тесте,
30К может и предел, но получаю я их описанным в посте способом т.е. с использованием таймера, где сокеты тоже переоткрываются естественно. И тогда мне неясно почему Вашим методом я получаю только 10К на той же машине в тех же условиях?
Кстати вы его не закрываете;-)
он там неявно закрывается из br.close(), на всякий случай добавил явно — ничего не поменялось
тыща потоков дает на моей машине где то 8 тыщ rps, 4 тысячи потоков => 10K rps, дальнейшее увеличение потоков прироста rps не дает.
Как мне добиться 30K rps которые я на этой же машине получаю с помощью таймера?
Как только соединение освобождается, отсылается новый запрос. В итоге 1000 сокетов будет использоваться настолько быстро, насколько быстро отвечает сервер. Так и определим максимальный RPS, который может отдавать сервер.
Вы не поняли. Задача такого теcта «быстро оценить максимальную пропускную способность», чтобы потом уже проводить тесты около неё, эмулируя боевую.
А как в этом бесконечном цикле понять что соединение закрылось? Что-то вроде своего пула сокетов, и как только какой-то освобождается нотифицировать все потоки и посылать в этот сокет?
Дело не только в RPSе, дело в протоколе. дело в самой подаче нагрузке даже с обычным таймером. С таймером, у вас запросы идут на сервер с равномерным распределением.
не совсем так, с равномерным распределением мы коннектимся к серверу, а у ж как только коннект асинхронно отработает — посылаем запрос. Это конечно не Пуассоновское распределение, но вся эта асинхронность тоже вносит определенный элемент случайности.
Кмк, это изначально лучший путь, т.к. у того проекта уже есть community и куча фич, включая требования.
в целом я согласен, что когда нужно хотя бы несколько фич из этой кучи, а там уже и community и все остальное, тогда безусловно, но если просто нужно дернуть какой-то метод из своего легаси кода при генерации контента запроса — с этим как, или он это тоже может?
Нет, вообще без таймеров
while(1) { do_request(); }
Но это вроде бы не совсем эмулирует боевую нагрузку: там же каждый раз новые соединения создаются а не старые переиспользуются как у вас.
И сколько максимально rps вам удавалось добиться таким способом? на localhost-е и на удаленный сервер в локальной сетке например?
Yandex.Tank он на питоне? Тогда сдается мне что это не быстрей простого netty при прочих равных — таже реализация NIO через виртуальную машину (питона в данном случае)
Gatling Tool тоже монстр +на scala, это конечно не проблема, но порог вхождения есть: dsl, статистика, гуй, интерграция всего со всем… сомневаюсь что это все добавляет быстродействия к netty, который там внутри.
+опять же если совсем свою логику дергать надо для генерации запроса, которая в коде твоего проекта лежит то как?
Про 1000 сокетов не понял — вы ставите в туле ограничение на 1000 сокетов/потоков и в каждом таком потоке посылаете по таймеру запросы?
я раньше думал так только испанцы и итальянцы живут, социализм же и есть, раз пособие до 27, налоги все покрывают видимо
мне только непонятно, как при всем этом они впереди европы всей, делают лучшие машины и механизмы — или это просто сейчас у них время такое настало или это нерепрезентативная выборка?
Если только jetbrains сделали бы партнером, включили бы в стостав основателей и т.д. (или как там это делается), чтобы они тоже могли ее разрабатывать или фиксить, тогда еще ладно. Все таки JB контора известная своим качеством в первую очередь, поэтому лишние стороннние баги им ни к чему.
выходит гугл для инфраструктуры в основном go собирается использовать? т.е. та ниша на которой erlang сейчас развивается.
Так понял что андройд на go вряд переводить будут.
Думаете стали бы в думе так законы плодить если размеры выплат не меняются?
Вы пишите 30 тыщ на окна ушло? Если вместе с работой то довольно бюджетно даже несмотря что 3 года назад было. А какая контора делала если не секрет?
Смотрел характеристики — вроде такой же: «сенсорный экран мультитач (емкостный)», почему у остальных нет такой функции («режим перчаток» вроде называется).
именно, ну собственно эти революционные технологии появились на java просто потому что на ней проще и быстрее было их создавать и развивать как опенсорс, чем например на cpp, который конечно и мощнее и быстрее и т.д.
Спасибо за обзор, но хотелось бы побольше аналогий с хадупом, технологии то параллельные, поэтому интересно есть ли аналоги фич одного в другом и т.д. чтобы как то потом сравнивать их.
30К может и предел, но получаю я их описанным в посте способом т.е. с использованием таймера, где сокеты тоже переоткрываются естественно. И тогда мне неясно почему Вашим методом я получаю только 10К на той же машине в тех же условиях?
он там неявно закрывается из br.close(), на всякий случай добавил явно — ничего не поменялось
Так?
тыща потоков дает на моей машине где то 8 тыщ rps, 4 тысячи потоков => 10K rps, дальнейшее увеличение потоков прироста rps не дает.
Как мне добиться 30K rps которые я на этой же машине получаю с помощью таймера?
А как в этом бесконечном цикле понять что соединение закрылось? Что-то вроде своего пула сокетов, и как только какой-то освобождается нотифицировать все потоки и посылать в этот сокет?
не совсем так, с равномерным распределением мы коннектимся к серверу, а у ж как только коннект асинхронно отработает — посылаем запрос. Это конечно не Пуассоновское распределение, но вся эта асинхронность тоже вносит определенный элемент случайности.
в целом я согласен, что когда нужно хотя бы несколько фич из этой кучи, а там уже и community и все остальное, тогда безусловно, но если просто нужно дернуть какой-то метод из своего легаси кода при генерации контента запроса — с этим как, или он это тоже может?
Но это вроде бы не совсем эмулирует боевую нагрузку: там же каждый раз новые соединения создаются а не старые переиспользуются как у вас.
И сколько максимально rps вам удавалось добиться таким способом? на localhost-е и на удаленный сервер в локальной сетке например?
+опять же если совсем свою логику дергать надо для генерации запроса, которая в коде твоего проекта лежит то как?
Про 1000 сокетов не понял — вы ставите в туле ограничение на 1000 сокетов/потоков и в каждом таком потоке посылаете по таймеру запросы?
мне только непонятно, как при всем этом они впереди европы всей, делают лучшие машины и механизмы — или это просто сейчас у них время такое настало или это нерепрезентативная выборка?
и кстати кто их развратил, этот ихний социализм опять же?