Простой рекламный сервер - PullRequest
5 голосов
/ 16 мая 2011

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

В последних трех моих проектах я использовал Grails, которые мне очень понравились, потому что они быстро развиваются и хороши.поддержка со стороны сообщества Java через Spring и Hibernate.Однако у Grails все еще есть некоторые проблемы с производительностью, и я не уверен, что это правильный выбор для этой задачи.Я искал другие альтернативы, но не могу решить, в какую сторону идти.Сервер должен быть способен обрабатывать около пары тысяч запросов в секунду, а также должен быть надежным.Структура БД выглядит следующим образом (упрощенно):

Ad ==> site, position, percent of view (percent of time the ad is shown)

Таким образом, в основном, рекламному серверу необходимо получить необходимые строки из БД для конкретного сайта и позиции и выбрать, какую рекламу показывать (в зависимости от процента).

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

  • Grails вместе с Redis и MongoDB - я не нашел никаких отчетов о производительности с этим трио.В моих предыдущих проектах мы обнаружили, что у Grails много проблем с производительностью, многие из которых мы решали по-разному, но для рекламного сервера я не уверен, что это решится.
  • Node.js вместе с хранилищем значений ключей - Node.js предположительно очень быстрый, но было бы немного рискованно реализовать его на данном этапе, поскольку он еще не стабилизирован.
  • Ruby on Rails вместе с хранилищем ключ-значение - еще не было разработок Ruby on Rails, но, насколько я могу судить по поиску, в Ruby on Rails есть многолучшая производительность, чем у Grails.
  • PHP с хранилищем значений ключей - также не было никакого программирования на PHP, но есть много больших сайтов, использующих PHP, которые имеют хорошую производительность, поэтомуэто следует считать хорошей альтернативой.

Любые предложения или рекомендации горячо приветствуются.

Ответы [ 3 ]

3 голосов
/ 16 мая 2011

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

2 голосов
/ 18 мая 2011

100.000 строк достаточно мало для хранения в памяти.С node.js я бы попытался сохранить данные в незавершенной БД.Предполагая, что набор данных не становится слишком большим, а обновления БД нечасты, очень простой сервер узлов должен обеспечить хорошую производительность.

ad.db:

{ key:'site:position', value: [{id:'1424234', percent:50}, { id:'8394847', percent:50}] }

url:

http :: //adserver.com/? Add = site: position

adServer.js:

var http = require('http');
var url = require('url');
var db = require('dirty')('ad.db');

var server = http.createServer(function (req, res) {
  var query = url.parse(req.url, true).query.add;
  var adds = db.get(query);
  var random = Math.floor( Math.random() * 100 );
  var id = '';
  for( var i = 0, len = adds.length; i < len; i++ ) {
    if( random < adds[i].percent ) {
      id = adds[i].id;
      break;
    } else {
      random += adds[i].percent;
    }
  }
  res.writeHead(200, {'Content-Type': 'text/html'});
  res.end('<img src="http://cdn.com/' + id + '.jpg" alt='' />');
});
db.on('load', function() {
  server.listen(80);
});
1 голос
/ 16 мая 2011

Я нашел эти сравнения Java с node.js, касающиеся производительности:

http://www.olympum.com/java/quick-benchmark-java-nodejs/

http://www.olympum.com/java/java-aio-vs-nodejs/

Они предполагают, что Java в два раза быстрее, но проведите свои собственные испытания.

Сколько комбинаций сайта, позиции, процента и т. Д. У вас будет? Сколько новых измерений вы добавите в будущем? Вероятно, стоит загрузить их все при запуске, чтобы избежать постоянного попадания в базу данных. Вы можете использовать их комбинацию, чтобы быстро создать ключ, который вы ищете адрес рекламы в памяти. Это должно быть достаточно быстро в Grails.

При тысячах запросов в секунду вы, вероятно, просматриваете кластерную ферму с балансировщиком нагрузки. Зависит от сложности логики, которая строит содержание страницы.

Как только вы определили URL, который браузер должен использовать для загрузки рекламы, мне нравится идея CDN, но это может дорого обойтись!

Если бы это был я, я бы придерживался одной технологии (Grails) и решал проблемы, когда сталкиваюсь с ними.

...