Re: Функционал и интерфейс
В Пнд, 16/03/2009 в 14:40 +0300, Artem Chuprina пишет:
> Покотиленко Костик -> debian-russian@lists.debian.org @ Mon, 16 Mar 2009 12:06:13 +0200:
>
> ПК> $ progA | ssh user@host progB
>
> ПК> progA записывает каманду в вывод, команда улетает мгновенно в буфер
> ПК> ssh, в случае простого протокола, без подтверждения доставки progA
> ПК> будет считать команду доставленной, хотя на самом деле это ещё не
> ПК> так.
>
> Если она так думает в локальном случае, ее автора пора лечить :-) Никто
> никому никогда не гарантировал мгновенной доставки в случае с локальным пайпом.
>
> ПК> Кроме того часто тяжело заставить команды приходить раздельными
> ПК> порциями.
>
> Это тоже от сети не зависит.
>
> >> Потому что тогда не будет способа воспользоваться
> >> функционалом :-)
> >>
> >> Так вот, у классической юниксовой CLI-программы интерфейс рассчитан на
> >> юникс-юзера. Который ближе к разработчику, чем к энд-юзеру. И тем
> >> самым просто является таким же API, что и у библиотеки.
>
> ПК> Ну нет же. Разные они, если подробно разобраться. Учитывая
> ПК> вышесказанное, API - для низкоуровнего (производительного и компактного)
> ПК> программирования,
>
> Преждевременная оптимизация - корень всех зол. (c) кто-то из великих.
>
> ПК> CLI - для юникс-юзера и скриптов (по быстрому на коленке).
>
> ПК> На пример, для сбора счётчиков правил iptables можно использовать
> ПК> обёртку вокруг iptables -nvL | iptables-save типа:
>
> ПК> iptables-save | grep "<условие>" | cut -d" " -fI
>
> ПК> или такую конструкцию на Си:
>
> ПК> ...
> ПК> struct ipt_entry *ipt_e;
> ПК> char *target;
>
> ПК> for(ipt_e=iptc_first_rule(chain_name, &ipt_h); ipt_e;
> ПК> ipt_e=iptc_next_rule(ipt_e, &ipt_h)) {
>
> ПК> if(!ipt_e) {
> ПК> printf("iptc_first_rule(): returned NULL pointer\n");
> ПК> return(NULL);
> ПК> }
>
> ПК> if(!<условие>) continue;
>
> ПК> target=iptc_get_target(ipt_e, &ipt_h);
>
> ПК> printf("Source IP: %s/%s (iface: %s), Destination IP: %s/%s (iface: %
> ПК> s), Target: %s, Counters: %llu bytes, %llu packets\n",
> ПК> x_strcpy(inet_ntoa(ipt_e->ip.src)),
> ПК> x_strcpy(inet_ntoa(ipt_e->ip.smsk)),
> ПК> ipt_e->ip.iniface,
> ПК> x_strcpy(inet_ntoa(ipt_e->ip.dst)),
> ПК> x_strcpy(inet_ntoa(ipt_e->ip.dmsk)),
> ПК> ipt_e->ip.outiface,
> ПК> target,
> ПК> ipt_e->counters.bcnt,
> ПК> ipt_e->counters.pcnt
> ПК> );
>
> ПК> }
> ПК> ...
>
> ПК> Первый вариант делается за 5 минут, подойдёт для не частого сбора
> ПК> небольшого числа счётчиков.
>
> ПК> Второй вариант "страшный", пока первый раз не сделаешь. Подойдёт для
> ПК> частого сбора сотен показаний.
>
> Я бы уже задумался о том, что узкое место такой системы - не в сборе
> показаний...
>
> ПК> Дальше, если скармливать нужные счётчики и выводить их за один проход -
> ПК> можно обрабатывать теоретически неограниченное количество счётчиков за
> ПК> проход без дополнительных расходов.
>
> Это как раз автомагически получается с iptables -L. На C тебе для этого
> придется громоздить изрядную конструкцию (фактически, разрабатывать
> половину перла). Оно окупится? У меня есть сомнения...
Уже окупилось. На системе где так работает после таких оптимизаций прогу
передающую счётчики в snmpd в top'е не видно, а snmpd иногда до 10% CPU
тратит. Следующим шагом, там от snmp откажусь в пользу самописного
демона, проблема иссякнет.
> >> Но если этот человек может алгоритмизовать некоторый набор
> >> своих действий - он поручает его программе, и API для этого у него уже
> >> есть.
>
> ПК> Да, но это тоже, что и бегать в чугунных сапогах.
>
> Результаты профайлинга предъяви, да?
Есть конкретный пример? С профайлингом на <Ваш любимый скриптовый
язык>...
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: