Журнал в файл через PHP или журнал к базе данных MySQL - который более быстр?

Question

Журнал в файл через PHP или журнал к базе данных MySQL - который более быстр?

context является вторым значением, передаваемым times, и становится значением специальной переменной this внутри функции из-за вызова f.call(context, i) (первое значение является значением this). [1115 ]

Number.prototype.times = function(f, context) {
    var n = this.valueOf();
    console.log(n);
    for(var i = 0; i < n; i++) f.call(context, i);
};

var n = 3;

n.times(function(n) { console.log(this, n); }, "hello");

Причина, по которой это выглядит странно, заключается в том, что this должен быть объектом, поэтому строка преобразуется в [ 118] объект (который похож на объект Array, следовательно, внешний вид массива).

Это более полезно в ситуациях, когда вы используете функцию prototype:

Number.prototype.times = function(f, context) {
    var n = this.valueOf();
    console.log(n);
    for(var i = 0; i < n; i++) f.call(context, i);
};

var arr = [1, 2, 3, 4];
(3).times(Array.prototype.reverse, arr);

console.log(arr);

11

mysql php

задан 8 October 2008 в 17:04

15 ответов

Другие вопросы по тегам:

mysql php

Похожие вопросы:

score 17 · Answer 1

Запишите в файл. Поверните журналы.
Пакетная загрузка файл к базе данных на запланированной основе.

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

score 0 · Answer 2

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

При тестировании MySQL попробуйте и MyISAM и INNODB. В теории Innodb будет работать лучше, поскольку он имеет блокировку уровня строки.

score 0 · Answer 3

Если это - для базы данных управляемый сайт, почему Вы не просто использование созданного в регистрирующихся возможностях Apache или IIS и подходящего инструмента создания отчетов, таких как AWStats и кроме того, всегда существует Google Analytics

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

score 0 · Answer 4

Все зависит от Вашей инфраструктуры и ограничений. Если диск будет медленным, то запись будет медленной. Если SQL-сервер будет изолирован запросами, то вставка будет медленной. Плоский файл является, вероятно, лучшим способом пойти, но я написал бы Ваш код или использовал бы существующий код (ГРУША:: Журнал), таким образом, можно изменить поставщика и метод устройства хранения данных по желанию.

score 0 · Answer 5

Несколько соображений:

Вы думаете, что захотите присоединиться к данным логов с другими данными в базе данных? Если так, издержки вставки дб, вероятно, выравниваются по ширине, таким образом, существующие отношения могут быть легко усилены.
Был бы, регистрируя данные в базе данных, позволяют Вам уменьшать объем данных, который Вы регистрируете значительно (из-за существующих отношений в дб)? Например, журнал в базе данных пользовательского действия мог просто быть таблицей, содержащей идентификатор пользователя, activityid, и метку времени. Файл журнала этот наклон в файле не был бы человекочитаем. В зависимости от Ваших потребностей необходимо было бы собрать по крайней мере некоторые данные пользователя в файле журнала, чтобы гарантировать, что это может быть полезно и человекочитаемо самостоятельно.
Шанс Вы захотите усилить это данные логов во фронтэнде или через административное средство в будущем? Если так, запись DB, вероятно, предпочтительна.

score 0 · Answer 6

В файл будет более быстрым, но в DB будет лучше.

0

ответ дан 3 December 2019 в 01:13

score 2 · Answer 7

Необходимо попробовать SQLite. Это даст Вам обоим скорость записи в файл, а также питание базы данных.

score 2 · Answer 8

Я прочитал статью в Пользовательском Журнале C++, несколько лет назад, о регистрирующейся производительности. Используете ли Вы DB или файлы, лучшая вещь сделать записать неформатированные данные, которые могут быть "расширены" в значимые данные, когда (и более вероятно если) необходимо просмотреть журналы. Подавляющее большинство стоимости входа является informatting строки, которые записаны в место назначения, и большую часть времени которые стоят, потрачен впустую - журналы никогда не читаются.

Я могу откопать ссылку статьи, если это полезно для Вас.

score 1 · Answer 9

Я сделал что-то подобное. Я регистрирую каждую запись на отдельный файл, затем у меня есть пакетная обработка, которая захватывает файлы, помещает их в файл tar и загружает их на центральный лог-сервер (в моем случае, S3 :)).

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

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

Я также раньше log4php+syslog-ng централизовал вход в реальное время. У меня есть журнал log4php к системному журналу, который затем вперед к журналам к моему центральному серверу. Это действительно полезно на больших кластерах. Один протест состоит в том, что существует предел длины сообщениям системного журнала, таким образом, Вы рискуете более длинными сообщениями, являющимися усеченным.

