мысль в том, что если вы достаточно медленно опрашиваете сайты, то и производительности любого скриптового языка должно вполне хватать. так что и данная библиотека не слишком плоха. да и вообще, можно выбирать парсер с точки зрения удобства прежде всего.
что-то вы напутали. свежий файл GeoIPASNum.dat по ссылке //geolite.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz размером 3658209 байт.
базы я подкладывал в "/usr/share/GeoIP/"
Ну, есть еще шанс, что они сначала считают трафик, а потом фильтруют часть как паразитный. С netflow, например такое может получиться. Но этот шанс маленький.
Ищите лучше у себя.
>Invalid database type GeoIP Country Edition, expected GeoIP Organization Edition
Это ведь значит, что вы не смогли подменить файл. Файл asnum сделан в формате GeoIP Organization.
У всех свои требования. Поэтому я и привел в пример программы обработки логов. Там требования очень высокие. и awstats прекрасно справляется без mysql.
если возможно, в глобальные файлы CMS вставляйте вызов register_shutdown_function где будет записываться объем до и после. При превышении пишите в error_log() или вот такой вариант используйте drupal.org/node/332276
Хотелось бы иметь какой-нибудь модуль, но я не нашел.
то есть, если ты изначально хотел.надежность+скорость — тебе нужен виртуальный хостинг с односторонней репликацией файлов через drbd и односторонней репликацией mysql.
Это добра навалом на рынке виртуального хостинга. Даже поэффективнее чем REMUS будет.
Такие конфигурации описаны в литературе и особых проблем при построении не составляют.
>а потому, что хочется распределённости для надёжности и скорости.
как это часто бывает — «выбери любые два».
1.распределенность + надежность — нет скорости. уже описал.
2.надежность + скорость — значит нужно держать сервера рядом и соединять прямым проводом.
3.распределенность + скорость — нет надежности: неизвестно как поведет себя произвольный не подготовленный движок, спроектированный для работы на одном сервере.
Тогда я все уже изложил в первом сообщении.
Чтобы оказывать приснившуюся тебе коммерческую услугу, нужно быть уверенным, что любой произвольный запрос на обновление данных (я не только об sql говорю) приведет к согласованному изменению на хранилище в целом. Любой удаленный компонент должен получить те же обновления еще до того как локальный sql-сервер вернет ответ скрипту. На передачу данных между разнесенными узлами требуется время.
Значит, в общем случае, на облаке будет работать медленнее чем на единичном сервере.
Ну и зачем все это нужно клиенту? Кто туда пойдет?
Насколько я могу заметить, общее мнение для частных проектов — просто покупать хороший хостинг в хорошем датацентре. Сутки простоя в год многие легко терпят.
В принципе, я еще могу себе представить, одностороннюю репликацию данных на запасной сервер-дублер, который просто ждет своего часа. Репликация работает асинхронно и никуда не спешит. В такой схеме клиент должен быть предупрежден что может потерять часть данных. И это даже неглупый технарь вполне может построить из подручных материалов.
Но будет ли это пользоваться коммерческим успехом?
Что значит прослойка в вашем видении? Супердистрибутив Джоомла Клустер Эдишн? Вордпресс Дистрибутед?
Чтобы вы поставили на них свои расширения, как прочитали в книжке «Джумла за 21 день» и все развалилось?
Я не имею ввиду лично вас и конкретно джумлу, но вы должны понять, что при коммерческой эксплуатации люди захотят это все сделать. Иначе они бы прекрасно обошлись бы распределенным и устойчивым narod.ru.
Раз какую-то услугу найти нелегко, значит есть объективные сложности с ней или с её окупаемостью.