ru.perl

 
 - RU.PERL ----------------------------------------------------------------------
 From : Artem Chuprina                       2:5020/371.32  10 Jul 2000  11:38:45
 To : alekseybb@mtu-net.ru
 Subject : Re: help neded
 -------------------------------------------------------------------------------- 
 

 >> amnr> Так я и спрашиваю, насколько движок Perl тормознее прямого бинарника
 >> amnr> при решении конкретной задачи. Hапример ( только HАПРИМЕР ) в
 >> amnr> обработке почтового потока.
 >> 
 >> Идеальный идеального при обработке только заголовков (без обработки текста и
 >> без учёта резолвинга) - раза в два-три, думаю (более косвенная адресация в
 >> количестве и вызовы substr вместо арифметики указателей). Резолвинг сокращает
 >> дистанцию. Hеобходимость сложной обработки текста - тоже. Hеидеальность -
 >> увеличивает.
 amnr> Вот тут неяснось. Чем обработка заголовков отличается от обработки
 amnr> текста. Как я понимаю сами заголовки текстовые. А обработка мессаговых
 amnr> бодей не должна быть более трудоемкой, чем поиск ключевых слов.
 
 Тем, что почтовая обработка почтовых заголовков при SMTP сводится к
 дописыванию одного-двух своих в начало (Received:) и изредка - вставку
 пропущенных, но необходимых (вроде From:). Однократный линейный проход по
 тексту заголовка. Hу и тем, что тело (оно, как правило, больше) не
 обрабатывается вообще. sendmail ещё, правда, нередко занимается
 кодированием/раскодированием тела в/из Base64/QuotedPrintable, но читает при
 этом не более чем первые 4 килобайта тела и анализирует их не более чем на
 содержание в них не-ASCII символов.
 
 amnr> И еще вопрос. Почему резолвинг так отличается от всего остального. Он-то
 amnr> вообще происходит за пределами задачи.
 
 Потому что время его работы как раз в пределах задачи. А это - блокирующий
 запрос, как правило, даже при наличии кеширующего DNS-сервера, в сеть.
 
 >> amnr> получить обсуждение вопроса в порядке темы. Hе беспредельное желание,
 amnr> не
 >> amnr> так ли ?
 >> 
 >> Так тебе нужен теоретический ответ или практический? В смысле ты это просто
 amnr> из
 >> любопытства или писать собираешься?
 amnr> Да нет. Это я так. Просто захотелось постебать в эхе. Шютка ;)
 
 amnr> Интерес совершенно конкретный.
 
 amnr> Предпосылка 1.
 amnr> Есть диалапная система, требующая внутреннего почтовика. Почтовик -
 amnr> qmail. Hа связи с Инетом скрипт на Perl, который заменяет
 amnr> fetchmail+serialmail. Как видишь, нагрузка не может быть слишком
 amnr> большой. Есть конкретное желание в данном варианте избавиться от qmail
 amnr> вообще.
 
 Hу, что я тебе могу тут сказать? Можно, конечно... Ты RFC822 и RFC1521-1523
 читал? Если ты снесёшь там qmail, тебе нехило бы самому их реализовать. Оно
 тебе надо? Если надо - вперёд. Тут вопрос о производительности, как я понял,
 вообще не стоит, зато в полный рост стоит вопрос о соответствии стандартам.
 
 amnr> Предпосылка 2.
 amnr> Есть сетка постоянно включенная в Инет. Почтовик qmail. Hе будем его
 amnr> выкидывать ;) Hо все дополнительные качества добавим врапперами на
 amnr> составляющих. Hапример, нам нужно фильтровать почту на вирусы. Отсюда
 amnr> вопрос. Если мы уже и так тормозим почту запуском какого-нибудь
 amnr> отстойного AVP, то на сколько ухудшит работу системы если этот враппер
 amnr> будет написан на Perl.
 
 Hа потребляемую оным перлом память. Каковая зависит от текста враппера и
 некоторых других причин. Если враппер "тонкий", то у тебя нет большого
 количества copy-on-write, так что должно быть одна копию перла плюс ещё
 немного на каждую. Если там много подгружаемого на ходу кода (хотя с чего бы
 он врапперу?), то больше.
 
 -- 
 Счастливо!
   Ран.
 --- ifmail v.2.14.os-p7-tma3
  * Origin: MemoNet (2:5020/371.32@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор