Re: Функционал и интерфейс
Покотиленко Костик -> debian-russian@lists.debian.org @ Mon, 16 Mar 2009 16:02:07 +0200:
>> Это как раз автомагически получается с iptables -L. На C тебе для этого
>> придется громоздить изрядную конструкцию (фактически, разрабатывать
>> половину перла). Оно окупится? У меня есть сомнения...
ПК> Уже окупилось. На системе где так работает после таких оптимизаций
ПК> прогу передающую счётчики в snmpd в top'е не видно,
А до того было видно? Ну, может, и имело смысл.
ПК> а snmpd иногда до 10% CPU тратит. Следующим шагом, там от snmp
ПК> откажусь в пользу самописного демона, проблема иссякнет.
А там сервер-то достаточно нагруженный? За snmpd ничего не скажу, кроме
того, что вот он как раз ни разу не скриптовый :-)
Впрочем, если у меня _одна_ программа ест 10% CPU на нагруженном сервере
- я оптимизирую не ее :-) Потому что даже заоптимизировав ее до нуля,
я больше 10% выигрыша не получу.
>> >> Но если этот человек может алгоритмизовать некоторый набор
>> >> своих действий - он поручает его программе, и API для этого у него уже
>> >> есть.
>>
>> ПК> Да, но это тоже, что и бегать в чугунных сапогах.
>>
>> Результаты профайлинга предъяви, да?
ПК> Есть конкретный пример? С профайлингом на <Ваш любимый скриптовый
ПК> язык>...
Ты так и не понял... Профайлить надо не мой любимый скриптовый язык, а
меня, любимого. Если я, юниксовый юзер, автоматизирую _свою_ задачу -
меня интересует экономия _моего_ времени. А не машинного.
Производительности моего наладонника мне почему-то вполне хватает. Меня
раздражает моя производительность при взаимодействии с его входным
интерфейсом (экранной клавиатурой). Но аккордных клавиатур делать не
хотят (заглох этот тренд), а телепатический ввод - не умеют...
И даже когда я разрабатываю нагруженный сайт (а ты не поверишь, я такое
делал - и именно на перле, и по нагрузке он входил в десятку в рунете, и
тянул эту нагрузку), я экономлю не машинное время, а человеческое.
Правда, уже не свое, а пользователя. И, кстати, заказчика - потому что
сайт, тянущий нагрузку с трудом, но сегодня, как правило лучше, чем тот,
который тянет без труда, но через два года. Второй сервер и
балансировка нагрузки обходятся дешевле, чем два года отставания.
С компиляторами и работой с бинарными протоколами - то же, но в меньших
масштабах.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Курицца - не пицца. (Итальянская пословицца)
Reply to: