Pull to refresh

Comments 73

На хабре все же много технического народу, поэтому хотелось бы хоть пару слов о технической стороне. Какая платформа была выбрана? Сколько железа на под себя потребовала?
Система построена на базе проверенной связки PHP+MySQL.
PHP использовался самописный фреймворк.
Всё это дело работает на 2х серверах которые на данный момент без проблем справляются со всеми нагрузками, один под веб-сервер nginx фронтенд + apache бакэнд, и второй сервер под БД.
Из оптимизаций под высокие нагрузки можно отметить только шардинг MySQL т.к. очень много статистических данных по рекламным кампаниям и площадкам, использование memcached ну и опкешер PHP кода (eaccelerator).

Запросов к серверу в сутки более 30кк
Средняя скорость вывода рекламы 0.03 сек
Я бы рекомендовал подумать над написанием движка, отвечающего за отдачу баннеров, на чём-то более производительном, чем php. Это позволить обрабатывать тесячи запросов в сек на одном сервере и позволит снять нагрузку с mysql.
Про тысячи запросов в сек я писал подразумевая C :)
При работе на одном сервере всей системы нагрузка не превышала 0.1% при примерно таких же показателях.
Своей команде я доверяю и их выбор ни разу не подвел.
Если Николай сказал, что сервер даже не нагреется, значит так и будет.
Тогда хотелось бы статью от Николая, на тему архитектуры системы. Одна из систем, которую я писал, обрабатывала порядка 20-25кк запросов в сутки, что выливалось в 500-600 запросов в сек. в пике. Хотелось бы знать, как удаётся обрабатывать такое количество запросов на php+mysql.
Имхо, memched для кэширования запросов к СУБД и eaccelerator с сохраненим опкода в shm наиболее популярное решение. Более экзотическое и более быстрое решение — свой кэш на shm.
Дал ему ваш коммент.
Думаю не заставит себя долго ждать.
Не могли бы вы рассказать про свой опыт? Я сейчас имею дело с чем-то подобным, очень интересно как другие решали те же проблемы
А что именно интересно? У меня схема простая: база mysql, интерфейсы управления на php, баннеры раздаёт демон, написанных на C. Демон периодически проверяет базу на обновления, загружает их, сбрасывает в базу счётчики, сохраняет в файлы логи, которые потом обрабатываются парсерами, аггрегируются и складываются в базу.
Сударь! Не будьте перфикционистом! Если на текущей платформе при данном железе скорость обработки данных находится в необходимых пределах (а как я понимаю сейчас там нафиг не нужны тысячи запросов в секунду), то смена платформы — преступление.
Соглашусь,
любые изменения должны быть оправданы требованиями.
Когда дойдёт до оплаты труда команды из своего кармана — быстро пройдёт.
30кк в смысле 30 000 000 или 30 000? Это запросов на статику или динамику?

Apache, значит PHP работает как mod_php. Над использованием php-fpm не задумывались?

Как я понимаю веб-сервер с сервером бд слинкован локальной сетью? На 100Мб/с или 1Гб/с?

А сессии где хранятся? В memched, в shm через ecceleretor или что-то другое?
запросов к динамике 30кк = 30 000 000, где к = 000 ))
Дальше уже тех. тонкости, которые мне уже надо уточнить.
Я то не системный администратор.
Если два сервака в сутки вытягивают 30 миллионов запросов со скоростью в 0.03 сек, то примите мои поздравления! Приложение судя по всему писали крайне прямые руки.

Как я понимаю сервера стоят не из слабеньких, видимо что-то в духе 4/8 ядерных интелов на этак 20ГБ ОЗУ? Сервер базы данных случаем не на сас дисках?
Первый сервер, который тянул все 2 года был просто:
Процессор Intel® Xeon® CPU E5405 @ 2.00GHz X 8
Оперативная память 4077 Mb
Файл подкачки (swap) 4095 Mb
Размер дискового пространства 131618 Mb
Винчестеры SAS 74 гб х2
Количество процессов 323
Продолжительность работы 563 days 18 hours 53 minutes
Средняя загрузка 0.41 0.42 0.35
— Параметры текущих серверов надо уточнить
Не хочется слыть занудой, тем не менее… Известная мне сеть делает 22кк запросов в сутки при пиковой нагрузке более 500 запросов в сек. 30/22*500=681 минимум запросов в сек. в пике в сети автора статьи. Пусть там два сервера по 8 ядер каждый (в чём я сильно сомневаюсь, скорее всего один под муську, другой под php), что даст 681/16=42 запроса в сек, что для php+mysql вполне достежимо, если систему хорошо оптимизировать. Но вышенаписанное «При работе на одном сервере всей системы нагрузка не превышала 0.1% при примерно таких же показателях» мне выносит мозг, КАК?????

Вот прямо сейчас у меня движок, написанный на C, кушает от 10% до 13% по top (ubuntu) при нагрузке порядка 700 запросов в сек. С базой движок не работает. Может я криворукий, пусть и с опытом порядка 7 лет в этой сфере?

В общем, требую технических подробностей :)
Я сам в шоке. Жду подробностей от Николая.
Обязательно дам их сюда.
Из того, что сразу могу отметить: Больше функций, больше статистики, аналитика, обзор данных, еженедельные выплаты, больше рекламных кампаний в ротации и много сайтов на выбор, поддержка в всегда в сети, регулярные обновления и работа над дополнениями практически не останавливается.
Из собственного опыта работы как с mobileads так и с mobiads:
— mobiads берет меньший % с дохода (кроме них все берут минимум 50%)
— поддержка реагирует сразу а не через месяц

С mobileads.ru работал год (если не больше). Когда в рекламную сеть попали сайты с алармами, сеть накрылась… Нормальная реклама оттуда пропала так как рекламодатели с алармами поднимали цены до нереальных.

Дальше кое-какое время поработал с mobiads. А потом вообще отказался продавать рекламу через посредников.
Так и не понял, что такое мобильная рекламная сеть и чем она отличается от обычного web, я имею ввиду то, что wap же умирает, если уже не умер? Сейчас колоссальными темпами идет смена курса на коммуникаторы, которые держат классический html, а классические рекламные / баннерные сети всегда имеют вроде как 3 вида баннера: 1) Анимированный (м.б. Flash) 2) Если флеш не установлен — то может просто статика или gif-анимация, 3) Текстовый вариант. Ну если добавить к этому еще разные сценарии и форматы на User-Agent… то можно выдавать удобочитаемые форматы под мобильники, а еще есть в CSS такое понятие как layout. Или вы о чем? в Android Store или тем более Apple iTunes, там свои «коровы» и они сами их «доят».
У Яндекса точно есть 3 сценария на баннеры, пользовались — знаем. Не хочу вас демотивировать, но на мой взгляд позиционирование «мобильная рекламная сеть» это уже поезд идущий не ту сторону. Посмотрите на эти мобильники — это же полноценные ПК. Что стоит крупным рекламным сетям просто добавить формат рекламного контента для мобильных устройств и всё? Учитывая, вектор развития и разрешение, например, samsung galaxy s 480x800 px — можно смело сравнить его с NetBook'ом.
Мы появились до андроидов и массовой истерии по айфонам.
С этим можно поспорить. Зачем тогда Google покупала admob?:)
В последнее время замечал баннеры мобильных агрегаторов рекламы (таких ПП как описанная Сергеем) в в очень даже раскрученных приложениях для iPhone.
Будущее таких проектов по-моему именно в выходе на рынок встроенной в приложении рекламы.
И думаю Сергей тоже смотрит в эту сторону.
Да, 100% в точку.
Поэтому и хочу запустить свое приложение,
Поэтому хотел бы собрать команду для игрового направления.
Ссылки я убрал, а то топик в самопиар свалился и заминусовали карму.
Наша сеть — mobiads.ru
Реклама размещается исключительно на мобильных сайтах и показывается посетителям с мобильных устройств.
Типы рекламы — баннерный и текстовый с оплатой за переход.
Есть ли у Вас четкое разделение рекламного трафика на вап и веб (в зависимости от APN указанного в настройках пользователя)?
Работаете ли с другими моделями оплаты, например с revenue sharing с контент провайдерами?
Не понимаю зачем это? И без APN сувществует много методов определения телефон это или ПК.
Раз не понимаете, значит Вам это было не нужно :).
Абоненты могут выходить в Интернет с телефона через разные APN'ы (вап и веб). Как правило, у таких точек разные IP ranges.
Терени о том зачем это может быть нужно для провайдера:
— при использовании вап точек доступа довольно часто WAP Gateway передает дополнительную информацию (MSISDN, иногда даже тип подписки prepaid или postpaid),, что для рекламодателя или контент провайдера часто бывает весьма полезным.
— часто операторы допускают revenue sharing прибылью от Wap трафика с провайдерами
Для этого хватит иметь базу IP вап точек (как я и все остальные делают).
Такие данные как APN я думаю нельзя получить от пользователя.
Так и есть. Логично использовать базу ip range вида:
Список ip1 = оператор1 точка доступа вап,
Список ip2 = оператор1 точка доступа ввв
Список ip3 = опреатор1 точка доступа цсд (или льготный интернет, или еще что-то)
Вот мой вопрос и был о том, есть ли возможность получать посетителей по критерию: оператор х, только вап абоненты?
Кстати, встречный вопрос к Степану, а есть ли такая возможность на Вашем портале?
А зачем мне на обычном сайте делить пользователей по точке доступа?

По поводу вашего вопроса к Сергею, отвечу за него и скопирую часть фильтров доступных при добавлении новой рекламное площадки в его сети:

Билайн(WAP)
Билайн(WiFi)
Билайн(Казань)
Билайн(Калининград)
Билайн(Красноярск)
Билайн(Новосибирск)
Билайн(СПб)
Билайн(Ставрополь)…

Аналогично с многими операторами России.
Мы не правильно поняли друг друга с APN.
>> есть ли возможность получать посетителей по критерию: оператор х, только вап абоненты?
да, есть. У нас точка доступа WAP выделена для выбора, но только по основным операторам.
Разделение четкое на мобильные устройства, операторы сотовой связи, браузеры, бренды производителей.
КП предоплачивают свои кампании в свой аккаунт нашей сети и настраивают свои кампании, включают/выключают и тд.
Или вопрос в другом?
Вопрос в следующем. Сейчас Вы «продаете» клики или переходы на сайты рекламодателей. Были ли у Вас /интересуют ли Вас другие методы сотрудничества например с оплатой за совершенное абонентом действие (загрузка ПО для телефона, звонком на номер рекламодателя, Итд).
Поскольку, заказывая мобильную рекламу для своих проектов в различных сетях, вижу, что они достаточно консервативные и им интересна в основном модель с оплатой за клики.
мы рассматриваем, но тут нужен рекламодатель, который с нами пройдет все пути от формирования типа рекламы до запуска варианта, а таких нет.
КП сами используют только такую систему расчетов с партнерами через ПП и им нет надобности строить все тоже самое с нами. Нет спроса — нет предложения.
Значит попробуем с Вами сконтактировать, возможно что-то и получится.
Размещать рекламу в мобильных приложениях нам ни кто не мешает, но на данный момент мы не обеспечим всех желающих рекламой.
Это сейчас приоритетное направление.
NOX как я понимаю был одним из партнеров?
Помниться предлагал работать с вами.
Привет Степан!
Я хотел бы тут без персон и фамилий,
если ты не против.
Очень жаль, что минусуют. Обычно кто преследует цель просто попиарится (не буду тыкать пальцем в конкретные публикации) не отвечают на технические вопросы, а это в контексте хабра как раз самая интересная часть. Но по комментариям видно, что очень охотно освещается и техническая сторона. Поэтому пост на чисто пиарный ну ни как не тянет.

