Блог Монашёва Михаила
Без бэкапа по жизни.
Привет, Гость
  Войти…
Регистрация
  Сообщества
Опросы
Тесты
  Фоторедактор
Интересы
Поиск пользователей
  Дуэли
Аватары
Гороскоп
  Кто, Где, Когда
Игры
В онлайне
  Позитивки
Online game О!
  Случайный дневник
MindMix
Ещё…↓вниз
Отключить дизайн


Зарегистрироваться

Логин:
Пароль:
   

Забыли пароль?


 
yes
Получи свой дневник!

Блог Монашёва МихаилаПерейти на страницу: « предыдущуюПредыдущая | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | следующуюСледующая »


среда, 26 декабря 2007 г.
Сигейт Баракуда 750 GB SATA Михаил 19:43:54
За две недели поменяли 4 SATA диска из 6! Это просто @#$% какой-то. Умудрились даже данные не потерять...

Если вдруг решите покупать сервер с большими дисками, то наверное пока лучше ограничиться 500 гиговыми.

P.S.
Задачка: в сервере есть 6 дисков. 3 сломались. Сколько нужно поменять в сервере дисков, чтобы все диски стали рабочими?
Подсказка: сервер на гарантии, поэтому при смене диска, производитель предоставляет диск того же производителя и той же модели.

P.P.S.
У интересный корпус intel sr2500 и sr1500 . Самые левые диски хуже всего обдуваются. Из-за этого их температура на 5 градусов выше самых правых. Но так исторически сложилось, что именно они в биосе идут под первыми номерами и именно их делают загрузочными. В итоге получается, что загрузочные диски с большей вероятностью могут выйти из строя, чем остальные диски.

P.P.P.S.
gmirror все спасает. ;~)­

Категории: Офис
Прoкoммeнтировaть
суббота, 15 декабря 2007 г.
Cache::Memcached::Fa­st Михаил 20:23:02
Вот новый клиент для мемкашеда http://search.cpan.­org/dist/Cache-Memca­ched-Fast/

Он быстрее Cache::Memcached примерно в 6 раз. У него есть нормальная обработка упавших серверов: connect_timeout, io_timeout, max_failures, failure_timeout . Консистентный хэш - ketama. И ещё несколько недокументированных­ функций для немного пропатченного сервера, например noreply.

memcached лучше ставить последний для тестов. Например отсюда: svn co http://code.sixapar­t.com/svn/memcached/­trunk/server/ .

Категории: Memcached, Оптимизация, Perl
комментировать 1 комментарий | Прoкoммeнтировaть
пятница, 14 декабря 2007 г.
О расстоянии между теорией и практикой Михаил 21:38:06
Каждый вечер вот уже 2 года, возвращаясь домой, я сталкиваюсь с пробками на дорогах. Задача создания в старом городе транспортной сети довольно интересна и чем-то похожа на задачи разнесения нагрузки в веб-приложениях.

Казалось бы Москва, с её звёздообразной структурой обречена на большие проблемы с пробками в центре города. Ведь центр - это удобное место, через которое можно проехать в любое место. При этом чем дальше от центра, тем трафик должен быть меньше. Т.е. теоретический вывод такой: узкое место в звезде - это её центр. Даже если есть много колец, при росте желающих проехать на другую сторону города будет всё больше и наступит коллапс.

На практике вышло так, что пробки образуются при въезде в Москву, на пересечении исходящих лучей-шоссе с Московской Кольцевой Авто Дорогой. Таким способом видимо сдерживается приток машин в город. И на сейчас между Третьим и Садовым кольцами днём вполне можно ездить на машине. Цент конечно всё ещё сильно страдает, но лишь потому, что недостаточно сужений на подъезде к нему сдерживающих входящий в него поток. Вышла интересная картина. На практике звезда коллапсирует не только в центре, но и на концах лучей. А между центром и концами лучей вполне можно проехать.

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

P.P.S.
Вообще меня удивляет лень и глупость людей, которые готовы тратить кучу времени и здоровья на ежедневные поездки на работу на другой конец огромного растущего города. Как я заметил, людям почему-то наплевать на своё время и здоровье, но почему-то не наплевать на деньги... :-?­

