Высоконагруженный сервер на Qt

>Высоконагруженный сервер на Qt

на VB пиши, на VB!

QT, не QT... масштабируемость в любом случае придется предусматривать. и еще не совсем понятно, что значит «обрабатывать»... что конкретнее предполагается делать с запросами клиентов?

> на VB пиши, на VB!

Главное погромче пернуть, чтобы все заметили, какой ты умный.

Предполагается, что клиент будет присылать запрос в виде plain-text или xml размером <= 10KБ, а сервер отвечать на него 10-50 КБ.

Сама обработка сводится к проходу по нескольким спискам и таблицам в памяти и небольшим расчетам.

6 наше всё

невижу ничего плохого в использовании

а чем жаба-то не устроила?

Зачем вообще писать [b]сервера[/b] на [b]QT[/b]? Что за необходимость?

а зачем вам вообще Qt нужен? в нём есть какие-то особые фичи, которых нет в java?

Устойчив к высокой нагрузке - это ГСМ какой-то. Могу посоветовать разве что к твоему qt еще boost asio и вперед.

Qt - это какой-то новый язык программирования?

по-моему, именно с Qt проблем для обеспечения требуемой производительности не должно быть. если списки и таблицы будут реализованы средствами Qt и будут хранится в памяти, то возможно хватит и одного потока для обработки запросов, на современном железе.

Да, и причём очень давно. Преемник дельфи.

Чтобы не писать на голом c++ ведь. Хотя писать сервер на с++ - вообще ссзб

Тебе архитектура масштабируемая нужна, тут дело не в Qt

И еще много будет значить что делаетя на самом сервере, если там запросик так где-то под 500 мс, то ты сам понял )) Главное не накосячь с потоками.

А лучше используй готовые масштабируемые решения. И С++ тут не в помощь

Видимо теперь будет QTсервер, брат зюзероутера.

Кутешные сокеты заюзать решил? Что-то я сомневаюсь, что они используют epoll, kqueue или overlapped io, чтобы юзать их под высокими нагрузками. Кутешные сокеты вообще дуршлаг тот еще.

Ой, увидел, что ответил не ТСу, но суть от этого не меняется

Вообще у куте довольно-таки жирный рантайм, в этой ситуации он будет только мешаться.

>возможно хватит и одного потока для обработки запросов, на современном железе

Если Qt юзает селект, о 5K обслуживаемых клиентов в одном потоке никакая речь идти не может

Намного лучше для этого Java NIO, которое как раз и юзает вышеописанных ребят под соответсвующими и юниксами и виндой. Но лучше просто взять и заюзать Grizzly, если хочется масштабируемого standalone

Writing scalable server applications in the Java™ programming language has always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to scale to thousands of users. The Grizzly NIO and Web framework has been designed to help developers to take advantage of the Java™ NIO API. Grizzly's goal is to help developers to build scalable and robust servers using NIO and we are also offering extended framework components: Web Framework (HTTP/S), Bayeux Protocol, Servlet, HttpService OSGi and Comet.

Я вообще-то на asio намекал, когда всё это перечислял :)

Можно и это в принципе. А если побольше готовенького, то просто Apache Thrift

А разве Qt умеет что-то кроме селекта?????

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

но в данном случае похоже проблема будет именно в трафике, который придется делить на несколько серверов.

Если qt для диспетчеризации использует poll или тем более select, то это не реально.

5К * 10Кб ~ 400Мбит/сек и в 10 раз больше от сервера к клиенту. Даже если не юзает селект, слабо себе представляю как оно поедет

а зачем вам вообще Qt нужен? в нём есть какие-то особые фичи, которых нет в java?

да, производительность.

По сабжу, бери да пиши, единственное могу посоветовать юзать напрямую вызовы методов вместо сигнал-слот, когда это возможно, оно даёт свои накладники иногда нафиг ненужные.

>да, производительность.
и на каких операциях (особенно высоконагруженных) вам не хватает скорости java?

Жаба - по определению тормозная хрень, учи матчасть. Разводить тут споры о рассовом превосходстве традиционного подхода «нормальный язык -> бинарник» перед «язык для быдлокодеров -> байткод -> интерпретатор» я не собираюсь, обсуждали тыщу раз, надоело, нравится вам жаба сидите епрст и наслаждайтесь. ЗЫ я уж молчу о том, что у меня даже JVM ни на одной из пользуюмых/обслуживаемых мной машин нету, за абсолютной ненадобстою каких бы то нибыло решений на так любой некоторыми жабе. А вот предлагать на каждом шагу, кто бы чего не хотел написать свою жабу не надо. Я же не лезу в треды с обсуждением как что-то сделать на жабе с советами юзать плюсы или D.

а много ли вы серверных приложений на плюсах знаете? а на Qt?

//слив засчитан

А много вы их знаете на жабе? У меня почему-то почти все серверные приложения написаны на С, есть кое-что сделанное для своих нужд на C++/Qt.

http://doc.qt.nokia.com/4.7-snapshot/network-threadedfortuneserver.html

>А много вы их знаете на жабе?

много. ссылку на какой-нибудь insight-it что ли привести?

Ладно я поставлю вопрос по другому. Почему я обслуживая стопку машин прекрасно обхожусь даже без JVM, уж молчу о наличии программа на жабе?! А вот без gcc/g++, никак?! VМоже таки это Вы преувеличиваете значение жабы для данного направления. Как ни крути C был, есть и ещё долго будет главным языком для серверного ПО.

Значит так.

1. Берешь qt
2. компиляешь arora
3. запускаешь
4. Валишь читать маны по erlang
???
6. PROFIT!

Beсь корпоративный мир вздрогнул от ужаса

> ссылку на какой-нибудь insight-it что ли привести?

Приведи. Увидишь, что рядом с жабой в большинстве случаев используются плюсы.

>языком для серверного ПО.
в данном случае речь идёт не об абстрактном «серверном ПО», а о конкретном самописном stateless сервере, который легко и непринуждённо пишется поверх NIO с помощью MINA или там Netty

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

не читал после фразы о рассовом превосходстве генератора сегфолтов над оптимальным соотношением производительности и продуктивности труда

>Приведи. Увидишь, что рядом с жабой в большинстве случаев используются плюсы.
ну вот, например, один из свежих примеров «тормозной» джавы:
http://www.insight-it.ru/masshtabiruemost/arkhitektura-mollom/

Продуктивность производительности труда быдлокодеров... точно я забыл... как же без них?!

не обижай архитектов google, ibm, oracle

Это был ответ на вопрос о серверных приложениях на плюсах, а не аргумент в пользу того, что Java тормозит и «не нужна».

еще и не правда что жабу не юзаешь. Когда догадаешся где она, то подумай, тормозит ли?

Расскажи где она?! О_о

>Вот только давай не будем

Вот только не надо. Любые «крутые корпоративные решения» — порнография. Исключительно из-за их громадных пространственных и *временнЫх* размеров. И уж кто-кто, а JVM в решении этих вопросов продвинулась дальше всех.