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

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

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

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

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

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

Я не забил на свою идею, я её немного буксую

Решил начать с интерфейсов, чтобы было что смотреть… Начал писать на базе своего фреймворка на php, но встретился с рядом проблем, а конкретно, с разграничением доступа для пользователей… Некоторые скрипты превратились в помойки с кучей проверок на роль пользователя… Меня это совсем не порадовало, а потому, немного модифицировал фреймворк и теперь скрипты выглядят лучше, по крайней мере они стали более читаемыми…

Слегка огрёб гемороя от задумки позволить рекламодателям иметь несколько пользователей… Пришлось помучаться, но, зато, теперь у рекламодателя может быть несколько пользователей с ролями администратора и простого пользователя…

В общем работаю, процесс идёт

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

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

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

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

В одном из проектов потребовалось хранить данные о пользователях и иметь к ним быстрый доступ… Базы данных не прокатывают из-за своей медлительности. Memcache подходит, но для данной задачи ему не хватает одного функционала, — возможности группировать ключи и выбирать сразу группу ключей. Например, у нас есть ключи key1.key11, key1.key12, key2.key21, должна быть возможность сделать запрос /get key1. и получить в ответ значения key1.key11 и key1.key12. Читать дальше…

В одно время всё никак не мог придумат как красиво реализовать модель с одним io-thread, который принимает запросы и множеством worker-thread которые их обрабатывают. Зачем такая схема? Потому что в многотредовом приложении только один тред может обрабатывать события (epoll, kqueue и т.п.). Но однотредовое приложение не будет использовать все ресурсы современного многоядерного процессора. Читать дальше…

Доработал memcounter до версии 0.0.5. Чуть позже подточу напильником до версии 0.1.0, но считаю что уже сейчас её можно использовать по полной программе.

Раньше и не задумывался о том что преобразование целого числа в строку в десятичном представлении работает почти в три раза медленнее чем в шестнадцатиричном. Забавно. Читать дальше…

Честно прочитал 43 из 81 страниц технического описани Judy. Ощущения непередаваемые… Просветление на фоне перегрузки мозга…

По прочтении нафиг выбросил из memcounter-а собственные хранилища и переписал код на использование Judy. Позже, когда просветлюсь от прочтения Software Optimization Guide for AMD64 Processors, может быть верну хранилище table, а пока и так быстро работает.

Для своих нужд написал memcounter. memcounter — это высокопроизводительный демон для хранения счётчиков. Читать дальше…