Реально, проверено на людях (на себе). Вот третий год идёт уже. :)
Ну правда доля интернета была не так велика, основное делается уже в реале.
Сначала записывал в базу айпишники как есть, в виде строки. На php считал простым перебором: доставал айпишник, сравнивал через strstr присутствует ли он в контрольной строке, если нет - добавлял его туда и увеличивал счётчик, если присутствует - дальше.
Время работы скрипта замеряю на одинаковом размере таблицы с айпишниками, 150 000 строк. в целом задача придумалась такая: нужно прописать некоторым страницам сайта количество уникальных просмотров. При этом предусмотреть рост посещаемости, как постепенный, так и скачкообразный (на прошлой неделе в какойто день к обеду было уже 45 000 человек и 800 000 просмотров).
Есть список чуть меньше 20К страниц, для которых нужно посчитать уников за определённый период. На входе есть этот урл, виде срс32, он же есть в таблице с просмотрами, в которой в худшем случае 150 тысяч строк, в лучшем (для кошелька) - 800-1000 К. Берём каждый урл из 20 тыс, находим в таблице, куда записываются просмотры и считаем количество уникальных элементов в такой выборке. Урлы, которые нужно искать лежат в другой таблице (извлекаются туда предыдущей операцией з большой таблице с просмотрами, занимает пару секунд, перебор-инсерт с условиями). Играюсь по всякому.
Такой метод требует в 300-500 раз дольше времени.
INET_NTOA делает тоже самое, только уже в базе. Эта функция применяется ещё при изначальной записи статистики в базу. На момент обсуждаемой операции мы имеем уже базу, где грубо говоря два целочисленных столбца - урл и айпи.
Структура примерно такая:
1 таблица: Каждая строка соответствует одному просмотру страницы, в ней два числа, одно - урл, второе - айпи, записанное туда функцией INET_ATON. Контрольная выборка для замера 150К строк.
2 таблица: список урлов где они не повторяются. 20К строк.
Вся обсуждаемая операция прописывает во второй таблице значения уникальных просмотров данного урла, содержащихся в первой таблице. :) Запросто может быть какойто хитрый умный путь сделать это одним запросом, я какгрицца не волшебник, тока учусь, и нужно это всё в принципе просто фор фан ))
nocomments добавил 01.12.2010 в 23:24
А тут немного другая ситуёвина, 8 ядер по 1,6Ггц, 8 гиг памяти и всё практически эксклюзивно под этот проект :)
Ждал пока накопится вчерашнее количество, чтобы сравнить скорость. После изменение формата записи айпишников в базу, получилось 3 минуты, т.е. как средствами php, отлично, резерв есть. Как записать в виде 4 байт не понял, если конвертить через chr - получается абракадабра (некоторые символы непечатные, не знаю как отнесётся к этому varchar). Записываю в виде INET_NTOA('x.x.x.x') в поле unsigned int. В принципе выигрыш значительный, solved.
seraphim, если 0.7 сек это один запрос - это очень очень много, речь про время работы скрипта на обработку такого запроса 15-20 тысяч раз.
Dreammaker, спасибо, сейчас изменил запись ip со строки на INET_NTOA(...), накоплю количство элементов, посмотрю что там со скоростью.
Dreammaker, об этом пересчёте и идёт речь. При количестве урлов около 20 000 и количестве записей 150 000 обработка через выбоку SELECT DISTINCT идёт 10 минут. Простым перебором всех 150 тысяч - 3-4 минуты.
вот это даже не подумал. нужно покопать в этом направлении. спасибо!
По поводу текстовых лог-файлов, тут не очень подходит, нужно не просто количество, нужно количество уников по определённым страницам, поэтому параллельно идёт выборка, и этот запрос выполняется несколько тысяч раз.
nocomments добавил 30.11.2010 в 20:19
Вот это как раз такая обработка, просто исходные данные сразу в базе удобнее
Cufon пользую, любой ttf шрифт подходит, посетителю ничего качать и устанавливать не нужно. Если отключит - будет видеть стандартный шрифт.
Haker, ну людям какбы пофигу какие там у вас тексты, обновляется ли ваш сайт и как вы его называете.
Делайте чтобы народ ломился и ссылку друг другу передавал, остальное всёравно.
nocomments добавил 30.11.2010 в 17:27
И ещё микросовет, пишите просто "сайт", для кого он - чужая точка зрения не интересует в этом вопросе.
Это рейтинги посещаемости, подсчёт уникальных ip, от текстовых файлов для этого уже ушёл, в данном случае база предоставляет высокий уровень экономии.
Xoce, спасибо, результат получается тот верный, но это ещё дольше, ваш вариант 0.2240 сек., DISTINCT/num_rows 0.0007 сек. Вопрос в том, почему php эту операцию обрабатывает в три раза быстрее чем DISTINCT.
Докладываю о результатах вынужденного тестирования нагрузки на NHS-1 :)
Средняя посещаемость около 10-12К в сутки, (сумарно по нескольким сайтам, расположенным на сервере).
Пару дней назад одновременно два популярных сайта бесплатно сделали рекламу одному из моих проектов, расположенных на этом хостинге. За несколько часов сайт посетило около 30 тысяч человек, потом стало постепенно спадать, но ясно, что учитывая пиковый расклад как норму, это соответствует где-то 100 тысяч в сутки. В том виде, как это было настроено до этого, вечером предыдущего дня сервер начал ложиться при паре сотен человек в онлайне.
Проект, прочувствовавший бремя временной поплулярности с точки зрения трафика лёгким никак не назовёшь, и при этом средняя глубина просмотра - 13 страниц, большое время на сайте. Плюс в процессе пришлось перенести формирование кеша (под полмиллиона файлов) на этот же сервер - ранее кеш находился на другом сервере, который под нагрузкой сразу лёг без признаков жизни. Формирование кеша грузит процессор (работа с изображениями).
Техподдержка оперативно помогла перенастроить сервер, (плюс по ходу пьесы немного оптимизировал скрипты) - ещё когда была максимальная нагрузка держал спокойно, на пике в онлайне было около 2000 посетителей. Визуально, возможности по посещаемости конкретного, сравнительно тяжёлого проекта на данном серваке выглядят так: если вдруг среднем в сутки будут приходит максимально 200-250 тысяч человек при среднестатистической активности - проблем возникнуть не должно. (Осталось их както привлечь, результаты по рся в виде нескольких тысяч рублей за несколько часов очень понравились) :)
Выражаю публичную неприкрытую благодарность специалистам техподдержки FastVPS за помощь в бою под пулями :)