Категории: Мысли
комментировать 10 комментариев | Прoкoммeнтировaть
Как захватить мир? Михаил 10:05:34
Четвёртый крепкий орешек не про терроризм. А про то, что программисты в силах захватить власть над миром.

Если присмотреться, то можно заметить, что несколько известных компаний с переменным успехом последние 10-20 лет пытаются сделать тоже самое.

Категории: Крепкий орешек 4, Фильмы
комментировать 4 комментария | Прoкoммeнтировaть
среда, 12 декабря 2007 г.
memcached и диски Михаил 20:55:55
В который раз наблюдаю вот такую странную картину:

­­

Перезагрузка memcached-а приводит к резкому снижению нагрузки на диски (19-00 на графике). Хотя должно быть наоборот. Ведь возрастает нагрузка на БД.

memcached запускается с ключиком -k (lock down all paged memory). top показывает, что есть ещё 2 гига памяти, а своп пустой. Такое ощущение, что мемкашед как-то высвапливается на диск. Есть идеи почему так происходит?

Категории: Memcached
комментировать 10 комментариев | Прoкoммeнтировaть
Почему OpenID отстой Михаил 19:22:06
В предыдущем посте (http://michael.min­dmix.ru/230-548-al-t­ernativa-gearmand.zh­tml#1368249 и ниже) у меня с Давидом Мзареуляном произошла беседа на тему OpenID. Решил оформить её в виде отдельного топика.

Аргументы Давида - OpenID удобен для авторизации там, где редко бываешь. Скорее соглашусь, что это так. Если юзеру не нужен функционал сайта и он готов оставаться на нём гостём с именем. Хотя именем OpenID назвать сложно.

Мои аргументы против OpenID заключаются в том, что он не достаточно надёжен для использования.

Посмотрите например исходники ЖЖ. Редкостный {censored}. И туда сейчас постоянно что-то новое комитят. И OpenID
там не работает месяцами.

Также можете спросить у Валеза как они разрабатывают Ли.ру. Или почитать как относятся к своим юзерам. Или лучше
почитать отзывы юзеров, о том, как к ним относятся.

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

Также можно посмотреть на то как глючат уже год рейтинги на blogs.yandex.ru, и никто их не чинит.

Можно ли доверять этим сервисам при авторизации через OpenID? Наверное можно, но не полностью.

Недоступность этих сервисов достаточно высокая, и авторизироваться под OpenID там не всегда получится. А выглядеть всё будет так, как будто мой сервис тормозит и глючит. Неправда ли странно юзеру на быстром инете ждать 10 секунд пока мой сервер дождётся ответа от почему-то зависшего другого сервера. А ведь ждёт он на моей странице.

А ведь именно с перечисленных сервисов придут основные пользователи OpenID. И если ИХ сервис глючит или
сломан, то страдать буду Я, а не они. И хакеры на моих сайтах будут удалять комменты горе-юзеров, использующих
OpenID на кривом сервисе, и на меня потом всех волков спустят. Не хочу я отвечать за чужие сервисы. Поэтому пока OpenID тут и нету. Сорри.

P.S.
Не читайте Хабр по утрам. :-)­

Категории: OpenID
комментировать 2 комментария | Прoкoммeнтировaть
beanstalkd - альтернатива Gearmand-у и TheSchwartz-у Михаил 10:10:01
beanstalkd - очень похожий на мемкашед демон. Занимается организацией очередей. Вот его сайт: http://xph.us/softw­are/beanstalkd

Алгоритм работы с ним очень простой. Один процесс подключился к демону и записал в очередь задание на выполнение. Другой процесс потом подключился к демону, получил задание, выполнил его и удалил его из очереди. Если за 120 секунд не успел, то задание свободно для резервировния другим процессом. Описание протокола тут: http://xph.us/softw­are/beanstalkd/proto­col.txt .

ИМХО очень полезная вещь. Не разобрался только пока, можно ли её заставить задания на диске сохранять или она как мемкашед, всё только в оперативке хранит...

UPD
По словам Алексея Капранова, на диск beanstalkd задачи не сохраняет. Всё в памяти держит.

