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

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

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

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

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

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

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

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

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

Часто ловлю себя на мысли, что вот, придёт время, работать можно будет меньше, буду чаше прогуливаться по городу, читать книги, отдыхать… Но чем дальше, тем больше работы

Сейчас на мне две крупные разработки (не считая всяких мелочей) — разработка нового рекламного движка для videoclick.ru и разработка нового контекста для этого же проекта.

По рекламному движку сразу же начал “думать” большую распределённую систему, но получилось на столько сложно, что решил на время отложить эту сложность и реализовать на первое время односерверное решение. Благо в ближайший год трафик врядли привысит 30-40 миллионов запросов в сутки, а с таким трафиком легко справится один сервер. Зато потом, когда сроки не будут так поджимать, можно будет спокойно придумать и реализовать более красивую схему работы. Ещё один плюс данного подхода — на базе этой разработки можно будет быстро реализовать adboo, главное до РИФ-а успеть

По контектсту, начитавшись архитектурных решений больших систем типа google, спроектировал архитектуру под этот проект. Получилось неплохо, но в требуемые сроки с таким решением явно не уложусь. А потому, опять таки, решил реализовать для начала одно-серверное решение. Алгоритм поиска пересечения ключевых слов выдал порядка 1000 запросов в секунду на моём Mac Book Pro в однотредовом решении, что для начала очень неплохо. Засада случилась с парсингом html-документов. Собственное решение довольно часто садилось в лужу, выдавая неверный результат. Выяснил, что проблема связана с ошибками оформления html. Пошаманив, лужи стали попадаться реже, но хотелось бы совсем от них избавиться. Для этого погуглил и нашёл проект tidy, который должен избавить от всех проблем, но пока не интегрировал его, не знаю на сколько эта библиотека производительна, будем посмотреть…

А ещё у меня появилась идея кластерного решения для рекламных сетей, прообразом которой послужила технология map/reduce… Реализация обещает быть легко масштабируемой (при этом будет почти линейная масштабируемость производительности), отслеживание ограничений точным, без необходимости синхронизировать счётчики в одном месте. Но производительность должна быть меньше чем у “заточенного” решения. Пока эта идея отлёживается на полочке, как будет больше свободного времени, обязательно займусь ею плотно. Руки чешутся

Почему чукча не писатель? Да потому что он программист, у него нет времени и желания писать посты в блоге

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