Поэтому призываю адекватную часть хабрособщества помочь автору с положительной кармой.
У меня топик не технический, но осветить могу любые детали.
Кроме конечно собственных разработок систем защиты и логирования.
Я топик плюсанул и автору в карму, чтобы писал. Но поверьте мне, пока это больше похоже на пиар, потому как технических подробностей нет, а в «Запросов к серверу в сутки более 30кк», и «При работе на одном сервере всей системы нагрузка не превышала 0.1% при примерно таких же показателях», и «Система построена на базе проверенной связки PHP+MySQL» пусть даже там мемкеш и по 8 ядер на обоих серверах, НЕ ВЕРЮ.

Ответ от Николая:
Сессии хранятся в RAM-FS но они не критичны т.к. используются только для авторизации пользователей внутри системы, а основные запросы это на показ рекламы, где механизм сессий как таковой не используется.

php-fpm хотели попробывать, но изучив информацию о производительности связок php-fpm vs mod_php решили ничего не менять, т.к. проблем с ресурсами сервера нету, но был риск возникновения проблем со стабильностью работы.

30млн запросов это на динамику. В любом случае nginx как проксирующий веб-сервер выручает, снимая нагрузку от медленных запросов, быстрее высвобождая ресурсы apache для обработки новых запросов.

Особо-хитрых оптимизаций небыло. Был грамотный сисадмин который настроил нормально систему, вебсерверы, mysql для обработки такого большого числа мелких запросов. По сути запрос на рекламу это простейший POST-запрос с минимумом данных о клиенте, а ответ от сервера вообще не бывает размером более 150 байт, т.к. в ответе мы возвращаем статичный HTML-код (2-3 <a href… или <img src для баннеров).

В остальном просто правильное проектирование архитектуры БД, особенно за счёт высокого попадания данных в кеш MySQL и отложенная обработка данных. Когда данные агрегируются и затем через определённые промежутки времени обрабатываются системой. Фоновые обработчики (воркеры) так же написаны на РНР.

и напиши что про 0.1% ты ошибся. и извиняешься что ввёл людей в залуждение. Сервера 8 ядерные, локальный канал 1Gbs.
Ответ только на один вопрос, 0.1% нагрузки — это неверная информация. В остальном было бы интересно получить статью на тему архитектуры системы, если возможно. Я так понял, вы в Питере?
Видимо все же 10%, про 0,1% конечно поверить невозможно. Хотя опять же в контексте 8 ядер нужно рассматривать LA, а не % загрузки по ядру, имхо.
И смотря на кокой ОС все это вертится. Некоторые ведь в LA считают и нагрузку на диски а некоторые нет.
Что бы не поднимать панику и поставить все на свои места кидаю скрин загрузки с первого сервера, характеристики которого я давал выше.

