Разработать мини-ява вебсервер. Оплата 200 евро.
Подробности тут:
http://vingrad.ru/projects/361.html

Товарищ Wowa, а Вы форумом не ошиблись    Для найма специалистов есть отдельный форум  
Сейчас придет злой админ и Вас забанит   

п.с. пара вопросов
1. не совсем понятен данный пункт: "2. Если нет, то посмотреть в мемкеше на каком-нить другом сервере. Есть ли там такая инфа."
2. Это должен быть именно вебсервер, или это можно сделать на, скажем, TomCat-е?

Опишите подробней задачу.

Это сообщение отредактировал(а) Vasay - 25.4.2009, 17:51

объясняю. Планируется высокая нагрузка. Поэтому такие явовские веб-сервера будут запущены на N машинах.  Сначала смотрять наличие данных у себя в памяти, если их нет, то в распредленной кеш-системе мемкеш. К этой кеш-системе все сервера доступ имеют.



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

Есть еще вопросы? 

Wowa, 

Мне кажется, вы изобретаете велосипед. 

Не стоит гнаться за производительностью (особый прирост все равно не получите). Возьмите сервер приложений в связке с БД. Настройте connection pool. Как только производительности станет не хватать - создайте кластер и настройте балансировку нагрузки (можно делать отдельно для БД и сервера приложений).

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

Так как 200евро это не та сумма  за которую Вы найдете специалиста способного все грамотно написать. Все же, с учетом нагрузки, работа предстоит не простая. 

В Томкате необходимость есть. Потому, что кто-то должен слушать 80 порт, парсить http запросы и отправлять http ответы. Самим писать эту часть, т.е. http server,  давно уже нет необходимости. И этот "Томкат" (или что-то подобное) может быть как standalone , так и компонент сервера приложений. Самим надо писать подготовку ответа на запрос, всю эту логику - поискать там, поискать здесь и т.д. И это приложение (по сути, это сервис), которое будет заниматься подготовкой ответа, никакого отношения к словам web или http не имеет. Если только оно само не реализовано как веб сервис (но в этом нет острой нужды, если это сервис для внутренних нужд и в локальной сети).     


Это сообщение отредактировал(а) COVD - 25.4.2009, 21:22

да как же в этом нет необходимости, если это несколько строчек кода всего-лишь? Мне потому и нужна ява, чтобы не использовать громоздкий вебсервер. Иначе бы я Апаче заюзал или его легковесный вариант.

Добавлено @ 21:19
Запускается прога, которая висит в памяти и слушает все время заданный порт. Как только поступает определенный запрос, то прога его обрабатывает.

Добавлено @ 21:26
Вот и весь веб-сервер. С поддержкой тредов.

Вот этим Томкат и занимается. Больше ничем и не должен. Сервлет, пропарсив запрос, должен отослать параметры запроса на другое приложение (сервис, который что-то ищет в памяти или еще где),  дождаться ответа сервиса и переслать его клиенту. От Томката больше ничего не требуется. Это http server.  В Апаче функции, аналогичные  сервлету, выполняет cgi скрипт, очевидно. В обоих случаях (Апач или Томкат) не стоит возлагать на них что-либо кроме их прямой обязанности - обслуживания http запрос-ответ. 

Это сообщение отредактировал(а) COVD - 25.4.2009, 21:39

COVD, зачем мне томкат, если минимальный код выше делает все необходимое?

Так я вас не отговариваю, используйте свой код. Вы предполагаете, что ваш код лучше работает, чем Апач или Томкат? Или вы место на диске экономите? Они, по крайней мере, являются индустриальным стандартом. 

Это сообщение отредактировал(а) COVD - 25.4.2009, 21:48

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

Я не думаю, что отказ от стандартных http серверов решает проблему высокой нагрузки или является весомым вкладом. т.е. я согласен с мнением Vasay "Не стоит гнаться за производительностью..".

Wowa, 



Вы в этом так уверены? 

Тот код, который Вы привели до нормальной работоспособности еще писать и писать. 

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

Да, используя томкэт, у вас не будет проблем с балансировкой нагрузки - томкэт умеет работать на кластере.  

нужно ОЧЕНЬ много запросов обрабатывать. Поэтому любая экономия это огромный плюс. Load balancer кидал бы запрос к одному из сотни серверов(с этим вебсервером). Далее явапрога делала бы своё дело.

Добавлено @ 22:09

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

Добавлено @ 22:11

что еще нужно?

Добавлено @ 22:12

конечно уверен. Есть апаче, а есть lighthttpd, есть nginx. Это легковесные вебсервера и поэтому работают быстрее. А в моем случае даже их весь функционал не нужен.

Все зависит от задачи... Может и не будет проблем, может и будут. Как насчет сессий? Кто будет отвечать за их поддержание (если они нужны).





Придумать как обрабатывать и логгировать эксепшены. 

сессии не нужны.



если коннект не произошел, то он не произошел.  Если эксепшен на уровне ниже(например нет коннекта к БД), то его что с Томкатом, что без него обрабатывать надо.

Добавлено @ 22:48

