Логирование руками. MySQL или файлы?

1. Запись в файл очень быстрая, быстрее чем в базу.

2. пишем в log.date("Y-m-d") , очищаем моментом, нужный срез так же. Не надо потом таблицу на крон для очистки и оптимизации ставить . Опять же, в бакап базы не попадает мусор

3. в любой момент делаем LOAD DATA через базу и нужный лог в таблице для анализа.

4. банально экономим процессорное время на не нужные проверки целостности, на обработку локов таблицы и т.п.

5. в отличии от базы, формат лога может быть любой.

Stek, ну зачем, Вы, как ни фига не понимающий в Вебе, лезете здесь со своими советами, а тем более с файловым решением для этого есть monstr? :) :) :)

А по сути, для логирования самое то - в файл.

А если еще и в реальном времени это надо, то из консоли tail -f

Это проблемы монстра, когда в интернете кто то не прав :D

Черт, пункт 6 так сказать :) Действительно очень удобно, когда скрипты пишут в лог (каждый в свой лог) , а ты в реал тайм режиме наблюдаешь что происходит. В случае же с базой придется уже писать свой мелкий скрипт.

Консоль? Не, не слышал:)

Спасибо за советы, есть над чем подумать.

ЗЫ. Монстр теперь будет походу "Фемида веб-девелопмента":)

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

При использовании базы данных для логирования ошибок, следует учесть вот какой тонкий момент: недавно я столкнулся, в одном из наиболее распространённых скриптов форумов, велось логирование ошибок в базу данных. При большой загрузке сервера, начинают возникать ошибки, типа "Lost connection...". Скрипт пытался записать в лог об этой ошибке, что естественно вызывало ошибку, которую он вновь пытался записать в лог... В результате, за сутки error_log вырастал до много-сотен-мегабайтных размеров.

Попробуйте сделать элементарный скрипт на запись через fopen('..', 'a'); Там все быстродействие упирается только в скорость файловой системы, а это тысячи записей в секунду.

Stek, не говори хоп, пока не перепрыгнул...

Вы никогда не сталкивались с обрезанными записями в логах?

на данный момент у ТС не есть высоконагруженной системы. Поэтому ФС справится без труда.

В случае больших нагрузок, возможно понадобится какая-либо надстройка, например,в виде APC, и по крону dump хеша в файл

only file

пример:

повисла БД...

писать в файлы, а потом по крону скриптом писать ошибки в БД и чистить файлы.

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

Ни разу. Зато с лог таблицами в базе по сотне гиг - сколько угодно. Особенно весело когда такая таблица в innodb на нагруженнном проекте, где ее фиг просто так дропнешь.

<?php

$start = microtime(true);
for ($i = 0; $i < 100000; $i++) {
    do_test();
}
$end = microtime(true) - $start;
print $end;

function do_test() {
    $fp = fopen('test.log', 'a');
    fwrite($fp, "test \n");
    fclose($fp);
}

100к записей за 9.0914931297302 , т.е. 10к записей в секунду. Это на виндах, на бюджетном 7200 диске. В базу думаю будет порядка 500-600 в секунду.

Когда у ТС будет такой траф для логов, то уж не думаю, что для него будет актуален метод логирования.

Stek, Это вы проверяли в монопольном режиме

а теперь

test.php

function do_test() {

    $test=$_GET['test'];

    $fp = fopen('test.log', 'a');

    fwrite($fp, "$test \n");

    fclose($fp);

}

start.php

$start = microtime(true);

for ($i = 0; $i < 100000; $i++) {

    file_get_contents("http://www.example.com/test.php?test=test$i");

}

$end = microtime(true) - $start;

print $end;

Это я на коленке... если есть ашЫпки, можно смело в лицо.