Статью Николай не обещает,
0.1% это скорее всего я видел в отчетах по другому серверу, приношу свои извинения, но я верил в эти цифры.
Да, мы в Питере.
Ниже кинул скрин по нагрузкам за прошлый год.
Вот у меня вап сайт почти 5к хостов, а заработок в вашей системе от 5 до 20 рублей в день, с чем это может быть связано?
И вам Евгений здравствуйте!
Проверил места размещения рекламы, проанализировал имеющийся трафик, посмотрел обзорную информацию по статистике рекламы на вашем проекте.
1. Заметил, что вы модифицировали наш код.
2. Вы используете несколько рекламных сетей
3. Не всегда реклама вообще выводится(нет даже отладочной информации в коде страницы)
Рекомендую поставить стандартный код сети, хотя бы временно перестать сортировать рекламные сети для адекватного анализа, отключите показ реферального баннера в настройках площадки(раз вы из-за него вырезаете/модифицируете код).
Для сайта CTR 0.5% — 0.7% — это даже очень хорошо. При текущей посещаемости можно заработать больше, количество показов рекламы должно быть около 30к — 40к, а у вас всего 2к — 3к, ваша система ротации рекламных сетей списывает на нет всю желаемую монетизацию.
Не нужно распылять имеющийся трафик на несколько рекламных сетей. И тем более самим же закрывать показ рекламы для посетителя. За 10 обновлений я увидел рекламу два раза.
Хотя рекомендую сделать даже проще: запрашивать рекламу с обеих систем одновременно и показывать только полученные объявления, без собственных алгоритмов смены рекламной сети.
Получая рекламу выводите ее в разных блоках периодически меняя местами.
Смотрел сейчас по своему основному серваку:
20млн обращений в сутки. LA 10-15.
Но у меня основные проблемы с дисками…
Степан, у нас же все проще.
Мы только получаем данные, сессии не ведем и отдаем не более 150 байт
Вышенаписаное мною было не для того что бы оспорить ;)

Про mobtop не хотите написать?
Как вы выдерживаете 80млн.
Есть уже кое-какие наброски. В скором времени обязательно опубликуем.
Стас готовит материал более тщательно со всеми тех.спецификациями, в отличии от меня.
А что вы так разбрасываетесь долями? Разработчикам просто платите хорошие деньги, а долю нужно держать и не отпускать. Пригодится еще.
Команда отличается от сотрудников, что каждый вносит вклад.
Отдавая человеку долю в проекте, можно рассчитывать на куда большую лояльность и отдачу в проекте.
Я этого и не отрицаю. Просто когда они все разбредаются, у них меняются приоритеты, проект живет, а доля уже неработающего над проектом человека остается, проект загибается.

Решением могут быть опционы. Но никак не доля.
Тут как раз существует возможность выкупить долю.
Или это делают оставшиеся в команде, или кто то один, или приглашается новый человек за выкуп доли.
Вариантов хватает как выйти из таких ситуаций.
Правда в том, что программисты, например, работают неплохо и за деньги. Если им нормально платить, то количество и качество отдачи не будет зависеть от доли. Им самим будет интересно делать хорошо и красиво. Более того, существуют компании, где за долю никто никогда не работал, или работать не может в принципе (аутсорсинговые). И тем не менее, они не закрываются.

так что я считаю «доля в проекте» — скорее такое магическое самоубеждение для себя. Что если есть у людей доля, они будут работать лучше. Может быть лучше, но часто мотивировать деньгами и долей вообще не стоит. Более сильные факторы это сплоченная команда, уверенный лидер, интересные проекты.
Да, согласен. Хочешь ЗП? Работай за ЗП.
Хочешь иметь часть общей приыли проекта? И принимать решения, тогда в долю.
Или вообще, можно быть инвестором и ни во что не вникать, а просто получать деньги.
Хочешь иметь часть общей приыли проекта? И принимать решения, тогда в долю.
Просто первый вопрос руководителя — а зачем давать кому-то долю. Это не выгодно, желательно вообще всю долю держать при себе (ну насколько это возможно на первых порах). Человек может и так принимать решения. Просто смысла в доле особо нет, вот я хочу о чем сказать. Вы сейчас привлекаете программеров долей, хотя вполне можете привлекать только зарплатой и интересным проектом.

Короче, не знаю. Я бы в своей компании установил бы табу на раздачу долей (у меня тоже есть несколько проектов, но нигде долей пока не делился).
Если читали весь топик, то изначальные условия были такими.
На ЗП и все остальное денег вообще не было, а менять условия только потому, что прошло время и нет желания с ними делится?
Это совместный бизнес и мы его ведем вместе.
В новый проект я беру людей, тех кто его сделает, а не тех кто на него будет работать.
Only those users with full accounts are able to leave comments. Log in, please.