Записки программиста

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

В результате перешёл на использование HTTP. Для себя я выделил следующие преимущества. Во-первых, при использовании HTTP, у меня есть возможность использовать огромное количество готового программного обеспечения для создания инфраструктуры. Тот же nginx можно прикрутить в качестве балансировщика. Во-вторых, теперь никаких telnet-ов для тестирования, можно использовать любой браузер. В третьих, такой демон можно легко, без переработок, использовать в качестве сервиса с доступом по HTTP.

Рекомендую подумать на эту тему

У меня достаточно долго длилась головоломка на тему, как в многопоточной среде ротировать данные и счётчики. На днях я реализовал одну из своих идей, которой и хочу поделиться.

В одной из систем, которую я развивал, ротация производилась простым способом — начитывались все актуальные данные из базы, данные ротировались через мьютексы, старые удалялись. В такой реализации мне решительно не нравилось то, что при ротации повторно начитывались неизменённые данные. Плюс мьютексы — это зло, их нужно избегать. Читать дальше…

Сейчас ломаю голову как показывать баннеры в контекстной сети. Вопрос делится на два возможных варианта: показ рекламы в контекстной сети на подобии Adsense, бегун или директ (где выбирается заданное количество объявлений подходящих по ключевым словам для данной страницы) и показ в контекстной сети на подобии videoclick или автоконтекста бегуна (где линкуются ключевые фразы на странице, при наведении на которые, показывается реклама).

В обоих вариантах есть общие вещи, но есть и различия. В первом варианте кампании не конфликтуют друг с другом, а просто выбираются на основе каких-то приоритетов (скорее всего по ECPM, количеству заработанных денег за тысячу показов), а во втором легко может произойти конфликт, когда одна или более кампаний “дерутся” за одно слово или фразу. Читать дальше…

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

Я вижу два подхода к решению задачи хранения счётчиков. Первый подход — это хранение относительного количества показов, кликов и т.п., которые были совершены с некоторого момента времени (например, с последнего перечитывания данных из базы данных). Второй подход — это хранение абсолютного количества показов, кликов и т.п., которы были совершены за всё время. Рассмотрим эти подходы подробнее. Читать дальше…

Мне Denis, в комментария на тему Приоритетные очереди 2, подсказал отличную тему, как бороться с перекрутами в системах управления рекламой, о чём сегодня и поговорим…

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

Почитал, подумал и пришёл к следующим мыслям.

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

Не первый раз сталкиваюсь с задачей, для которой я пока не придумал красивого и простого решения… Речь идёт о приоритетных очередях.

Для решения проблемы с выбором баннера, который надо показать на площадке, я знаю два решения. Первое решение — подсчёт суммы приоритетов всех баннеров, расстановка весов каждому из баннеров, а потом, случайным образом (с учётом приоритетов) выбор баннера. Такой вариант не нравится большим количеством вычислений и тем, что баннеры выбираются случайным образом, а не равномерно (на большом трафике статистика нормальная, но хочется иметь нормальную статистику и на маленьком трафике). Второй вариант — очереди. Формируется циклическая очередь, по которой бегаем. Математики мало, но есть свои проблемы. Читать дальше…

Написал собственный парсер HTML. Пока он не достаточно хорошо оптимизирован (знаю где можно ускорить), но при этом перелопатил HTML-ку в 721Мб (взял реальный HTML в 180К и продублировал его много раз) за 13 секунд без оптимизаций и за 10 секунд с оптимизацией -O3. Получается порядка 72 мегабайт в секуду. Весьма неплохо получилось, я прямо охуел, целью было 40Мб/сек

Парсер на входе получает HTML-ку, а на выходе выдаёт текст из допустимых тегов (можно указывать содержимое каких тегов нужно игнорировать). При этом он толерантен к ошибкам в документе и умеет обходить долбанные JavaScript в которых любят писать что-то типа document.write(”</script>”);

Осталось основательно потестить его на разных реальных HTML-ках и можно использовать…

Задался сегодня вопросом о том какой код со строками работает быстрее:

u_char c;
if (c == ' ' || c == '\t' || c == '\r' || c == '\n') {
......
}

или:

u_char c;
u_char delimiter[] = “…”;
if (delimiter[c]) {

}

И вот что получилось… Читать дальше…

Отстой полный! Я не нашёл HTML-парсера, который работал бы быстро, и при этом, мог перерабатывать не wellformated-документы…

Tidy оказался знатным тормозом, документ размеров в 180Кб, взятый с одного популярного сайта, он перелопачивал со скоростью порядка 6 документов в секунду, это ни в какие рамки не лезет для моих задач, где скорость должна исчисляться сотнями документов в секунду… Но зато перелопатил…

Libxml2 вообще отказался обрабатывать какие-либо документы… Опытным путём пришёл к выводу, что достаточно одной ошибки в документе чтобы он вернул ошибку…

Поиск в Google пока ничего не дал… Чувствуется придётся писать свой парсер…