Daos и охренительные нагрузки :)
08.10.2010 мои проекты технологии
И снова стоит обновиться! Скачайте новую версию прямо сейчас. В ближайшее время владельцы нескольких довольно крупных сайтов планируют установить Daos, так что я снова задумался о надёжности записи/чтения файлов и сделал теперь просто НЕУБИВАЕМО. То есть я могу просто удалить файл со статистикой, а она всё равно воскреснет.
Программистам, возможно, будет интересно решение. Оно здесь, в двух функциях. Обсуждение проблемы было пару месяцев назад у меня в блоге, я тогда выбрал вариант лучше изначального, но всё же сейчас ещё лучше на порядки.
Краткое объяснение алгоритма
Перед записью в файл, с него делается резервная копия. После чего файл переименовывается, чтобы к нему не было доступа, спокойненько записывается и переименовывается обратно.
Чтение же происходит в несколько попыток (доли секунды) — если файла нет (значит в него идёт запись или что-то случилось), ждём 5000 микросекунд и пробуем открыть снова. Если файл так и не находится на протяжении нескольких циклов (100), тогда открываем резервную копию.
Надёжней просто некуда уже.
Обновитесь! Просто распакуйте новую версию поверх старой установки. Файл статистики не пострадает, всё плавно перейдёт на новый алгоритм. Я доволен, хорошую работу сделал.
Комментарии
Комментирование этой статьи закрыто.
« Demotivation.ru: стоит ли размещать там свою рекламу? И снова о том, как портить хорошие идеи »
Хотя сейчас вижу, как ещё улучшить можно. Ну да ладно, вероятность проблем, о которых я подумал, сравнима с угрозой космического вторжения.
Тормоз, ты хорошую работу сделаешь, если оно будет самообновляться, или где-то в админке по нажатию какой-то кнопки, или по отсыланию какого-то email.
А ручками обновляться каждое утро – народу больше делать нечего? Я удивляюсь, почему до сих пор все не взвыли…
А что сложного? Скачал архив, распаковал. Автоматическое обновление тоже далеко не каждого устроит, это небезопасно. Нужно ведь тогда все каталоги на запись открывать.
Тем более, я никого обновляться не заставляю — если кому не нужны улучшения, пусть сидят на старых версиях.
А ты действительно тестил это под нагрузкой? Или это просто тебе кажется, что так не будет тормозить и глючить?
Эмулировал стресс-тесты, кроме того есть несколько пользователей с посещаемыми сайтами.
Почему ты так спрашиваешь? Если есть сомнения, высказывай с конкретикой.
/И снова стоит обновиться!
Вот поэтому я никогда сразу на новую версию не перехожу…
Тормоз, не изобретай велосипед… Сделай просто два формата сохранения данных – в файлах и mysql, с возможностью выбора во время установки и апгрейда в случае нужды. Для небольших сайтов можно будет не заморачиваться с создание базы, а у крупных данный файл со статистикой не будет бутылочным горлышком (просто представь гипотетическую ситуацию – на сайте 100 рабочих строчек, еще 900 в архиве, посещаемость 10000 показов в день – сколько времени будет тратить скрипт на работу с файлом).
Я еще не копался в исходниках, и не знаю, насколько у тебя все продумано под такие случаи, но уверен – скорость работы mysql в разы выше файлов. Да и ту же статистику подбивать проще.
Spryt, в Daos 2.0 примерно так и будет, а в этот код я точно не буду ещё и MySQL запихивать, нет смысла.
А вот твоя уверенность про скорость обработки данных в сравнении с MySQL вполне может оказаться напрасной :) Тестировать надо, наугад такие предположения не стоит делать.
На какие только ухищрения ты не идешь, чтобы не использовать БД :-)
Навскидку пять проблемных моментов:
1) if (date(‘s’) == 1) не гарантирует, что очистка будет происходить раз в секунду. Может запуститься одновременно десяток процессов очистки, которые будут мешать друг друту, а может и годами не выпадать ни одного запроса на первую секунду.
2) scandir() и fnmatch() проще заменить на glob() – будет быстрее, а функция ровно та же.
3) условие filemtime(‘var/’.$file) < $currentTime тоже выглядит странно, ибо никто не гарантировал, что файл, измененный секунду назад уже никому не нужен. Более того, он могу быть создан меньше секунды назад – в конце предыдущей секунды, а проверяем в начале следующей.
4) Рекурсия – дорогая штука, как по памяти, так и по процессору, и где можно ее нужно заменять циклом, где это не вызывает проблем. И у тебя как раз тот случай.
5) Холостой цикл, а у тебя именно он и есть, – это вообще плохо в плане нагрузки на проц.
Дружище, вот у меня сделано всё максимально удобно и просто, и всё равно лишь один из десяти купивших дистрибутив пользователей соизволит его посмотреть и поставить. А если ещё надо разбираться, как базу делать на хостинге и подключаться к ней — процент ещё меньше будет.
Я противлюсь MySQL не только потому-что нет опыта работы с БД, но и прежде всего из этих соображений.
А мне не нужна такая гарантия. Это сделано, чтобы код очистки (который вряд ли понадобится вообще) не нагружал систему зря постоянно.
Ты прав, не подумал. Но это мелочи.
Это не страшно. Ты не вкурил суть :)
Тесты проводил?
Проводил тесты?
>так что я снова задумался о надёжности записи/чтения файлов и сделал теперь просто НЕУБИВАЕМО
Дежавю какое-то:)
Просто помню как обламался с каталогами – при >1000 элементов скрипт начинал ощутимо тормозить (естественно, никакой оптимизации не было – просто всё в одном файле). С тех пор стараюсь все важные и объемные данные записывать в БД. А по скорости – думаю, создатели БД не дураки, и наиболее частые обращения просто кешируются в памяти (да и вообще, они для этого и были созданы – чтобы проще хранить данные).
Конечно, в некоторых случаях использовать файлы гораздо проще и удобней, но не в случае продажи рекламы. Хотя, раз уж это доработка – с такой «неубиваемостью» это решит все проблемы с файлами, которые были до этого.
PS. Как решаешь проблему скликивания?
>создатели БД не дураки, и наиболее частые обращения просто кешируются в памяти
Не нужно надеяться непонятно на что, а почитать про оптимизацию. Про индексы например
Проблемы скликивания просто нет, не за клики же оплата. Хотя, сперва почему-то находились умники, но просто фильтруется по IP, считаются только уникальные.
Дело в том, что оно не гарантирует так же, что очистка вообще хать когда-нибудь произойдет. Если к скрипту нет запросов, то и бог с ним.
А если есть, но чиститься не будет, то это уже хуже. Вообще, наиболее популярный вариант решения данной проблемы – это создания файла-метки, дата модификации которого равна дате последней очистки и перед очисткой проверяется это время, и если оно было N минут назад, то делается touch() и запускается очистка.
Понятно, что при большой посещаемости вероятность, что очистка никогда не сработает исчезающе мала, но тут есть шанс, и большой, что два запроса в одну секунду запустят две очистки параллельно и будут удалять файлы из-под носа друг у друга. Самый очивидный результат – ворнинги из-за попытки вызвать filemtime() для несуществующего файла.
Если кратко, то да. И не только я – это классика жанра.
Да обязательно она произойдёт хотя бы раз в сутки, если на сайт не полторы калеки заходит. В любом случае каталог не успеет засраться мусором. В том числе и потому, что эта функция очистки — просто подстраховка, мусор появиться может только при наличии очень редких нештатных ситуаций. Согласен?
Насчёт тестов. Рекурсия, опять же, вызывается при не очень вероятной ситуации одновременного доступа к файлам, и количество проходов даже в этом случае вряд ли будет существенным, чтобы сильно заморачиваться и менять рекурсию на цикл.
И только если на огромнейшем сайте вдруг выяснится, что именно это — узкое место (крайне маловероятно), можно и оптимизировать ещё сильнее.
Попов-style)))
Не надо меня сравнивать ни с какими Поповыми.
точно Попов :)
для продаваемого продукта – такие вопросы и такой код – просто сакс.
БолгенDaОS ;))
Без обид ;)
Да кто ж на глупость обижается?
А у меня пропал файл сегодня, однако.
Обкатывал DAOS после 30-40 тыс. показов все реклы слетели.
Вот блин. Значит придётся ещё с этим кодом мудрить, а я хотел уже закруглиться и новых версиях в этой ветке не делать.
Постараюсь в ближайшее время исправить. Mob, попробуй удалить var/stat.php. Но скорей всего не поможет, как я теперь понимаю, при подобных крушениях в бэкап потом тоже попадают неправильные данные.
Проблема в том, что поскольку я был уверен в этом алгоритме, проверялось лишь наличие файла, но не проверялась целостность полученных данных.
Исправлять, наверно, не буду до тех пор, пока не пойму, что точно происходит. Пожалуй, стоит даже снова позвать монстров от программирования на помощь, обмозговать вместе.
Приношу свои извинения. Очень неприятная ситуация.
Вау, нифига у тебя сайтище! 100 показов открутились за 10 секунд. Отлично. В смысле для теста здорово, а вообще CTR микроскопический, конечно, вернее он вообще нулевой. Все пользователи с поисковика? Или вообще боты?
Нет не боты, отчего же. CTR на сайтах подобного плана появляется при 30 тыс и выше показах. Так сегодня крутил 2 ссылки, он был на уровне 0,5-0,7%, что хорошо для развлекалки. А потом «бах» и нет ссылок, благо свои тестовые.
А так 200 тыс. показов в сутки откручивает.
Так что же делать с падениями то?
Как CTR может «появиться» при увеличении количества показов? :) Это всё же статистическая величина. CTR может сильно скакать при маленьких количествах, там случайности много значат. Но при 1000 и более показов его значение вряд ли будет гулять в широких пределах.
А сколько было падений, как часто они происходят? Я пока не знаю чего делать, изучаю вопрос. Когда пойму точно, почему это происходит, смогу выпустить обновление.
P.S. Изучаю даже не я один, мне помогают, за что всем большое спасибо.
Странно, но зависит, раскочегаривается что ли. Да и Ваша тестовая ссылка для этой тематики никак не даст CTR хороший. Тут по тематики бить надо.
Падение было одно – тупо все пропало.
Вообще, интересный эффект. Думаю, он объясняется тем, что есть какой-то предел у нас в мозгу, после которого повторение в глаза определённой строчкой начинает привлекать бОльшее внимание :)
Но в любом случае я считаю, что 4 клика с 10 тыс. показов — это вообще не нормально.
Извините, за «тыканье», я обычно на «ты» и показалось, что мы с вами знакомы.
А ваша ссылка открутилась? Уведомление пришло?
Может уже стОит сделать форум поддержки своих продуктов?
А то в комментах саппортить не серьезно.
Аська есть?
Ссылка открутилась, уведомление пришло. Аськи нет и не будет :)
А тебя, getlife, я не узнал в гриме. Может прекратишь эти SEO-эксперименты? Есть ник, так пользуйся им. А то getlife вместо ника — это «не серьезно».
Профилирование проводилось? Воспользуйтесь iotop и lsof
А что оно даст, это профилирование? Мы узнаем, какие места наиболее затратные и всё.
Мне – ничего.
Опять вроде слетело и что самое интересное и стили слетели, гляньте как стал выглядеть блок сейчас.
Можете сбросить мне на brokenbrake@gmail.com содержимое каталога var установленной системы?
Тормоз, если надумаешь БД, то (как вариант) – можно использовать базу от WP. При установке давать флажок «Использовать БД блога», инклюдить ../wp-config.php, потом создавать там таблицу для Даоса и – профит, не нужно вводить отдельных настроек
Интересная идея! Спасибо. Подумаю об этом. WP сейчас у каждого второго, если не больше.
Главное, чтобы это не было единственным способом использования Даоса с БД.
Единственным не будет. Вообще, предварительно планировал только два варианта: SQLite и файлы, причём прозрачно, не нагружая пользователя принятием решения о выборе.