Категории: Beanstalkd, Gearmand
комментировать 13 комментариев | Прoкoммeнтировaть
суббота, 8 декабря 2007 г.
Мы сделали вторую планету! Михаил 23:12:59
Наконец-то свершилось. Теперь LovePlanet тоже стала следующей. За нами :-)­

­­

Конечно это только на сегодня. И завтра всё будет иначе. Но тренд на обгон снова обозначен, как это было сделано пол года назад : http://michael.mind­mix.ru/130-509-my-sd­elali-planetu.zhtml и он сбудется!

Категории: Beon, Блоги, LovePlanet
комментировать 4 комментария | Прoкoммeнтировaть
четверг, 6 декабря 2007 г.
Пара строк про оптимизацию MySQL и memcached-а Михаил 10:30:13
Заметил интересную вещь. Если MySQL начинает активно использовать диск, то счётчик table_locks_waited начинает расти бысрее, чем раньше, а table_locks_immedia­te медлнее. Т.е. процент запросов, ожидающих своего выполнения, увеличивается. А процент запросов, выполняющиеся сразу, падает. Вчера я понял как этого избежать.

Мускул работает в несколько тредов. В конфиге my.cnf есть строчки:

# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8

У меня на сервере два XEON 5130. Итого 4 ядра. Поэтому я раньше ставил thread_concurrency = 8. Кроме того, я где-то видел график как скалится mysql на многоядерном сервере и по нему тоже выходила оптимальной цифра 8.

Но формула "Try number of CPU's*2 for thread_concurrency"­ хорошо работает лишь тогда, когда треды не лочатся на дисковом вводе/выводе. Поэтому, возникает ситуация, что запросы некому обработать, ибо все треды работают с диском. Аоэтому в подобных случаях можно увеличить thread_concurrency.­ У меня сейчас стоит thread_concurrency=­12 и это намного лучше, чем thread_concurrency=­8.

Вторая оптимизация: запуск мемкашеда с ключиком -k . Это ключ не позволяет процессу мемкашеда высвапливаться на диск. У меня омемкашед начал высвапливаться со всеми вытекающими :-(­ Ключик -k решил эту проблему.

Третья оптимизация. По дефолту под FreeBSD (под Linux это вроде не так) memcached собирается с тредами. А это значит куча мутексов на каждое обращение к нему. Поэтому configure.ac надо немного подредактировать, чтобы не собиралось с тредами.

P.S.
Спасибо Томашу Брешко, за помощь с memcached-ом.

Категории: MySQL, Оптимизация, Memcached
комментировать 4 комментария | Прoкoммeнтировaть
четверг, 1 ноября 2007 г.
Провёл семинар... Михаил 22:22:30
Сейчас вернулся домой (в 1 час ночи!!!) со своего семинара по мускулу и мемкашеду. Очень понравилось умным людям рассказывать о чём-то, до чего сам дошёл и вроде как тоже стал не менее умным :-)­ .

Презентация здесь: http://softsearch.r­u/i/download/mmug.pd­f
Видео здесь: http://softsearch.r­u/i/download/mmug-s1­.avi и http://softsearch.r­u/i/download/mmug-s2­.avi (Огромное спасибо Ивану Серёжкину за съёмку и обработку видео).

Хочется ещё чего-нить порассказывать... Не знаю только о чём...

Категории: Memcached, MySQL, Семинары и Конференции
комментировать 14 комментариев | Прoкoммeнтировaть
четверг, 25 октября 2007 г.
Бесплатный семинар "Совместное использование MySQL и memcached" Михаил 13:57:15
1 ноября вечером в 19:00 по адресу: г. Москва, ул. Мясницкая, д.20, аудитория 236 состоится очередная встреча Moscow MySQL User Group. А я в силу своих скромных умственных способностей расскажу там про то, как мы используем Мускул с мемкешедом.

Если Вы никогда ранее не работали с мемкашедом, то узнаете что это за зверь и как с его помощью ускорить работу с MySQL-ем.

Если уже используете его в своих проектах, то возможно узнаете, как это можно делать оптимальнее.

Зарегистрироваться на семинар можно тут: http://blog.styleru­.net/register/ . Регистрация обязательная, без неё просто не получится войти в здание.

