Re: Функционал и интерфейс
On Mon, 16.03.2009 16:02:07 , Покотиленко Костик wrote:
> В Пнд, 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 для этого у него уже
> > >> есть.
> >
> > ПК> Да, но это тоже, что и бегать в чугунных сапогах.
> >
> > Результаты профайлинга предъяви, да?
>
> Есть конкретный пример? С профайлингом на <Ваш любимый скриптовый
> язык>...
Вы бы ESR-а всё-таки почитали, а то Артёму тут уже приходится
некоторые места своими словами пересказывать и те же цитаты приводить,
которые там уже приведены.
--
С уважением,
Тихон Тарнавский.
http://linuxforum.ru
http://posix.ru
Reply to: