Кэширование файла

[dimagolov]

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

 

[OZ]

dimagolov, ерунда. Если есть сессии - то нужно искать только в них, естественно. Если нет - проще искать по таблице юзеров, чем создавать 2 таблицы и перекидывать юзеров между ними.

-~{}~ 13.07.07 03:03:

Да и вообще, вопрос звучал не о способе поиска, а о кэшировании результата.

 

[zerkms]

OZ

Да и вообще, вопрос звучал не о способе поиска, а о кэшировании результата.

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

 

[OZ]

zerkms, про глупых он будет прав. У него ОЧЕНЬ много пользователей и точность выдаваемого результата для него не критична. Ему нужно количество On-Line, но точность этой цифры не важна, а меняется эта цифра часто. Гораздо эффективнее обновлять эту информацию раз в 5 минут, чем 100 раз в секунду мучать базу оптимизированным запросом.

 

[zerkms]

Гораздо эффективнее

эффеективнее с какой точки зрения? а можно ознакомиться с результатами опытов?

про глупых он будет прав

тогда вопрос - какого, извиняюсь, хера, он пришёл спрашивать у глупых?

 

[OZ]

zerkms, можно было не хамить, чтобы не извиняться.
Не его вина в том, что отвечали глупые ему.

эффеективнее с какой точки зрения? а можно ознакомиться с результатами опытов?

Можно. Проведите их и ознакомьтесь. Если сомневаетесь, что легче отдать файл из нескольких бит, чем делать запрос к базе данных, то узнайте, как всё это работает. Желательно, на практике.

 

[zerkms]

OZ
ну уж, уважаемый, это вы сказали что "гораздо эффективнее". Поэтому хотелось бы узнать, чем вы руководствовались, когда писали эту фразу - реальными цифрами или картами таро.

 

[OZ]

zerkms, когда Вам говорят, что снег белый, Вы тоже спрашиваете, чем аргументировано данное утверждение?
Или Вы хотите сказать, что прочитать 5 бит (цифра количества on-line) сложнее, чем сделать запрос к базе данных? Вы говорите ерунду и просите доказать, что Вы неправы. Закончим дискуссию.

 

[zerkms]

хотя, мне в принципе не сложно и измерить

примитивный запрос vs получение int из файла (на 10000 вызовов): 0.548245 vs 0.362528

т.е. на каждый вызов мы имеем выйгрыш 2 * 10^(-5) секунды

это та самая огромная эффективность, о которой вы говорили?

-~{}~ 13.07.07 11:38:

OZ
прокомментируйте плиз результаты измерений, особенно в контексте своего утверждения и конкретно - слова "гораздо"

 

[OZ]

*ля, это уже троллизм.
zerkms, 10000 коннектов к базе вы тоже посчитали?
Если вы убеждены, что прочитать 5 бит также сложно, как создать коннект к базе данных + создать процесс для выполнения запроса + распарсить запрос + выполнить запрос (с поиском по диску и памяти) + ..., то я не смогу вас разубедить, бредьте дальше.

 

[zerkms]

zerkms, 10000 коннектов к базе вы тоже посчитали?

т.е. если он будет брать число посетителей онлайн из файла - то у него и к базе коннекта не будет? зачем ему тогда вообще БД?

создать процесс для выполнения запроса + распарсить запрос + выполнить запрос (с поиском по диску и памяти)

выполнение запроса + получение результата были в тестах
mysql_query() + mysql_fetch_array()
это 2 функции, которых за глаза - для выборки 1 числа (пользователей онлайн)

то я не смогу вас разубедить

конечно не сможете, потому что ляпнули херню, а увидев цифры пошли на попятную.... удачи...

 

[Андрейка]

в общем снег белый потому, что он холодный

оптимизаторы программок рулят

 

[OZ]

zerkms, а ты бэнчмарком протести 2 скрипта - который в базе ищет, и который из файла читает 5байт.