Категории: MySQL, Memcached, Семинары и Конференции
Прoкoммeнтировaть
Странная Алекса Михаил 13:54:35
Смотрю на http://www.alexa.co­m/data/details/traff­ic_details?q=&url=be­on.ru и никак не понимаю откуда там провал, длящийся уже 2 недели.

2 недели назвад мы перенесли все картинки на новый сервер. Неужели этот перенос так повлиял на Алексу. По нашей статистике посещаемость только растёт и охват собственно тоже...

Категории: Alexa, Beon
Прoкoммeнтировaть
суббота, 22 сентября 2007 г.
О том как крепчает маразм... Михаил 17:41:17
Многие наверное слышали про Йована. Это человек, создавший несколько лет назад dirty.ru . Сообщество много времени было закрытым и попасть туда было сложно. Кроме всего прочего отличалось оно тем, что за ошибки в написанном там тесте, из него выгоняли. Когда я об этом узнал, то сильно удивился. Про себя же подумал, что наверное у его создателя какой-то пунктик на тему правописания, выраженный в нетерпимости ко всем, кто не овладел языком в совершенстве. Ну мало ли как бывает... Долбанула училка в первом классе линейкой по рукам за описку. А у ребёнка психологическая травма на всю жизнь осталась. И теперь он сам мучается и других тиранит... Приблизительно таким был ход моих мыслей.

С тех пор прошло много лет.

В мае этого года, когда dirty.ru открыло свои двери для всех, произошло смешение старых и новых участников сообщества с одним интересным последствием. Пунктик насчёт правописания, так долго вбиваемый Йованом в головы сообщества, дал плоды.

Вытесненные пришлыми новичками, старички стали искать себе новое пристанище для общения. А сами новички, прежде уже окученные старичками, так же частично попали в активные члены любителей писать без ошибок. Зреющий долгое время прыщ лопнул и его брызги разлетелись по всему Рунету.

В итоге на Вебпланете в комментариях к переводным статьям наблюдаются хронические обсуждения качества перевода, вместо самой статьи. А в непереводных статьях - борода комментов с описанием допущенных в статье орфографических ошибок. Люди очень инерционны и им сложно перестроиться на новый лад. Вот и цепляются за старое сколько могут.

Вот так странности одного человека могут быть культивированны в массы и потом коснуться многих. Если подумать, то приблизительно также Ленин совершил революцию, а Гитлер - вторую мировую. Странные люди делают нашу историю...

Категории: Dirty.ru, Мысли
комментировать 1 комментарий | Прoкoммeнтировaть
четверг, 6 сентября 2007 г.
Способы кэширования данных в memcached-е Михаил 18:22:26
По мере того, как оптимизируется движок beon.ru мы постепенно пересматриваем свои взгляды на то, как правильно кэшировать данные. Основная вопрос - как данные в кэше оставлять актуальными и синхронизированными­ с БД.

Способ первый, самый простой в реализации. При добавлении или изменении какого-либо объекта в БД удалять его из кэша. Сменил например пользователь свой номер аськи - мы записываем изменения в MySQL и одновременно из memcached-а удаляем ключик, соответствующий этому пользователю. Потом, когда нам понадобиться информация о нём, мы дёрнем memcached, он нам скажет, что такого юзера он не имеет в кэше, мы вытащим его из MySQL-я, положим в кэш и далее передадим информацию о нём скрипту, который её спрашивал. Плюсы и минусы этого способа очевидны.

Второй способ, является развитием первого. При изменении объекта в БД, вместо удаления его из кэша, мы записываем в кэш изменённые данные. Так мы уменьшаем количество промахов при обращении к кэшу и экономим на одном запросе к БД.

Третий способ, который мы ещё не пробовали, на в будущем наверное реализуем. Он заключается почти в полном отказе от работы с БД. Она работает с диском и поэтому ожидать от неё заметных скоростей не приходится. Да и как быть, если изменения происходят так часто, сильно нагружают БД?

В первых двух случаях мы имели ситуации, когда данные сначала попадали в БД, а только потом менялись в кэше. Но ведь можно сменить направление синхронизации и сначала обновлять данные в кэше, а потом, скажем раз в час, читать их из кэша и записывать в БД. Конечно это грозит потерей данных из-за отключения питания или из-за вытеснения редко используемых ключиков из memcached-а. Но для некоторых задач это вполне приемлемо.

P.S.
Если бы к memcached-у прикрутили бы хранение списка с возможность писать в его начало или конец, цены бы ему не было.

Категории: Оптимизация, Memcached, MySQL
комментировать 2 комментария | Прoкoммeнтировaть
Как ещё больше повысить эффективность кэширования? Михаил 16:30:33
Анализируя сегодня эффективность кэширования, я решил посмотреть кто же те люди, которые создают больше всего промахов, при обращению к кэшу, по каким страницам они ходят и что можно предпринять, чтобы лучше кэшировалась часто востребованная информация.

Выяснилось, что основные генераторы кэш-миссов - это поисковые боты. Они ходят по сайту совершенно непредсказуемо, уменьшая эффективность кэширования дважды. Во-первых, они генерят много промахов при обращении к кешу. Во-вторых забивают его редко используемой информацией, к которуй обычные пользователи не обращаются.

Исключение составляет наверное только бот Рамблера, который заходит на субдомен с дневником, весь его выкачивает, а потом принимается за следующий дневник. После первого его обращения 90% странички дневника лежит в кэше, и остальные странички генерятся быстро и не создают нагрузку на БД.

Выскажу предположение, что при ограниченном размере кэша можно повысить его эффективность, не сохраняя в данные, если запрос пришёл от бота.

Категории: Оптимизация, Офис, Memcached, Рамблер
Прoкoммeнтировaть
вторник, 4 сентября 2007 г.
Мониторинг memcached-а Михаил 14:31:22
Странную картину я наблюдал последние 2 недели. После рестарта memcached плавно всасывал в себя всё больше ключиков, и вроде как со временем эффективность кэширования должна была расти. Но по статистике выходило иначе. Число промахов при обращении к кэшу держалось на уровне 10% . Когда сегодня мы решили логировать промахи, то оказалось, что кэширование некоторых объектов оказалось неэфективным.

К чему собственно этот пост. А к тому, что даже если кажется, что всё кэшируется правильно, то бывает очень полезно проверить свои догадки на деле. Да и вообще, мониторинг - чертовски полезная штука.

Категории: Оптимизация, Memcached, Офис
комментировать 3 комментария | Прoкoммeнтировaть
воскресенье, 2 сентября 2007 г.
Теперь без handshake-а Михаил 20:12:31
Посмотрел на себя со стороны и понял, что занимаюсь псевдо-умной работой: включаю лог медленных запросов в mysql, жду пока он станет большим, выключаю лог, натравливаю на файл лога агрегатор, смотрю начало файла, выданного агрегатором и принимаю одно из решений: переписать sql-запрос, разбив его на несколько более простых или закэшировать его результаты в memcached-е. Второе решение принимается тогда, когда первое неприемлемо. Например, запрос и так уже простой.

Фактически я занимаюсь однообразной и цикличной работой, которую впору передать компьютеру.

Если развить эту мысль дальше, то вырисовывается интересная картина. Представьте, что некто заходит на страничку своего дневника, делая запрос к веб-серверу. Запрос получает nginx, проксирует его Апачу, тот делает несколько запросов к memcached-у и mysql-ю. Запрос от nginx-а к Апачу идёт по tcp/ip, а это значит, что им надо сначала сделать handshake, а только потом перейти к передаче запроса и получения ответа. И так много-много раз. И всё потому, что нам нужно точно знать, что выполнится какое-то условие. Например, что пакеты не потеряются. Но ведь обычно они не теряются! Неправда ли, не очень эффективно каждый раз делать то, что почти никогда не нужно, только ради это редкого "почти".

А сколько всего прочего делается внутри компьютера только ради редких исключений. Например тот же HTTP сделан легко читаемым людьми только из-за того, что один миллиардный запрос посмотрит какой-то админ и поймёт, что и как в нём запрашивается. А бедный компьютер парсит все эти текстовые заголовки, хотя ему было бы намного проще работать с байтами, а не с текстом.

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

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

Таким способом мы сможем избавиться от множества "лишних" проверок, немного почистив код. Но код оперирует данными, а в них порой тоже множество лишней и никому не нужной информации.

Следующее, что можно мониторить - это востребованность тех данных, которые создаются и потребляются. Хороший пример - процесс соединения по tcp/ip между двумя программами, запущенными на одном сервере. В нём происходит много лишних действий, например handshake, не нужный в подавляющем большинстве случаев. Оптимизатор тут может сработать следующим способом: заметить, что код, отвечающий за передачу данных между двумя программами, всегда выполняется по одному и тому-же сценарию. Конечно, где-то алгоритм будет ветвится, но эти куски нас не интересуют. Нам нужно получить список кусков кода, которые всегда выполняются одинаково. Зная его, мы можем начать менять поведение алгоритма передачи данных, отключая те или иные вызовы функций в его начале, и потом наблюдая за теми местами в его конце, которые стали вести себя иначе. Найдя такое место, мы можем исправить в нём условие так, чтобы алгоритм шёл по тому-же пути, что и ранее. Тем самым мы сохраним поведение алгоритма, удалив из него ненужные функции.

Следующей ступенью может стать изменение самих данных. Например, читабельность HTTP хороша для человека, но вредна для компьютеров, с ним работающих. Не плохо было бы обмениваться бинарными данными, а не текстовыми. Поэтому было бы здорово провести нечто подобное предыдущей ступени, только вместо удаления вызова функции, мы сделаем вызов другой функции. Надо только придумать какой функции и на какую функцию менять во второй части алгоритма, чтобы путь его прохождения.

Если посмотреть на первую и вторую оптимизацию, то возникнет ощущение, что в итоге может получить нерабочий код. Но тут всё дело в величине накопленной статистики, которая скажет нам, постоянен ли тот или иной участок кода или нет. И я не уверен, что результирующий код будет содержать намного больше ошибок, чем изначальный, написанный человеком.

Описанный оптимизатор служит цели ускорить код за счёт потери его универсальности.

P.S.
Надеюсь всё это вычитать и переписать более структурированно.

Категории: Мысли, Оптимизация
комментировать 1 комментарий | Прoкoммeнтировaть
Вечная жизнь или реконструкция в будущем? Михаил 19:04:28
Ядерный взрыв. Эти тысячи атомов, от которых отваливаются протоны... Хотят ли атомы жить вечно? Если б они хотели, то возможно догадались бы, что это возможно. Смотрите сами.

Представьте суперкомпьютер, раз за разом моделирующий ядерный взрыв и заставляющий снова и снова "жить" распадающиеся атомы.

Далее перемещаемся на несколько лет в будущее и перемещаемся в наручный калькулятор, который уже умеет моделировать ядерные взрывы и как раз именно сейчас занят им в очередной игре, охватившей разум хозяина калькулятора.

И выходит, что атом, живёт вечно, много раз и часто даже одновременно проживает несколько своих жизней! И всё потому, что он кто-то когда-то открыл, что изотоп урана может участвовать ядерной реакции, а наш атом оказался именно таким изотопом урана.

Так и мы, люди, можем жить вечно, если также востребованы и незаменимы в текущей жизни. Ибо как же без нас сможет на пятёрку сдать свою домашнюю работу второклассник из далёкого будущего, получивший задание смодерировать жизнь своих древних предков. :-)­

P.S.
Как то я задавался мыслью, кто же выдумывает религии... Оказывается всё проще. Они сами лезут в голову, нужно только успеть их записать.

P.P.S.
Не знаю как Вы, но мне подобная реконструкция по душе. Уж лучше так, чем никак. Наверное...


Хочется: не забыть мысль для следующего поста
Категории: Мысли, Матрица
комментировать 2 комментария | Прoкoммeнтировaть
понедельник, 27 августа 2007 г.
Почему домен должен писаться однозначно? Михаил 18:27:26
Потому что иначе люди будут писать его вот так:

yander.ru
yendex.ru
yandekx.ru
jandex.ru
ayndex.ru
yandrx.ru
yandax.ru

или так:

