Справедливости ради, факт встречи человека, который вообще рассматривает вариант перемещения по Женеве за рулём, а не на общественном транспорте (на крайняк такси) тоже достаточно неожиданный ;)
А можете побенчмаркать, сколько он через OpenVpn и Wireguard сможет прокачать? В качестве сервера и в качестве клиента?
Я тоже планирую подобное собрать, пытаюсь определиться с процессором, в идеале чтобы хватило полностью забить как минимум 1 гигабит (а то и 2.5 в пике), при этом держать 2-3 впн-сервера для 4-8 клиентов и 2-3 клиентских подключения к сторонним ВПН-серверам.
Вообще, в ConcurrentQueue не так уж много локов. На самом деле из конкурентной троицы Queue-Stack-Bag она самая быстрая (на моём опыте).
Любопытно было бы взглянуть, что её так убило.
… ок, приврал, ConcurrentQueue быстрее стека, ConcurrentBag легче, но это другая история.
Спасибо за ссылку, о паре нюансов даже не задумывался.
Но всё это не отменяет моего удивления: мой случай идеален для SpinLock: очень короткая операция, количество потоков меньше количества ядер, очень низкий или нулевой contention — казалось бы, почему Monitor/Lock заметно лучше? Если бы было +- одинаково — не было бы вопросов.
… по следам этого доклада, прогнал бенчмарк для new SpinLock(false): быстрее дефолтного, но в случае с (около)нулевым контеншном всё равно медленнее lock'a, в случае с высоким контеншном — быстрее.
Позор, конечно, что я упускал это раньше.
Немного не в тему, но всё-же: а пробовали сравнивать производительность SpinLock и Monitor?
К моему удивлению, Monitor работает быстрее, по крайней мере в случаях, когда в основном ему не приходится блокировать поток(и).
Честно говоря, считал, что СпинЛок должен быть гораздо дешевле и шустрее.
Ну, рельный юз-кейс же, никем (судя по всему) не поддерживаемый :)
Я бы на месте производителя как минимум проанализировал бы, чисто для расширения кругозора.
Кстати, тут была статья какое-то время назад, люди импортозамещают библиотеки для работы с ПДФ — отличный фич-реквест для них был бы, по-моему, и конкурентное преймущество ;)
Сам не пользовался, мы просто перевели весь транспорт на свой велосипед.
Ну а хостить джава-машину, чтобы генерировать ПДФ — это круто :)
Использовали несколько разных ПДФ-генераторов, не знаю ваших требований к генерируему документу, но наши покрывались полностью.
У нас, на пример, ещё были зависимости от CallContext и самописных ХТТП-модулей, ничего, нашли замены/переписали.
Я к тому, что если хочется перейти — то надо собраться и пару недель посвятить пруф-оф-концептам, а дальше всё (относительно) просто.
По своему опыту — рекомендую.
С продуктами ХП у меня был перерыв на много лет, теперь за почти год использования Zbook studio g9 никаких проблем, только положительные эмоции, вторая такая же машина из этой же поставки — тоже без проблем.
Не тротлит, кстати, с охлаждением i9 справляется, уж не знаю, в разрекламированной ли испарительной камере дело или ещё в чём.
Справедливости ради и пресижнами у меня тоже проблем не бывало, а вот с ThinkPad P1 — случалось: и матери дохли, и батарея вспухала, и вентиляторы шумели и дохли, и с доками родными никак не дружил.
У Zbook Studio G9 i9, 64гб, 2 слота м2 и нвидиа rtx a5000, так что попросил бы.
А разница во времени между ними — 1 поколение процессоров Интел, т.е. примерно год.
А можете добавить в бенчмарки измерение аллокаций и GC?
Справедливости ради, факт встречи человека, который вообще рассматривает вариант перемещения по Женеве за рулём, а не на общественном транспорте (на крайняк такси) тоже достаточно неожиданный ;)
Буду благодарен.
ОпенВПН сервер на ОпенВрт тоже поднять совсем несложно, очень бы помогло, если и его сможете протестировать.
А можете побенчмаркать, сколько он через OpenVpn и Wireguard сможет прокачать? В качестве сервера и в качестве клиента?
Я тоже планирую подобное собрать, пытаюсь определиться с процессором, в идеале чтобы хватило полностью забить как минимум 1 гигабит (а то и 2.5 в пике), при этом держать 2-3 впн-сервера для 4-8 клиентов и 2-3 клиентских подключения к сторонним ВПН-серверам.
Вообще, 150 Мбит это очень скромно, если не сказать прямо: неприемлимо мало.
Сам пытался найти бенчмарки чтобы подобрать железо — нереально.
Вообще, в ConcurrentQueue не так уж много локов. На самом деле из конкурентной троицы Queue-Stack-Bag она самая быстрая (на моём опыте).
Любопытно было бы взглянуть, что её так убило.
… ок, приврал, ConcurrentQueue быстрее стека, ConcurrentBag легче, но это другая история.
Спасибо за ссылку, о паре нюансов даже не задумывался.
Но всё это не отменяет моего удивления: мой случай идеален для SpinLock: очень короткая операция, количество потоков меньше количества ядер, очень низкий или нулевой contention — казалось бы, почему Monitor/Lock заметно лучше? Если бы было +- одинаково — не было бы вопросов.
… по следам этого доклада, прогнал бенчмарк для new SpinLock(false): быстрее дефолтного, но в случае с (около)нулевым контеншном всё равно медленнее lock'a, в случае с высоким контеншном — быстрее.
Позор, конечно, что я упускал это раньше.
Немного не в тему, но всё-же: а пробовали сравнивать производительность SpinLock и Monitor?
К моему удивлению, Monitor работает быстрее, по крайней мере в случаях, когда в основном ему не приходится блокировать поток(и).
Честно говоря, считал, что СпинЛок должен быть гораздо дешевле и шустрее.
Кстати, под NET Core вполне можно было оставаться на EF6 и спокойно дожидаться, пока они доделают необходимые фичи.
Ну, рельный юз-кейс же, никем (судя по всему) не поддерживаемый :)
Я бы на месте производителя как минимум проанализировал бы, чисто для расширения кругозора.
Кстати, тут была статья какое-то время назад, люди импортозамещают библиотеки для работы с ПДФ — отличный фич-реквест для них был бы, по-моему, и конкурентное преймущество ;)
https://habr.com/ru/articles/739114/
Multi-target компиляция общих библиотек с минимально необходимым количеством #if NETFRAMEWORK #else?
… но в целом, конечно, согласен — вполне себе ограничение.
http://blogs.msdn.com/b/dotnet/rss.aspx
http://blogs.msdn.com/b/visualstudio/rss.aspx
Это чтобы ничего не пропускать ;)
По ПДФ — не скажу, плотно ПДФом занимались другие люди, некоторые требования выглядят знакомо, насчёт других — не уверен.
Выше правильно подсказали — вынести в отдельный сервис.
… мы переезжали на NetCore 3.1, тоже было вполне решаемо при желании/необходимости.
Смотрели такое?
https://devblogs.microsoft.com/dotnet/corewcf-v1-released/
Сам не пользовался, мы просто перевели весь транспорт на свой велосипед.
Ну а хостить джава-машину, чтобы генерировать ПДФ — это круто :)
Использовали несколько разных ПДФ-генераторов, не знаю ваших требований к генерируему документу, но наши покрывались полностью.
У нас, на пример, ещё были зависимости от CallContext и самописных ХТТП-модулей, ничего, нашли замены/переписали.
Я к тому, что если хочется перейти — то надо собраться и пару недель посвятить пруф-оф-концептам, а дальше всё (относительно) просто.
По своему опыту — рекомендую.
А почему невозможно? Какие неразрешимые технические причины?
А что там в этом spring boot?
Web server, насколько я понял? Ещё что-то "крупное"?
А не смотрели профайлером, что именно отжирает СТОЛЬКО памяти в жава-приложении? — детализацию бы глянуть.
Мне это чисто из любопытства, я из.нета, просто поразило НАСКОЛЬКО джава-вариант плох.
С продуктами ХП у меня был перерыв на много лет, теперь за почти год использования Zbook studio g9 никаких проблем, только положительные эмоции, вторая такая же машина из этой же поставки — тоже без проблем.
Не тротлит, кстати, с охлаждением i9 справляется, уж не знаю, в разрекламированной ли испарительной камере дело или ещё в чём.
Справедливости ради и пресижнами у меня тоже проблем не бывало, а вот с ThinkPad P1 — случалось: и матери дохли, и батарея вспухала, и вентиляторы шумели и дохли, и с доками родными никак не дружил.
Ну это уже ни к весу, ни к мощности не относится.
… в сравнимых комплектациях пресижн всё время выходил на несколько сотен дороже з-бука.
У Zbook Studio G9 i9, 64гб, 2 слота м2 и нвидиа rtx a5000, так что попросил бы.
А разница во времени между ними — 1 поколение процессоров Интел, т.е. примерно год.