Вот кстати предварительные результаты: Оба написаны на C, но в случае с rejik используется не встроенная в glibc библиотека для работы с регулярными выражениями, а pcre (www.pcre.org). Squidguard для работы с url использует libdb3. Но даже не принимая во внимание работу с regex видно, что rejik опережает. Вот и хочу добавить в этот же тест еще и oops (точнее модуль редиректора).
wc -l http.log: 661'625 (содержит только баннеры, счетчики, js, ~85Mb) wc -l month.log: 4'557'435 (запросы за месяц в перемешку с нормальными, ~285Mb) 1. Проверка (по средним результатам из 3-х запусков) в случае использования только urls для редиректов: rejik (http.log): 0m5.8s squidguard (http.log): 0m17.2s, почти в 3 раза медленнее rejik (month.log): 0m34s squidguard (month.log): 1m50s, ~3.2 2. Проверка в случае использования только regex для редиректоров: rejik (http.log): 0m35s squidguard (http.log): 1m30s, ~2.6 rejik (month.log): 3m7s squidguard (month.log): 9m55s, ~3.2 3. Проверка в случае совместного использования (пункт 1+2): rejik (http.log): 0m15s squidguard (http.log): 1m23s, ~5(!) rejik (month.log): 3m1s squidguard (month.log): 11m30s, ~3.8 ----- Original Message ----- From: "Sergei Golod" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, October 25, 2003 12:06 PM Subject: [OOPS] RE: [OOPS] Re: [OOPS] пробшый шар на тему 1.5.23 > И squidguard и rejik написаны на C. Поэтому и придется сравнивать, здесь > нет вариантов на perl - они сразу отбросились. По сравнению строк и > регэкспов - да, согласен если используется библиотечная функция всеми > продуктами. Для сравнения же url - не факт, кто-то будет использовать > двоичный поиск, кто-то еще что-нибудь другое. И ведь никто не мешает > редиректору хранить счетчик использования элементов массива, чтобы > перестраивать порядок просмотра тех же самых регулярных выражений - т.е. > в зависимости от встречаемости и уже только это даст значительный > выигрыш. > А сравнивать через полиграф будет не совсем корректно - это будет > сравнение в целом проксей, а не редиректоров. Значит пока придется > сравнить squidguard и rejik. Игорь, может хотя бы просто выделите модуль > редиректора в отдельную программу - ведь в случае успешных испытаний это > будет еще один жирным плюсом в пользую упса :). > > С уважением, Сергей. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Igor Khasilev > Sent: Friday, October 24, 2003 8:34 PM > To: [EMAIL PROTECTED] > Subject: [OOPS] Re: [OOPS] пробшый шар на тему 1.5.23 > > On Fri, 24 Oct 2003, Sergei Golod wrote: > > > У меня тут другой вопрос/предложение созрел. На одном из серверов я > > хочу попробовать использовать oops в качестве баннерорезки. И с этой > > Всё можно сделать, лишь-бы был смысл :) Вряд-ли скорость модуля будет > хуже чем скорость другого редиректора, написанного на C. По сравнению с > perl производительность будет(должна быть) лучше в разы. Основные > затраты времени > - сравнение строк или проверки регексов, но тут от самого oops-а ничего > не зависит. Единтственное что может как-то влиять - стратегия прохода по > списку редиректов, но, к сожалению, кроме линейного просмотра вряд-ли > можно что-либо придумать - порядок просмотра должен совпадать с порядком > строк в конфиге. Очень важно: бывают такие регулярные выражения, которые > могут просто уложить работу прокси, поскольку сьедают процессор начисто. > > проверить можно иначе: ставится polygraph (такой бенчмаркинг для > проксей), прописывается реальный конфиг редиректора и потом мучаете > сквида и oops-a. > > > > > > ===================================================================== > If you would like to unsubscribe from this list send message to > [EMAIL PROTECTED] with "unsubscribe oops" in message body. > Archive is accessible on http://lists.paco.net/oops-rus/ > ===================================================================== If you would like to unsubscribe from this list send message to [EMAIL PROTECTED] with "unsubscribe oops" in message body. Archive is accessible on http://lists.paco.net/oops-rus/