ramblr.ru
rambler.com
ramber.ru
rmbler.ru
ramblrer.ru
rabler.ru

А потом говорить, что у них почему-то почта не доходит или пароль их украли или ещё что-то. Кстати, этот список совсем не полный, а некоторые домены из него работают, но при этом не принадлежат понятно каким компаниям.

Источник доменов: очередь ожидающих отправки сообщений нашего почтового сервера.

Категории: Идиоты жгут, Яндекс, Рамблер
комментировать 2 комментария | Прoкoммeнтировaть
пятница, 24 августа 2007 г.
Кто же кликает по рекламе? Михаил 09:59:36
Недавно пришла идея провести эксперимент и узнать, кто же кликает по рекламе на beon.ru . Мне казалось, что зарегистрированные пользователи не должны по ней кликать вообще, ибо у них глаз замылен и он автоматом фильтрует места размещения рекламных блоков. Оказалось, что это не совсем так.

Я разместил и настроил код clickaider.com так, чтобы он измерял тип юзера: гость или залогиненный юзер и год/месяц его регистрации.

Вот данные по тому, какой тип пользователей кликает по рекламе:
­­

Вот данные по году и месяцу регистрации пользователей:
­­

Второй график требует перевзвешивания, ибо скорость регистраций с каждым месяцем растёт. Кроме того, там отброшен недлинный хвост из тех пользователей, которые зарегистрировали в 2006 году. Их несравненно мало, относительно того, сколько решистрируется сейчас.

Даже без перевзвешивания второй график показывает, что "сторожили beon-а" кликают по рекламе заметно реже, нежели новички.

Также интересен график, показывающий откуда изначально пришли на сайт посетители, прежде чем они кликнули на рекламу:
­­
(график называется "Original Referer Domains" в clickaider.com )

Из него видно, что стороннего трафика очень мало. А если на этом графике отобразить людей, у которых реферрер пустой, то стороннего трафика становится ещё на 30% меньше. Сие есть наглядный пример того, как можно зарабатывать на рекламе без поискового трафика.

P.S.
Измерялись клики по рекламным блокам Google Adsense.

P.P.S.
Осталось только слезть с иглы рекламной бизнес-модели и можно будет заявить о своей полной независимости :-)­


Категории: Блоги, Кликайдер
комментировать 2 комментария | Прoкoммeнтировaть
понедельник, 20 августа 2007 г.
Thoughts on the Social Graph Михаил 16:24:22
Брэд Фицпатрик отличную статью http://bradfitz.com­/social-graph-proble­m/ о проблеме развития социальных сетей и том, во что всё это может в будущем превратиться и почему.

P.S.
Виктор Шепелев пишет примерно о том же: http://webplanet.ru­/column/service/shep­elev/2007/08/15/vill­age.html .

Категории: Мысли, Брэд Фицпатрик, Социальный граф
Прoкoммeнтировaть
воскресенье, 19 августа 2007 г.
Очень поучительная история Михаил 08:43:10
Вот такое письмо я получил сегодня:

-------------------­--------------------­--------------------­---------------

Subject: Google Adsense disabled Mon.itor.Us! Now you can place your ads

Although on the positive side it accelerated our plans to sell ads directly.
We offer our customers sponsorship ad units, served in the top, right and
bottom areas on our website and blogs. If you are interested in securing a
premium sponsorship at mon.itor.us please contact us to
advertise@mon.itor.­us. Before opening the offer to public and contacting ads
providers we want our customers to use this opportunity first. We have very
targeted traffic and our visitors are businesses and owners of websites,
blogs, forums, etc. Mon.itor.Us pages and blog will be an ideal place to
advertise hosting, web design and development services, web promotion,
Internet application and services, business services, etc. We are going to
use popular ads management software so we will provide our customers with
detailed reports.
We also want to mention that we are interested in new monitoring locations,
and will provide banner space in exchange to hosting.

We are looking forward for your sponsorship.
Best regards
Mon.itor.us Team

Thank you for your appeal.

After receiving your response, we re-reviewed your account data
thoroughly. We have reconfirmed that invalid clicks were generated on the
ads on your site in violation of our Terms and Conditions and program
policies.

https://www.google.­com/adsense/terms
https://www.google.­com/adsense/policies­

We have these policies in place to help ensure the effectiveness of Google
ads for our publishers as well as our advertisers. According to our policy
on this matter, we are unable to reinstate you into the program.

As you may know, publishers disabled for invalid click activity are not
allowed any further participation in AdSense. For this reason, you may not
open a new account.

Please bear in mind that subsequent or duplicate appeals may not be
considered and you may not receive any further communication from us. We
appreciate your understanding.

-------------------­--------------------­--------------------­---------------

Mon.itor.Us - это вебдванольный сервис по мониторингу доступности сайтов. Год наад он мне показался интересным, я в нём зарегался и работал параллельно с Host-Tracker.com . Ещё я использую mralert.com , но он протух со временем. Мониторинг с интервалом в 30-40 минут мне не нужен. Ну да я отвлёкся...

Не буду защищать или обличать Mon.itor.Us . Хочу лишь заметить, что полагаться только на один источник дохода не стоит.

Категории: Монетезация, Web 2.0
Прoкoммeнтировaть
суббота, 18 августа 2007 г.
Идея сервиса... Михаил 08:23:53
К сожалению, всё ещё большинство людей проводит кучу времени пялясь на экран телевизора... А на нём этим бедным людям показывают, мягко говоря, много рекламы. Один мой знакомый как-то пытался написать программу, распознающую рекламу. Не знаю что тогда у него вышло, но сама идея иметь возможность отключать рекламу показалась интересной.

Так моя идея до безобразия проста и наверняка кто-то уже что-то делала/ет в этом направлении. Заключается она в следующем: как только по телику начинается или кончается реклама, человек кликает на кнопку с название телеканала и информация уходит на Ваш сервис. Он её обрабатывает, отсекая случайные клики. И потом распространяет на компьютеры всех тех, кто решил подключиться к сервису. Для тех, кто сабмитит информацию о рекламе - сервис бесплатный. Для всех остальных - платный, скажем 1$ в год.

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

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

И самый главный плюс: этот сервис приблизит момент падения телевизионных рекламных бюджетов и увелит приток рекламных денег в инет.

P.S.
Возможно вырезать рекламу намного проще. Например на всероссийских каналах она должна быть точно привязана ко времени, ибо региональные ретрансляторы должны знать, когда вставлять свою локальную рекламу.

Категории: Мысли, Web 2.0
Прoкoммeнтировaть
среда, 15 августа 2007 г.
Новая профессия Михаил 15:17:01
Дор-девелопер. :-)­

Категории: Юмор
Прoкoммeнтировaть
Футболки выгоднее 3gp Михаил 07:29:40
Проводили очередной эксперимет с монетезацией трафика на наших блогхостингах. Выяснилось, что продавать футболки выгоднее, чем продавать 3gp-видео для мобильных телефонов. Причём в несколько раз.

Задача ставилась простая: без влезания в дебри партнёрок, без программирования с нашей стороны найти то, что продаётся. Мы однажды уже обожглись, потратив много сил на реализация sms-рейтинга и получив продукт не окупивший затраты себя. Поэтому теперь мы решили ограничиться только размещением банера 728х90.



Категории: Web 2.0, Блоги, Монетезация
Прoкoммeнтировaть
 


Блог Монашёва МихаилаПерейти на страницу: « предыдущуюПредыдущая | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | следующуюСледующая »

читай на форуме:
пройди тесты:
Чармикс,Энчантикс,или Беливикс.
Тайны сердца. В чем его сила? (5)
читай в дневниках:
Сменила
...
...

  Copyright © 2001—2018 MindMix
Авторами текстов, изображений и видео, размещённых на этой странице, являются пользователи сайта.
Задать вопрос.
Написать об ошибке.
Оставить предложения и комментарии.
Помощь в пополнении позитивок.
Сообщить о неприличных изображениях.
Информация для родителей.
Пишите нам на e-mail.
Разместить Рекламу.
If you would like to report an abuse of our service, such as a spam message, please contact us.
Если Вы хотите пожаловаться на содержимое этой страницы, пожалуйста, напишите нам.

↑вверх