Комментарии 8
Извините, я немного не в теме C#, но
Это как? О какой тут скорости идёт речь? Тонкий клиент медленнее из-за сетевого взаимодействия? А как толстый клиент с JVM обшается? Это быстро?
Ситуация с .NET осложняется тем, что внутри процесса стартует JVM, потребляя немало ресурсов и внося дополнительные требования к окружению.
Скорость работы тонкого клиента всегда будет чуть ниже, так как он работает через посредника.
Это как? О какой тут скорости идёт речь? Тонкий клиент медленнее из-за сетевого взаимодействия? А как толстый клиент с JVM обшается? Это быстро?
Представим узлы кластера А и Б, толстый клиент К, тонкий клиент Т подключен к узлу А.
При попытке извлечь данные, находящиеся на узле Б, толстый клиент отправит запрос напрямую. Тонкий же работает только через узел А.
А как толстый клиент с JVM обшается? Это быстро?
Через JNI и указатели на unmanaged (offheap) память. Да, это намного быстрее сокета.
А нельзя ли «толстую» версию клиента через IKVM запустить? Насколько это будет стабильно и быстро?
У меня уже был опыт использования JMS через IKVM — работало нормально.
У меня уже был опыт использования JMS через IKVM — работало нормально.
Ради прикола попробовать можно было бы, но для продакшна это точно не решение.
Да и проект IKVM загнулся, к сожалению.
http://weblog.ikvm.net/2017/04/21/TheEndOfIKVMNET.aspx
Добавлю, что типичный оверхед на JNI составляет несколько десятков наносекунд. Reverse JNI на момент замеров (JDK 7) был немного медленнее, чем прямой. В рамках распределенной системы, где типичный latency измеряется миллисекундами, оверхед JNI амортизируется практически в ноль.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Apache Ignite.NET 2.4: Тонкий и кроссплатформенный