Каморка

Всем привет

Вопрос теоретический. В обозримом будущем надо будет писать сервер (без ГУИ) который должен будет бежать на различных платформах (Win32/Win64/Unix/Linux)
По функциональности это TCP/IP сервер способный одновременно обслуживать много подключений. Подключение может быть на пару секунд или на часы (в зависимости от бизнес логики). Сервер может читать большие текстовые файлы (в зависимости от запроса клиента) и делать вычисления (нагружать CPU). Доступ к базам данным есть. С обработкой видео стима или игр никак не связано. Вот вкратце и все.

Вопрос - на чем его лучше писать - на Джаве или С++ ?
Или по другому - чем плоха Джава в этом случае ?

Я разговаривал с программистами на Джаве - они в одни голос говорят что Джава в этом случае ничем не проигрывает (включая перформанс)
Я это беру под сомнение (поскольку сам из С/С++) но это только предчувствие.
Джавники просили представить хоть один сценарий где-бы Джава проигрывала С/С++ для серверных апликаций. Кто-нибудь знает такой сценарий ?

С другой стороны много серверов НЕ написано на Джаве - например MySql

..... сижу в раздумьях

Как джавист могу сказать что таки-да, Java не проигривает если не надо заниматься всякой экзотикой..
А как прагматик я бы посоветовал писать на том, что ближе и более знакомо.

В целом если сервак регулярно ждет на IO, то абсолютно пофиг, Java или C++.
Но если нужно выжать из CPU(a особенно GPU) все, что только можно, то C++ предпочтительнее.
BTW, существует куча баз данных написанных на Java, просто исторически они не стали очень популярными.

Ах, да, и еще, при прочих равных, Java потребует в 2 раза больше памяти...

Не знаю какой именно сервер будет и что именно надо, но на всякий случай предложу посмотреть в сторону tntnet. Может пригодится. Интересный проект. (на серверпейджность можно просто не обращать внимания, мне эта часть как раз не нравится.)

Marmot писал(а):Как джавист могу сказать что таки-да, Java не проигривает если не надо заниматься всякой экзотикой..
А как прагматик я бы посоветовал писать на том, что ближе и более знакомо.

В целом если сервак регулярно ждет на IO, то абсолютно пофиг, Java или C++.
Но если нужно выжать из CPU(a особенно GPU) все, что только можно, то C++ предпочтительнее.
BTW, существует куча баз данных написанных на Java, просто исторически они не стали очень популярными.

Ах, да, и еще, при прочих равных, Java потребует в 2 раза больше памяти...

хммм.... а почему Джаве в два раза больше памяти надо ?

Это зависит у кого какая прагрматика
Есть люди с амбициями, которые станут писать на С++, чтобы держать все под своим контролем.
Смещение в сторону Java и .Net очевидное, что делает количество людей активно заинтересованых в С++ все меньше и меньше. Основная причина - скорость разработки и стоимость поддержки. Железо при необходимости можно купить за разумные деньги, чтобы гонять на нем навороченные Java сервера. Жалобы на заметное падение производительности в основном от промахов в коде. После прогона через профайлер глаза открываются и причины тормозов видны сразу в виде бесчисленных toString или строковых конкатенаций, что поправимо.

А памяти больше по причине более объемных библиотек и code safety, пр. Но опять таки память можно добавить а сервера сделать load balanced.

Мое личное мнение: если речь идет о десятках конкурентных коннекций, то имеет смысл рассмотреть яву, если о сотнях то с или с++.
Выравнивание нагрузки на нескольких сереврах, из моего опыта, выливается в довольно большой гиморрой обычно, и если етого можно избежать то лучще избегать.

Ну и в загашник ссылка, вдруг окажется полезной (особенно ссылки на етой ссылке): http://kano.net/javabench/

aissp писал(а):Мое личное мнение: если речь идет о десятках конкурентных коннекций, то имеет смысл рассмотреть яву, если о сотнях то с или с++.

Не мнение, а чисто практический опыт: имеется в продакшне 10 серваков, когда каждый одновременно держит 7К коннектов.
В стресс-тестах это число доводили до 30К. Усе работало. Написано на Java...

Ну сам понимаешь так считать несовсем корректо - а сколько сишный бы сервер потянул? А какие сервера в железе? А что делают они? Открывают закрывают коннект? Мне кажется, уже при 1000 конкурентных коннектах и при скольконибудь сложном диалоге клиент сервер - приходиться писать свой мемори аллокатор как для входяших так и для исходяших пакетов, заодно оценивать время жизни пакета в системе. Короче, занимаься профайлингом. Рад за яву если ошибаюсь. Но мне кажется говорить что ява быстрее сей - ето не очень корректно. Я согласен что "дурно" написанный код на си будет работать хуже "хорошего" кода на ява, более того скорее всего дурной код на си будет работать хуже дурного кода на яве, но вот обратное мне кажется неверным.

поиск по словам 20k problem там обычный пентиум на си держал 20000 коннектов ява такое могет?

не в коем мере не меряюсь длинной коннекта, просто мнение, рад буду в нем разочароваться.

