В Пнд, 16/03/2009 в 14:40 +0300, Artem Chuprina пишет: > Покотиленко Костик -> debian-russian@lists.debian.org @ Mon, 16 Mar 2009 > 12:06:13 +0200: > > ПК> $ progA | ssh u...@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 для этого у него уже > >> есть. > > ПК> Да, но это тоже, что и бегать в чугунных сапогах. > > Результаты профайлинга предъяви, да? Есть конкретный пример? С профайлингом на <Ваш любимый скриптовый язык>... -- Покотиленко Костик <cas...@meteor.dp.ua> -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org