IMXO. тут трудно спорить, судя ГОСТУ — они оба синхронные:
Basic.Consume (ID=10) start
a queue consumer: Sync request, carries content
Basic.Get (ID=80) direct
access to a queue: Sync request, carries content
но по своей сущности Consume — синхронный запрос, как только сообщение появляется в очереди, оно сразу считывается (передается клиенту), коннекция держится постоянно. в этом смысле — синхронный.
методом GET ты можешь забрать сообщение в любое время из очереди (или пустое уведомление GET-EMPTY). коннекцию постоянно можно не держать. в этом смысле — асинхронный. Хотя если смотреть с иной стороны, как только мы выдаем GET, мы сразу получаем (синхронно) ответ: либо GET-OK либо GET-EMPTY, т.е. синхронный.
нет, это планируется сл. этапом.
пока идет только обкатка сервера
в настоящее время amqp запрос осуществляется методом BASIC.GET (асинхронный)
планирую разработку синхронного запроса BASIC.CONSUME
тогда без comet технологии не обойтись.
сказать что Яндек использует Oracle MySQL и PostgreSQL — это ничего не сказать. У Яндекса много подпроектов и в каждом используется своя БД. Сам поисковик индекс хранит в специализированном формате. Я на Конференции задавал им вопрос, но получил очень уклончивый ответ.
а статья об идеях автора, которые может быть кому-то не нравятся, но лично мне они интересы (сам занимался изобретением велосипедов). Я конечно понимаю, что написать второй сфинкс не имеет смысла, но адаптировать некоторые идеи под свои нужды и так, чтоб тебя это устраивало — то это того стоит.
давай проэксперементируем?
руби имеет производительность в 5 раз меньше чем си.
можно это запустить на 2 и более потоков (по ядру на поток)
тогда производительность повысится раза в полтора.
правда кода раза в два увеличится и головная боль появится в в виде блокировок.
1 — согласен, но в подобных системах, больше половины трафика — служебные сообщения.
по моим расчетам не положат
2. Comet предлагаешь?
3. вот как раз это то время, когда человек набирает сообщение, можно и 10 сек сделать, тогда больше вероятность, что сервер ляжет. Время выбрано так, что если равномерно 10 к пользователей полезут общаться, то будет 350-400 rps а сервер выдерживает на ноуте около 2000.
Nginx mod_wsgi предоставляет API к своему poll-интерфейсу, который можно использовать для реализации цикла gevent — только представьте — nginx как сервер асинхронных python-приложений.
Не надо переоценивать роль энджиникса. Это распространенная ошибка, когда хотят в серверную логику запихать логику бэкэнда. Это может привести к сокетному голоданию и тогда наступит полный, сами понимаете что.
я так понял — это индекс одного сайта.
а каким образом осуществляется индексация? обход по базе или по страницам?
как хранится индекс, какие средства использованы для хранения?
как извлекается информация из идекса? Это реализовано отдельным демоном?
я бы сделал fcgi приложение и поставил бы его за энджиниксом (апачем)
на мой взгляд индекс лучше хранить в памяти и дублировать на файловой системе или ином хранилище. Вопрос что делать — если индекс очень большой? Наверно дешевле докупить память ;).
key/value хранилище? А как используем составной индекс? например поиск по фразе «sumsung s-320»
но по своей сущности Consume — синхронный запрос, как только сообщение появляется в очереди, оно сразу считывается (передается клиенту), коннекция держится постоянно. в этом смысле — синхронный.
методом GET ты можешь забрать сообщение в любое время из очереди (или пустое уведомление GET-EMPTY). коннекцию постоянно можно не держать. в этом смысле — асинхронный. Хотя если смотреть с иной стороны, как только мы выдаем GET, мы сразу получаем (синхронно) ответ: либо GET-OK либо GET-EMPTY, т.е. синхронный.
пока идет только обкатка сервера
в настоящее время amqp запрос осуществляется методом BASIC.GET (асинхронный)
планирую разработку синхронного запроса BASIC.CONSUME
тогда без comet технологии не обойтись.
приблизительнго так:
nginx 950 rps
http_libevent 1400rps
пошел читать топик по ссылке :)
руби имеет производительность в 5 раз меньше чем си.
можно это запустить на 2 и более потоков (по ядру на поток)
тогда производительность повысится раза в полтора.
правда кода раза в два увеличится и головная боль появится в в виде блокировок.
твои ошибки и твой бесценный опыт.
по моим расчетам не положат
2. Comet предлагаешь?
3. вот как раз это то время, когда человек набирает сообщение, можно и 10 сек сделать, тогда больше вероятность, что сервер ляжет. Время выбрано так, что если равномерно 10 к пользователей полезут общаться, то будет 350-400 rps а сервер выдерживает на ноуте около 2000.
спасибо
а каким образом осуществляется индексация? обход по базе или по страницам?
как хранится индекс, какие средства использованы для хранения?
как извлекается информация из идекса? Это реализовано отдельным демоном?
я бы сделал fcgi приложение и поставил бы его за энджиниксом (апачем)
на мой взгляд индекс лучше хранить в памяти и дублировать на файловой системе или ином хранилище. Вопрос что делать — если индекс очень большой? Наверно дешевле докупить память ;).
key/value хранилище? А как используем составной индекс? например поиск по фразе «sumsung s-320»
самого ни раз заминусовали :)
тема интересная и актуальная
а как продвигается реализация?
что уже сделано?
спасибо