ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] RE: =?koi8-r?Q?=5Bapache?==?koi8-r?Q?-talk=5D_RE=3A_=5Bapache-talk=5D_RE=3A_=5Bapache-talk=5D_RE=3A?==?koi8-r?B?IFthcGFjaGUtdGFsa10g7M/HySDB0MHewQ==?=



On Fri, Nov 15, 2002 at 03:52:16PM -0000, Daniel Podolsky wrote:

> >писание логов на NFS-fs и прочие гарантированные способы передачи. 
> Как минимум, на один меньше - порчи записей происходить не будет. И есть у
> меня уверенность, что mysql быстрее отрабатывает...

Быстрее - это вряд-ли.  Там кроме записи данных возникает еще куча
побочной работы, например transaction management, а это очень медленно
(в сравнении с записью в файл)

> >Если передача в какой-то момент невозможна, то apache блокируется и 
> >перестает заниматься основной деятельностью.
> Я себе это так представлял: пока коннект есть - отсылаем в базу. Как пропал
> - пишем в локалный файл и информируем администратора. Как появился - снова в
> базу, и снова - мессагу администратору. Пусь заливает то, что в локальном
> файле осело.

Ну вот, еще один любитель усложнять конструкцию.
Коннект есть. Мы в него что-то положили, но вместо подтверждения о завершении
транзакции получили обрыв коннекта (а скорее - блокировку на бесконечное время).
Вопрос - наше данное записалось или нет ?
С транзакциями - не записалось (но про них см. выше), без транзакций - 
неизвестно, но зато быстро. Потом - чтобы избежать блокирования, мы должны
добавить в систему таймауты (и всякую их обработку). Если таймаут будет
маленьким - администратор будет весь в мессагах. Если большим - то
у нас будут те самые блокировки, которые в апаче совершенно неприемлемы.

Я решал подобную задачу с транспортировкой логов по сети в реальном времени
в рамках Top100. Клиентская часть _естественно_ была на принимающей стороне,
а то что писало логи - _естественно_ писало их в файловую систему (диски
я считаю надежнее сети). Весь варез (клиент и сервер) - 600 строк на языке С,
но даже в такой несложной системе глючки всплывали еще несколько раз
в течение года. То что предлагается - когда клиентом является пишущая сторона -
многократно сложнее.

Алексей Тутубалин
mailto: lexa@lexa.ru
Web: http://www.lexa.ru/lexa 





=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.