/*
До чего же тупыми люди бывают
*/

и к базе коннекта не будет? зачем ему тогда вообще БД?

коннект будет раз в 5 минут. читайте первое сообщение темы.

Даже если будет коннект у него, то поисковый запрос - это не выборка целога числа. Поисковые запросы - долгие.
Практики вам недостаёт явно.

удачи...

всего доброго.

 

[zerkms]

OZ
а ты думаешь - цифры чего я привел????

коннект будет раз в 5 минут. читайте первое сообщение темы.

а с какой стати - для получения числа пользователей онлайн надо будет делать ешё один? если и так он уже есть, для получения других данных??

/*
До чего же тупыми люди бывают
*/

и вправду, таких как ты - ещё поискать

 

[dimagolov]

OZ
про файл не все так просто как хотелось бы. файловая система в принципе не заточена на сотни одновременных запросов на чтение при паралельной записи в файл (каждые N секунд, но все равно паралельно чтению), в отличии от БД которая именно для этого затачивалась. подобные подходы оптимизации (будем писать в файл) видимо основываются на убежденности в том, что создатели движка БД лохи и не понимают как обрабатывать много запросов одновременно, а мы умные, мы будем базу беречь и силами скрипта интерпретируемого языка и его функций обращения к диску напишем намного более эфективное кеширование данных чем глупые авторы БД на сях и в критических секциях оптимизировав на асме.

 

[OZ]

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

А вообще, после вашего сообщения

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

Вам лучше ничего не советовать кому-либо по способам работы с базами данных.

 

[dimagolov]

Автор оригинала: OZ
Вам лучше ничего не советовать кому-либо по способам работы с базами данных.

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

 

[OZ]

dimagolov, я считаю, что обработать запрос вида
SELECT count(*) FROM `sessions` WHERE `time`>'...' AND `id`>'0'
по определению сложнее, чем прочитать 5 бит из файла, потому, что для обработки sql-запроса нам нужно совершить БОЛЬШЕ действий, чем для чтения файла. Причём обработка запроса ТОЖЕ совершает манипуляции с файлом на диске (не всегда, конечно) + дополнительные действия.
Про php-шные и сишные функции чтения файлов: взгляните на исходники. PHP-шные функции для работы с файлами это обычные пересылки параметров сишным функциям. Как и функции по работе с базами данных, между прочим.

-~{}~ 13.07.07 06:36:

А вообще, для кэширования такого маленького объёма информации лучше использовать shared memory.

Asafchik, shmop_open,shmop_write,shmop_read,shmop_close.

 

[Vitafresh]

OZ, от Вас раз десять прозвучало голословное утверждение о том, что одновременное обращение сотен(тысяч) пользователей к файлу ГОРАЗДО быстрее чем элементарная выборка из базы по индексированным полям.

Обоснуйте, пожалуйста, свое утверждение маленьким тестом. Иначе обсуждение теряет всякий смысл.

Я не имею достаточного опыта именно в PHP, но в том что файловые операции быстрее запросов к БД очень сильно сомневаюсь.

Даже в случае, если в файле хранится результат сложного (и "длинного") запроса, ИМХО проще этот результат сохранить в махонькую табличку и от туда его показывать.

Еще раз: Убедите в обратном не пустыми разговорами про гипотетическу "кучу действий" в БД, а реальным тестом.

 

[phprus]

OZ

5 бит

Что вы заладили 5 бит, да 5 бит?
Во первых выучите наконец математику, ибо в 5 битах можно закодировать числа от 0 до 31, а во вторых если у автора максимум 31 человек в онлайне, то вся таблица с сессиями уже давно лежит на сервере в кеше и по этому СУБД к диску ВООБЩЕ обращаться не будет (ибо все и так в оперативке).

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

SELECT count(*) FROM `sessions` WHERE `time`>'...' AND `id`>'0'
по определению сложнее

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