score 2 · Answer 10

Я полагал бы, что плоский файл будет быстрее для записи в.

2

ответ дан 3 December 2019 в 01:13

score 1 · Answer 11

Я рекомендовал бы протестировать обоих с несколькими тестовыми сценариями.

Я предположил бы, что плоский файл будет быстрее, b/c это действительно, что делает DB - он просто пишет это в файл. Единственное преимущество, о котором я могу думать, состоит в том, если база данных может работать одновременно, Вы могли бы получить лучшие результаты.

score 6 · Answer 12

Я использовал бы Отложенную Вставку в MySQL. Таким образом, Вы не должны ожидать вставки для окончания.

score 4 · Answer 13

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

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

Однако со всей этой производительностью имел отношение, единственный способ быть уверенным состоит в том, чтобы записать простой тест и измерить его....

Обновление: я сделал быстрый тест - и конечно же если необходимо открыть и закрыть файл, это о той же скорости или более медленном использовании теста 10 000 строк:

Однако, когда Вы начинаете иметь несколько процессов, делающих это, это замедляется как видно ниже. Это с 10 параллельными процессами (все синхронизации в секундах)

DB time: 2.1695
DB time: 2.3869
DB time: 2.4305
DB time: 2.5864
DB time: 2.7465
DB time: 3.0182
DB time: 3.1451
DB time: 3.3298
DB time: 3.4483
DB time: 3.7812
File open time: 0.1538
File open time: 0.5478
File open time: 0.7252
File open time: 3.0453
File open time: 4.2661
File open time: 4.4247
File open time: 4.5484
File open time: 4.6319
File open time: 4.6501
File open time: 4.6646
Open close file time: 11.3647
Open close file time: 12.2849
Open close file time: 18.4093
Open close file time: 18.4202
Open close file time: 21.2621
Open close file time: 22.7267
Open close file time: 23.4597
Open close file time: 25.6293
Open close file time: 26.1119
Open close file time: 29.1471

function debug($d)
{
    static $start_time = NULL;
    static $start_code_line = 0;

    if( $start_time === NULL )
    {
        $start_time = time() + microtime();
        $start_code_line = $code_line;
        return 0;
    }

    printf("$d time: %.4f\n", (time() + microtime() - $start_time));
    $fp = @fopen('dbg.txt','a');
    fprintf($fp,"$d time: %.4f\n", (time() + microtime() - $start_time));
    fclose($fp);

    $start_time = time() + microtime();
    $start_code_line = $code_line;
}

function tfile()
{
    $fp = @fopen('t1.txt','a');
    for ($i=0;$i<10000;$i++)
    {
        $txt = $i."How would you log, which do you think is quicker:How would you log, which do you think is quicker:";
        fwrite($fp,$txt);
    }
    fclose($fp);
}
function tfile_openclose()
{
    for ($i=0;$i<10000;$i++)
    {
        $fp = @fopen('t1.txt','a');
        $txt = $i."How would you log, which do you think is quicker:How would you log, which do you think is quicker:";
        fwrite($fp,$txt);
        fclose($fp);
    }
}

function tdb()
{
    $db = mysql_connect('localhost','tremweb','zzxxcc');

    $select_db = mysql_select_db('scratch');

    if (!$select_db) 
        die('Error selecting database.');

    for ($i=0;$i<10000;$i++)
    {
        $txt = $i."How would you log, which do you think is quicker:How would you log, which do you think is quicker:";
        mysql_query("INSERT INTO tlog values('".$txt."')");
    }
}

debug("");

tfile();
debug("File open");

tfile_openclose();
debug("Open close file");

tdb();
debug("DB");

score 2 · Answer 14

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

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

С входом базы данных можно, по крайней мере, сделать следующее [использование MySQL MyISAM]:

INSERT DELAYED INTO `hits` ...

См. 12.2.5.2. ВСТАВЬТЕ ОТЛОЖЕННЫЙ Синтаксис для получения дополнительной информации.

score 7 · Answer 15

Вы могли попробовать оба способа использовать log4php, который поддерживает:

Конфигурация через xml и файл свойств (та же структура как log4j).
Файл, RollingFile, DailyFile, Эхо, Консоль, Почта, ГРУША:: дб, ошибка PHP, события Syslog или NT и Сокет appenders.
Простой, TTCC, шаблон, HTML и разметки Xml.
Вложенный (NDC) и отображенный (MDC) контексты диагностики.
Переключаемая внутренняя отладка.

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