Да нет там проблем. Все вебсервера незавимые друг от друга и помимо своего локального кеша, прикрыты центральным кешем-мемкешом(который через сокет работает). Поэтому даже если в локальном кеше какого-то сервера данных не будет, то он их с мемкеша получит. Данные кеша НЕ устаревают, т.е. отсутствует даже проблема их валидации. На один и тот же запрос всегда один и тот же ответ должен приходить.

Из заявленного бюджета это было не очевидно   .

Wowa, 

Ну Вам виднее. Думаю, вебсервер в Вашей системе будет далеко не самым узким местом, и вряд ли прирост производительности менее 10% стоит проблем, которые вы получите с написанием собственного вебсервера. 

Я писал в какой-то степени подобные вещи - на отладку уходит довольно много времени. Причем отладку на реальной нагрузке. Так как многие баги начинают выползать только тогда.  А потом переделал все под TomCat и прошла голова.  

Это сообщение отредактировал(а) Vasay - 25.4.2009, 23:07

хех 200 долларов - сумма хочу сказать )
хотя.. кризис... кто знает ))
Я бы на вашем месте сам бы взял и написал такую програмулю, тем более что задача интересная и, видимо, не очень стандартная, а как начнешь делать - там копать и копать, за 200 вряд ли кто то сделает качественно и до конца
НО это всего лишь имхо   

не долларов, а евро. Я не понимаю насмешек. Тут работы даже мне на день(я в Яве мало программил), ну максимум на два. Не пишу я сам, т.к. занят другой разработкой. Я не могу программить все части системы сам.

P.S. На ПХП такое я бы вообще за час написал. Проблема лишь в том, что на ПХП веб-сервер не сделаешь.



Да какие-же там 10%. Там гораздо больше. Иначе следуя твои словам все сервисы должны были бы через Томкат работать. Даже memcache или СУБД. Везде коннект напрямую.

Wowa, 



Ну так там не нужен http   

Томкэт пишется давно, применяется как основа для серверов приложений. Я думаю, он достаточно неплохо вылизан. Не напишут Вам за 200 евро столь же качественный продукт!  Сейчас напишут, Вы оттестите - вроде все ок,  а когда пойдет работа под нагрузкой - начнутся проблемы... а автора ищи потом. Знаем, плавали!  


Мне кажется, что зря Вы вообще, что-то изобретаете. Почему не воспользоваться готовыми решениями? Вы думаете что они будут медленней? Сильно сомневаюсь. 

Возьмите сервер приложений. Там все уже есть - и load balancing и распределенный кэшь. И головной боли не будет да и скорость всяко не ниже будет!

Так мы вас и пытаемся убедить, что не надо вам веб-сервер делать самому. Ни на ПХП, ни на Java.  Используйте Апач, а все остальное за час напишите.

Нужна работа на 80-ом порту, чтобы фаерволлами не блокировалось. http нужен лишь для того, чтобы браузер запрос правильно посылал и результат обрабатывал. Это фунционал реализован в приведенном мною коде выше.



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


Использоваться будут ведь готовые классы с java.net. А код и логика очень простые. Сомневаюсь, что проблемы будут из-за нагрузки будут.


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



Что я изобретаю? У нас есть Package java.net и с помощью него легко реализуется мини веб-сервер. Это готовое решение. Необходимо лишь добавить опрос локального и  распределенного кешов + базы, при необходимости.



У меня уже есть load balancing и кеш распределенный. Зачем мне сервер приложений.

Добавлено @ 00:38

Я не понимаю зачем мне Апач или Томкат. Если я могу сразу прогу повесить слушать 80-ый порт. Поступает запрос - отдаются данные. Всё.

Wowa, 

Хорошо - вопрос закрыт, Вам виднее.



Тогда разрешите пару замечаний по вашему объявлению:

- по-моему, Вы в ТУ забыли написать про заполнение кэшей.
- свой кэш - это тоже memcached, или его надо реализовать на сервере?

Снова вернусь к вопросу из своего первого поста 
"2. Если нет, то посмотреть в мемкеше на каком-нить другом сервере. Есть ли там такая инфа."

Что значит, "на каком-нить другом сервере"?  Как выбирается этот "какой-нить" сервер?


п.с. Если не секрет - сколько запросов в минуту Вы хотите обрабатывать?

я не удтверждаю, что мне виднее. В споре рождается истина. Но пока на мой взгляд никто так и не объяснил аргументированно, чем Томкат или Апаче лучше для данной задачи.



Если данных в кеше нет, то они извлекаются из источника(это может быть мемкеш, а если и там нет, то база), заносятся в кеш и отдаются юзеру.



свой кеш.. Это просто объект... Прога постоянно в памяти ведь висеть будет, а поэтому всё, что в объекте храним - будет доступно. Т.е. я предполгаю, что нужно просто добавлять новые данные в singleton объект и заводить ключ доступа к этим данным. Таких-вот мини-данных может быть очень много, фактически миллионы.. Есть возражения?



Есть методика, которая позволяет по ключу определить мемкеш сервер, на котором находятся данные соответствующие этому ключу.


Мне это очень сложно предположить. Но кол-во запросов будет расти постоянно и сильно. Т.е. мне нужно решение, которое будет обрабатывать максимально возможное кол-во запросов и горизонтально масштабируемое. Горизонтальное масштабирование мы получаем, если делать по предложенному мною варианту - т.е. куча серверов одиночек с возможность добавить любое кол-во доп. серверов. Все они имеют доступ к общему мемкешу и общей базе.

А максимально возможное кол-во запросов мы сможем обработать, если напрямую 80-ый порт слушать. Без использования доп. сервера.

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

P.S. и ведь чтобы что то взять нужно сначала что то положить? ))

Это сообщение отредактировал(а) nucer - 26.4.2009, 10:29

http://www.danga.com/memcached/

API:
http://code.google.com/p/memcached/wiki/Clients

Wowa. Теперь, наконец, стало понятно, что все, что вы хотели, это прикрутить пример java-client для memcached к вашему java-коду, реализующему http-server. И, действительно, PHP-client вы бы и сами прикрутили наверное за час. А Java вы решили использовать, чтобы ускорить обработку http запросов. И это не подвергается сомнению. Рассуждения Томкат vs ваш код основывались на общих соображениях готовое vs самописное. Но, оказалось, что вам логгирование не нужно, сессии не нужны. Наверное, и авторизация и пул потоков тоже не нужны. Или вы потом добавите.

 




  

Это сообщение отредактировал(а) COVD - 26.4.2009, 13:35

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

Wowa,  Вы уж извините, что мы вместо того, что бы предлагать свои услуги развели тут базардискуссию. Просто раздел форума к этому располагает 




Есть. И опять сводится к  "готовое vs самописное" Не думаю, что есть смысл реализовывать систему кэша самому. Ведь я так понимаю, нужно контролировать размер, замещать старые объекты... Есть готовые решения: Java Caching System По русски: http://www.ibm.com/developerworks/ru/libra...&S_CMP=GR01  Да можно и memcached поднять.

Если есть запас памяти, чтобы сразу выделить ее под потоки, так и оправдан. Вот кстати пример http://java.sun.com/j2se/1.5.0/docs/api/ja...torService.html

Есть вариант использовать Grizzly + Jersey для решения этой задачи. 
Скажу сразу: я имел опыт работы с Jersey, а Grizzly только "щупал" и не могу 100% утверждать что это решение подойдет. Хотя у меня есть ощущение что это то что нужно. 
Что эта связка даст:
1) Маленький, шустрый, построенный на базе NIO многопоточный http сервер, который работает в embedded режиме. 
2) Переносимые RESTful сервисы c обменом данными по http-протоколу. 
3) Звучит громоздко, но на самом деле это все очень легковесные решения.

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

P.S.: Что касается кэшей и прочей оптимизации, то тут нужно смотреть по факту - выявлять узкие места на рабочем сервисе. Техническая возможность для оптимизации в случае использования вышеуказанного решения имеется. (В XP программирование есть такой принцип YAGNI - You Ain't Gonna Need It - "не делай того что тебе в последствии не понадобится", а еще есть анти-паттерн "предварительная оптимизация" ;-)

Попробую пристроить свою статью в этот топик

Это нормально. Поэтому я тему сюда и поместил. Существует много способов сделать эту задачу и дискуссия позволит выбрать мне наиболее подходящий.



Боюсь, что действительно громоздно выйдет и получится зависимость от этих систем и от разработчика. Чтобы делать с использованием этих систем "как надо" должен бюджет выше быть. Но в целесообразности их использования для этого проекта я сомневаюсь. Слишком лишь простые вещи "мини-сервер" делать должен.



memcached итак есть. Но он не панацея, т.к. это распределенный кеш. Его нужно дергать через сеть. Когда запросов много, то сеть также не выдерживает. Именно поэтому я хочу опрос сначала локального кеша делать, лишь потом смотреть в мемкеше и базе.



Спасибо за инфу. Запас памяти есть и я готов выделять сервера лишь под работу этого мини-сервера. Т.е. например, можно 4-8Гб выделить. Если нужно, можно и больше.

Ну, в данном случае громоздкость это примерно 3 - 4 Мб библиотек, а по разработке/отладке значительно меньше усилий нежели написание своего микро-сервера. Что касается производительности, то я и предлагаю её проверить на прототипе. От разработчика точно нет зависимости - все технологии просты, открыты и хорошо документированы. Да и с учетом планируемой вами простоты системы такая зависимость маловероятна. 



В том то и смысл, что написание очень простой логики не должно требовать написания мини-сервера с нуля... высока вероятность что это можно сделать "малой кровью". По крайней мере у меня такое ощущение. 

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

Я и имел ввиду локально. Просто, зачем программировать свой кэш для этого пункта "1. Посмотреть в у себя кеше, если такая инфа есть, то вернуть её", когда есть готовые решения. Тот же Java Caching System, или если Вы привыкли работать с memcached, то почему его не использовать не только для распределенного кэша, но и для локального (т.е. поднять локально на том же компьютере где и web сервер)?