aissp писал(а):Ну сам понимаешь так считать несовсем корректо - а сколько сишный бы сервер потянул? А какие сервера в железе? А что делают они? Открывают закрывают коннект?

Сишный потянул бы больше, но и писать и отлаживать его бы пришлось намного больше...
Сервак неслабый - 8 кОров
Делают они много чего, но самое интересное это мультиплексирование датабазных операций.
Коннект держится постоянно

aissp писал(а):Мне кажется, уже при 1000 конкурентных коннектах и при скольконибудь сложном диалоге клиент сервер - приходиться писать свой мемори аллокатор как для входяших так и для исходяших пакетов, заодно оценивать время жизни пакета в системе. Короче, занимаься профайлингом. Рад за яву если ошибаюсь.

Если честно, то в моем случае 80% CPU уходит на перемещение байтов, хотя я и очень сильно это минимизировал. Бесспорно, на С это можно было бы сделать намного оптимальнее...

aissp писал(а):Но мне кажется говорить что ява быстрее сей - ето не очень корректно.

Абсолютли, но на Java быстрее разработка и проще поддержка, на мой взгляд

aissp писал(а):поиск по словам 20k problem там обычный пентиум на си держал 20000 коннектов ява такое могет?

Могет, могет, с тех пор как ее научили использовать epoll, ну и что там на Винде...
Тока памяти надо побольше...

iocompletion port на Виндах. В такой редакции соглашусь Запиши что консенсус достигнут

dima писал(а):Вопрос теоретический. В обозримом будущем надо будет писать сервер (без ГУИ) который должен будет бежать на различных платформах (Win32/Win64/Unix/Linux)

Как-то совсем не коретно ставишь вопрос... Поэтому я бы посоветовал - пиши на джава.
Не знаю конечно как джава, но его аналог код C# .NET компилирует машинный код в рантайме. Почитай последние .NET статьи небезизвестного тебе Рихтера (если он конечно авторитет для тебя) про производительность .NET. В джава наверное тоже также - машинный код компилируется в рантайме. Впрочем не знаю. Пусть джависты здесь подскажут.

Про C/C++ могу только добавить, что написать масштабируемое серверное приложение для Windows - только IOCP. Все остальное - глупости и пустая трата времени. Но с IOCP несмотря на простоту дизайна есть много подводных камней. Так что если не писал - то оставь это.

Marmot писал(а):Если честно, то в моем случае 80% CPU уходит на перемещение байтов, хотя я и очень сильно это минимизировал. Бесспорно, на С это можно было бы сделать намного оптимальнее...

Да вряд ли будет очень уж оптимальнее. Если bottleneck в IO, то здесь ни Java, ни C++ значительной роли не играют. Удобнее и быстрее в десятки раз будет написать на том же Python, используя Python Twisted. Никакого тебе дерьма в лице multi-threading, всё чисто и красиво.

badger писал(а):

Marmot писал(а):Если честно, то в моем случае 80% CPU уходит на перемещение байтов, хотя я и очень сильно это минимизировал. Бесспорно, на С это можно было бы сделать намного оптимальнее...

Да вряд ли будет очень уж оптимальнее. Если bottleneck в IO, то здесь ни Java, ни C++ значительной роли не играют. Удобнее и быстрее в десятки раз будет написать на том же Python, используя Python Twisted. Никакого тебе дерьма в лице multi-threading, всё чисто и красиво.

На питоне писать к сожалению не рекомендую, иначе рано или поздно упретесь в проблему с отсутвием нормального тридинга и как следствие невозможностью полноценно задействовать ресурсы современных и будущих многоядреных процов. К сожалению разрабочкики питона забили болшой и толстый болт на проблему. А зря, хороший язык (был). Проблему знаю не по наслышке - сами на ем уже лет 7 пишем серьезные серверные приложения, сейчас чешем репу что делать....

Как серьезная альтернатива жабе - C#.

-Maxim

sobomax писал(а):На питоне писать к сожалению не рекомендую, иначе рано или поздно упретесь в проблему с отсутвием нормального тридинга и как следствие невозможностью полноценно задействовать ресурсы современных и будущих многоядреных процов. К сожалению разрабочкики питона забили болшой и толстый болт на проблему. А зря, хороший язык (был). Проблему знаю не по наслышке - сами на ем уже лет 7 пишем серьезные серверные приложения, сейчас чешем репу что делать....

Зависит от требований. Те сервера, что я писал на Python (CPython), справляются с нагрузкой лучше, чем то, что использовалось до того, написанное на Java с потоками.

А GIL естественно зло, что поделать. Но для страждущих есть тот же Jython. Правда, как я сказал, мне хватало CPython.

А язык Python по-прежнему хороший. И Python3K видится даже лучше. К сожалению у другого хорошего языка, Ruby, нет такой продуманной организационной политики развития языка.

badger писал(а):Те сервера, что я писал на Python (CPython), справляются с нагрузкой лучше, чем то, что использовалось до того, написанное на Java с потоками.

Плохо написать можно на любом языке, это не очень хороший показатель.

-Maxim