вторник, 5 июня 2012 г.

IPC::MPS was updated for Multiplicative Agent

IPC::MPS was updated for Multiplicative Agent.

Changes:
- connected flag in NODE_CLOSED
- your own pack and unpack functions, instead of Storable

First change is need to distinguish "Cannot connect to node" and "Node closed" states.

пятница, 25 мая 2012 г.

Деструкторы для замыканий

Периодически ловил себя на мысли, что хорошо бы, чтобы у замыканий были дестркторы. И лишь вчера осознал, что это можно легко организовать "вывернув" замыкания на изнанку. Рассмотрим в качестве примера следующий код:
 sub make_foo {
  my $foo = shift;
  print "INIT\n";
  return sub {
   $foo += shift;
   print $foo, "\n";
  };
 }
 
 {
  my $foo = make_foo(3);
  $foo->(1);
  $foo->(1);
  $foo->(2);
  $foo->(2);
 }
А теперь сделаем так, что замыкание не возвращается в функцию с действием, а передается ей в качестве аргумента. Это позволяет добавить деструктор сразу после вызова этой функции:
 sub with_foo {
  my $foo = shift;
  my $sub = shift;
  print "INIT\n";
  $sub->(sub {
   $foo += shift;
   print $foo, "\n";
  });
  print "DESTROY\n";
 }
 
 {
  with_foo(3, sub {
   my $foo = shift;
   $foo->(1);
   $foo->(1);
   $foo->(2);
   $foo->(2);
  });
 }

вторник, 15 мая 2012 г.

PostgreSQL, MySql and MariaDB as Key-Value storage

После сравнения BerkeleyDB и TokyoCabinet настало время посмотреть на PostgreSQL, MySql и MariaDB как на хранилища ключ-значения.

Использовался тот же  маленких сервачек.

PostgreSQL


postgresql-server v9.1.2

SET synchronous_commit TO OFF
commit_delay = 1

Во всех вариантах PostgreSQL заметно быстрей чем BerkeleyDB и TokyoCabinet! Разумеется это, когда объем базы превышал размер оперативной памяти.

С ростом базы замечено существенное снижение производительности, когда используется btree индекс.
Поэтому для очень больших баз и когда этого достаточно, стоит использовать hash индекс.


MySql and MariaDB


Для perl модуля DBD::mysql используется патч https://rt.cpan.org/Public/Bug/Display.html?id=76462,
чтобы при mysql_server_prepare не было утечки памяти.

mysql-server-5.1.61
mariadb-server-5.2.10

У сравнении участвовали:
MyISAM
ARIA
XtraDB (Innodb_flush_log_at_trx_commit=0)

HandlerSocket не использовался.

На маленьких базах и длинных ключах TokyoCabinet hash (не btree) быстрей в 3-5 раз чем MyISAM, ARIA и XtraDB.
На коротких ключах MyISAM быстрей в 5 раз.

Когда базы большие, то MySql and MariaDB вырываются вперед, даже XtraDB быстрей, чем TokyoCabinet.

Как и у PostgreSQL, с ростом базы замечено существенное снижение производительности, когда используется btree индекс.
Преимущества hash индекса (XtraDB) не сказалось, в отличие от PostgreSQL.


Выводы


Когда базы маленькие можно использовать TokyoCabinet или BerkeleyDB.
Когда данных больше, то стоить посмотреть в сторону MyISAM, ARIA (MariaDB) или PostgreSQL.
Когда базы огромные, то лучше использовать PostgreSQL с HASH индексами.

понедельник, 26 марта 2012 г.

BerkeleyDB и TokyoCabinet

Результаты двух недельноего стравнения BerkeleyDB и TokyoCabinet на стареньком компьютере.

BerkeleyDB::Recno, которые, кстати, сделаны поверх Btree, можно заменить "ручными очередями", сделаными на основе BerkeleyDB::Btree или TokyoCabinet::BDB, без потери производительности.

Настройками по умолчанию TokyoCabinet предназначены для маленьких баз. BerkeleyDB - для средних.

Для больших баз с соответствующими настройками BerkeleyDB::Btree и TokyoCabinet::BDB примерно одинаковы по производительности и размеру. Большие базы 5000000 записей, key 1040 - байт, value - 1000 байт.

Тестовый сервер:
CPU: AMD Sempron(tm) Processor 2800+ (1608.27-MHz 686-class CPU)
real memory = 8589934592 (8192 MB)
ada0: ATA-6 device
ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
ada0: 76318MB (156299375 512 byte sectors: 16H 63S/T 16383C)

А вот TokyoCabinet::HDB выигрывает в скорости и в размене у BerkeleyDB::Hash почти в два раза.

четверг, 23 июня 2011 г.

Закорючки, продолжение

Предположим, что вам необходимо множества раз писать данные в сокет, при этом задача не позволяет объединить все операции записи в одну.

Perl:
send $sock, $msg1;
send $sock, $msgN;

OZ:
{send Sock Msg1}
{send Sock MsgN}

Haskell:
send sock msg1
send sock msgN

Много раз повторяется "send sock" - попробуем избавиться от дублирования.

Perl:
my $snd = sub { send $sock, @_ };
$snd->($msg1);
$snd->($msgN);
# или &$send($msgN);

OZ:
local Snd = fun {$ M} send Sock M end
{Snd Msg1}
{Snd MsgN}

Haskell:
let snd = send sock
snd msg1
snd msgN

Как видим, Perl закорючки (@#$%&) путаются под ногами.

четверг, 2 июня 2011 г.

Закорючки

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

1. |----------------------------+---------------------------|
2. | Traditional syntax | Terse syntax |
3. |----------------------------+---------------------------|
4. | push @$arrayref, @stuff | push $arrayref, @stuff |
5. | unshift @$arrayref, @stuff | unshift $arrayref, @stuff |
6. | pop @$arrayref | pop $arrayref |
7. | shift @$arrayref | shift $arrayref |
8. | splice @$arrayref, 0, 2 | splice $arrayref, 0, 2 |
9. | keys %$hashref | keys $hashref |
10. | keys @$arrayref | keys $arrayref |
11. | values %$hashref | values $hashref |
12. | values @$arrayref | values $arrayref |
13. | ($k,$v) = each %$hashref | ($k,$v) = each $hashref |
14. | ($k,$v) = each @$arrayref | ($k,$v) = each $arrayref |
15. |----------------------------+---------------------------|

То есть, все идет к тому, что скоро закорючки (@#$%&) станут не нужны.
Если честно, раньше думал, что их наличии упрощает код. Меньше надо выдумывать имен и идентификаторов.
Однако, пописав на еще более высоком уровне (OZ, Haskell), понял, что иногда без них проще.

P.S.
А может просто руки болят?

среда, 23 марта 2011 г.

не-Perl

На прошлой неделе мне сразу два человека сказало (кажется даже в один день), что я пишу на Perl как не на Perl.
Забавно, но я использую обычно очень маленькое подмножество многоликого языка Perl.

P.S.
http://github.com/kni/redis-sharding/tree/v0.2
http://search.cpan.org/perldoc?IPC::MPS