Перейти до

Билинг для 300-500 абонентов.


Рекомендованные сообщения

  • Відповіді 248
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Не поленитесь и сделайте нормально. Не нужно никакких pppoe. Только гемороя себе добавите и тех. поддержке. Стройте простой ipoe на unnumbered, влан на дом или на пользователя.

Извините, не удержался. Если сравнивать Абилс с машинами, то это Ваз2101 на 500 тысяче пробега, с непонятными внутренностями после пердоделок, а  главный специалист сервиса - любитель фильмов ужаса.

Нет ни одного универсального биллинга. Каждый биллинг рассчитан на своего клиента. Самый простой показатель - к-во абонентов. Какие-то биллинги уверенно нацелены на сегмент в 0-5000 абонентов, другие

Posted Images

Ну я ж и грю - как минимум переписывать mysqlclient библиотеку...

Существует асинхронный клиент. И есть обертки - например, twisted предлагает выносить mysql в отдельный поток (собственно, и выносит), где будет всё говно, а в основном потоке будет асинхронный код, который будет работать с асинхронным интерфейсом (оберткой) MySQL. Хрень, конечно, но всё равно получается на порядок шустрее, чем синхронный код.
Ссылка на сообщение
Поделиться на других сайтах

 

Мы пытались но список дистрибутивов не вели так как ситуация когда не стратует или после обновление все просто падает, а клиенты в большинстве случаев не разбераются в проблеме, а сразу наезд идёт что все плохо биллинг не работает и все и клиент звонит 10 раз в "час что всепропало" потом оказывается он просто переустановил биллинг или обновил его и не посмотрел как все собрано.

Так а что неправильно с точки зрения клиентов? Они заплатили деньги за то, что вы поставите им НОРМАЛЬНО сервак с биллингом. ВЫ им собрали с исходников, а далее они админят дистр по МАНУАЛУ от создателей дистра и попадают на проблемы с вашими собранными радиусами.

Так в чем они виноваты?

Повторюсь, вам нужно всего лишь выкатать инсталяху на 2 основных дистра и усё!

видите даже Вы не разобрались в ситуации а обвиняете, а если бы все таки собрали свой радиус с портов Вы бы опять потом обновили на стандарный и было бы обвинение что после обновления не работает. Хотя если честно не могу онять что у Вас с обновлением не работает, все должно чётко обновиться без проблем

при попытке обновить дистр - неразрешенные зависимости. и пробовать трогать это - страшно! (так же как и обновлять биллинг).

 

 

исходя из Вашей логики все прекомпилированные биллинговые системы зло потому что нельзя обновить систему

Ссылка на сообщение
Поделиться на других сайтах

 

А с чего вы взяли, что логика в СУБД?

Из этой темы и показанных костылей :)

Если нет логики в СУБД, то при нормальной работе в СУБД должны только сохраняться конфиг/пулы/изменения_в_пулах раз в сколько-то секунд и все.

 

Покажите статус процесса радиус сервера, на select/epoll/kqueue висит? Если да, то он асинхронный.

 

Ну и да, в той же гидре логика в СУБД вся. Из-за чего она и применяется при больших нагрузках...

Если у вас не упирается в СУБД, то это далеко не большие нагрузки :) Но речь сейчас не об этом, а о том, что неадекватно реализовано, из-за чего локи, пиление и прочие проблемы даже на микронагрузках.

 

 

мне одному кажется что это полная чушь не одно из Ваших высказываний не выдерживает и малешей критики.

Все уже давно услышали что Вы "круто разбираетесь" в программировании

но так никто и не  увидел ни одного Вашего проекта и даже элементарную функцию   написать не можете зато куча пафосных речей которые вообще не  имеют никакого отношения к реальному программированию

Ссылка на сообщение
Поделиться на других сайтах

 

Ну и да, 2к онлайна без особого напряга тянет тазик 5-летней давности с 2-головым атлоном..

На 2к согласен, даже может на 3к, только последствия после лавинообразных авторизаций будут!

 

 

проверил у себя 25 независимых потоков в каждом по 100 000 запросов не одного дедлока, думаю проблема где то у Вас просьба выслать мне Auth.pm так будет легче найти ошибку

Ссылка на сообщение
Поделиться на других сайтах

Ну я ж и грю - как минимум переписывать mysqlclient библиотеку...

http://search.cpan.org/search?query=AnyEvent+mysql&mode=all

https://www.npmjs.org/search?q=mysql

http://twistedmatrix.com/documents/current/core/howto/rdbms.html

https://code.google.com/p/go-wiki/wiki/SQLDrivers

 

Все давно переписано.

 

Вообще разговор ни о чем уже. Вы с чего-то вдруг решили, что планировщик на sql костылях - это нормально. Пилите, имеете проблемы, но продолжаете жрать кактус. Ваше дело. Но это говнокод и ламерство.

 

и даже элементарную функцию написать не можете

Асмодеус, вы такой программист, как я балерина, молчали бы уже :) Відредаговано ttttt
Ссылка на сообщение
Поделиться на других сайтах

 

Ну я ж и грю - как минимум переписывать mysqlclient библиотеку...

http://search.cpan.org/search?query=AnyEvent+mysql&mode=all

https://www.npmjs.org/search?q=mysql

http://twistedmatrix.com/documents/current/core/howto/rdbms.html

https://code.google.com/p/go-wiki/wiki/SQLDrivers

 

Все давно переписано.

 

Вообще разговор ни о чем уже. Вы с чего-то вдруг решили, что планировщик на sql костылях - это нормально. Пилите, имеете проблемы, но продолжаете жрать кактус. Ваше дело. Но это говнокод и ламерство.

 

и даже элементарную функцию написать не можете

Асмодеус, вы такой программист, как я балерина, молчали бы уже :)

 

Да уже заметили что программирование вы учили в балетной школе. Предполагаю что Вы где то хотели срубить бабок фокрнув абилс но Вас на этом сразу словили и денег не дали, вот Вы и беситесь.

Ссылка на сообщение
Поделиться на других сайтах

 

 

Вы с чего-то вдруг решили, что планировщик на sql костылях - это нормально.

Сохранение статуса при каждом изменении объекта - да, это нормально. Для критичных данных. И получение статуса из базы каждый раз - это тоже нормально для критичных данных. Особенно - если планируется когда-нибудь строить отказоустойчивый кластер, или балансировать нагрузку.

 

А делать заведомо немасштабируемую систему, которая допускает возможность утери важных данных при краше - это ненормально.

 

проверил у себя 25 независимых потоков в каждом по 100 000 запросов не одного дедлока

Дедлок  таки проскакивает в аккаунтинге, если радиус собран с поддержкой потоков (как в дебиане). Но откуда он вылазить может - я не представляю, негде ему там взяться вроде бы...

2014-10-23 16:12:44 LOG_ERR:  []
UPDATE dv_calls SET
         status='1',
         started=FROM_UNIXTIME(UNIX_TIMESTAMP()),
         lupdated=UNIX_TIMESTAMP(),
         nas_port_id='98903',
         acct_session_id='81c04921',
         CID='E8:94:F6:xx:xx:xx',
         CONNECT_INFO=''
         WHERE user_name='xxxx' AND nas_id='2' AND acct_session_id='IP' AND (framed_ip_address=INET_ATON('10.140.0.22') OR framed_ip_address=0)
         ORDER BY started
         LIMIT 1;
 --1213
 --AutoCommit: 1
--Deadlock found when trying to get lock; try restarting transaction at /usr/abills/libexec/../Abills/mysql/main.pm line 126
    main::query2('Acct=HASH(0x8e4c450)', 'UPDATE dv_calls SET\x{a}         status=\'1\',\x{a}         started=F...', 'do') called at /usr/abills/libexec/../Abills/mysql/Acct.pm line 121
    Acct::accounting('Acct=HASH(0x8e4c450)', 'HASH(0x6031348)', 'Nas=HASH(0x7ffdbc0af9f0)') called at /usr/abills/libexec/racct.pl line 372
    main::acct('DBI::db=HASH(0x64aa468)', 'HASH(0x6031348)', 'Nas=HASH(0x7ffdbc0af9f0)') called at /usr/abills/libexec/rlm_perl.pl line 132
    main::accounting called at /usr/abills/libexec/rlm_perl.pl line 0
    eval {...} called at /usr/abills/libexec/rlm_perl.pl line 0
Відредаговано NiTr0
Ссылка на сообщение
Поделиться на других сайтах

Сохранение статуса при каждом изменении объекта - да, это нормально. Для критичных данных. И получение статуса из базы каждый раз - это тоже нормально для критичных данных. Особенно - если планируется когда-нибудь строить отказоустойчивый кластер, или балансировать нагрузку.

Это все бурное воображение и в общем-то бред. Вы сильно переоцениваете возможности, надежность мускуля и критичность ваших данных. RPC сервис тут был бы гораздо лучшим решением, чем костыли на SQL.
Ссылка на сообщение
Поделиться на других сайтах

Ну мускул всяко надежнее для хранения, чем таблица в памяти, умирающая вместе с процессом. А критичность статуса ип адресов (свободен/занят) - вроде как и невысокая, но и не нулевая. Потому как если двум клиентам выдается один и тот же ип - начинаются проблемы у клиентов, и много возмущений.

Ссылка на сообщение
Поделиться на других сайтах

 

 

проверил у себя 25 независимых потоков в каждом по 100 000 запросов не одного дедлока, думаю проблема где то у Вас просьба выслать мне Auth.pm так будет легче найти ошибку

Auth.pm из вашего cvs.

 

 

Дедлок  таки проскакивает в аккаунтинге, если радиус собран с поддержкой потоков (как в дебиане)

То есть проблеме имеет место быть. Диадлок будет появляться и это очевидно, или я что то не так понимаю.

Ссылка на сообщение
Поделиться на других сайтах

 

 

Предполагаю что Вы где то хотели срубить бабок фокрнув абилс но Вас на этом сразу словили и денег не дали, вот Вы и беситесь.

Что бы это реализовать, надо как минимум альтернативный opensource продукт с поддержкой и много времени. И самый главный нюанс, что бы разработчик не дорабатывал продукт, который хотят форкнуть. Так что Abills это не грозит. Надеемся только на улучшения продукта, безопасные обновления, высокую производительность.

Ссылка на сообщение
Поделиться на других сайтах

исходя из Вашей логики все прекомпилированные биллинговые системы зло потому что нельзя обновить систему

так ведь все пакеты в пакетных дистрах это скомпиленные проги. только вот они в пакетах, красиво завернутые и легко обновляемые.

а у вас не так. но сам биллинг - это не беда. но вот тот же радиус из исходников - уже проблема.

 

и еще: ваша привычка обновлять биллинг днем, в процессе работы тысяч клиентов, тоже напрягает. неужели нельзя было обновлять ночью его?

ответ от вас удивил: так вы не заказывали. так это не было нигде не написано, а очевидность обновления не в рабочее время оказывается для вас не очевидна. очевидно, что вам все равно, что юзеры уменьшат карму прову.

Відредаговано sadmin
Ссылка на сообщение
Поделиться на других сайтах

 

исходя из Вашей логики все прекомпилированные биллинговые системы зло потому что нельзя обновить систему

так ведь все пакеты в пакетных дистрах это скомпиленные проги. только вот они в пакетах, красиво завернутые и легко обновляемые.

а у вас не так. но сам биллинг - это не беда. но вот тот же радиус из исходников - уже проблема.

 

и еще: ваша привычка обновлять биллинг днем, в процессе работы тысяч клиентов, тоже напрягает. неужели нельзя было обновлять ночью его?

ответ от вас удивил: так вы не заказывали. так это не было нигде не написано, а очевидность обновления не в рабочее время оказывается для вас не очевидна. очевидно, что вам все равно, что юзеры уменьшат карму прову.

 

 

обновление радиуса 3 команды,

если бы дистрибутив был скомпилирован то Вы тоже бы говорили что опять что то не так опять не те зависимости или скомпилированы радиус дистрибутива не так обновляется

 

мы работаем в любое время только Вы ж не хотите платить за круглосуточную поддержку или за работы в нерабочее время, так что притенении нужно к себе предъявлять

Ссылка на сообщение
Поделиться на других сайтах

 

проверил у себя 25 независимых потоков в каждом по 100 000 запросов не одного дедлока, думаю проблема где то у Вас просьба выслать мне Auth.pm так будет легче найти ошибку

Auth.pm из вашего cvs.

 

только за этот год более 10 раз был изменён так что нужно конкретную дату

 

 

 

 

проверил у себя 25 независимых потоков в каждом по 100 000 запросов не одного дедлока, думаю проблема где то у Вас просьба выслать мне Auth.pm так будет легче найти ошибку

Auth.pm из вашего cvs.

 

 

Дедлок  таки проскакивает в аккаунтинге, если радиус собран с поддержкой потоков (как в дебиане)

То есть проблеме имеет место быть. Диадлок будет появляться и это очевидно, или я что то не так понимаю.

 

 

да подтвердилось на старом опенсорсном дистрибутиве буду тестировать и отпишись по ситуации

Ссылка на сообщение
Поделиться на других сайтах

обновление радиуса 3 команды, если бы дистрибутив был скомпилирован то Вы тоже бы говорили что опять что то не так опять не те зависимости или скомпилированы радиус дистрибутива не так обновляется мы работаем в любое время только Вы ж не хотите платить за круглосуточную поддержку или за работы в нерабочее время, так что притенении нужно к себе предъявлять

ну то есть вы считаете, что проблем с вашей тех поддержкой и тех особенностями вести проект нет?
Ссылка на сообщение
Поделиться на других сайтах

 

обновление радиуса 3 команды, если бы дистрибутив был скомпилирован то Вы тоже бы говорили что опять что то не так опять не те зависимости или скомпилированы радиус дистрибутива не так обновляется мы работаем в любое время только Вы ж не хотите платить за круглосуточную поддержку или за работы в нерабочее время, так что притенении нужно к себе предъявлять

ну то есть вы считаете, что проблем с вашей тех поддержкой и тех особенностями вести проект нет?

 

 

тех поддержка полностью регламентирована, и учтены все возможные пожелания

Ссылка на сообщение
Поделиться на других сайтах

 

 

Диадлок будет появляться и это очевидно, или я что то не так понимаю.

 

Дедлок не должен появляться. Ибо лок вызывается только в auth.pm, в одном месте кода, и сразу на всю таблицу сессий. А дедлок вылезает в acct.pm - где нет ни локов, ни транзакций, ибо нет сложных операций.

Ссылка на сообщение
Поделиться на других сайтах

 

Диадлок будет появляться и это очевидно, или я что то не так понимаю.

 

Дедлок не должен появляться. Ибо лок вызывается только в auth.pm, в одном месте кода, и сразу на всю таблицу сессий. А дедлок вылезает в acct.pm - где нет ни локов, ни транзакций, ибо нет сложных операций.

 

 

 

проблема оказалась на много тривиальней и связана было с innodb  уже поправлено

Ссылка на сообщение
Поделиться на других сайтах

проблема оказалась на много тривиальней и связана было с innodb уже поправлено

Вы забыли добавить "Обновите биллинг!".))))

и получить еще с десяток багов. и так до просветления.

Відредаговано sadmin
Ссылка на сообщение
Поделиться на других сайтах

 

проблема оказалась на много тривиальней и связана было с innodb уже поправлено

Вы забыли добавить "Обновите биллинг!".))))

 

 

можно просто проверить что изменилось если не хотите обновлять или патч загрузить с git

 

или просто помедитировать может само пофиксится

Відредаговано ~AsmodeuS~
Ссылка на сообщение
Поделиться на других сайтах

 

Предполагаю что Вы где то хотели срубить бабок фокрнув абилс но Вас на этом сразу словили и денег не дали, вот Вы и беситесь.

Что бы это реализовать, надо как минимум альтернативный opensource продукт с поддержкой и много времени. И самый главный нюанс, что бы разработчик не дорабатывал продукт, который хотят форкнуть. Так что Abills это не грозит. Надеемся только на улучшения продукта, безопасные обновления, высокую производительность.

 

ну как удалось еще что то найти ?

Відредаговано ~AsmodeuS~
Ссылка на сообщение
Поделиться на других сайтах

 

 

проблема оказалась на много тривиальней и связана было с innodb  уже поправлено

Это хорошо.

 

 

ну как удалось еще что то найти ?

У меня пока не совсем достаточно времени, для детальных тестов. По мере нахождения, я буду отписываться. Скорее всего ближе к концу ноября.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від Firelli
      Снова решил начать заниматься сетями. (в прошлом году сеть продал, и сижу скучаю)
      Билинг был Nodeny+, но как-то маловато, или перерос его. Еще раз его покупать не хочется. (хотя и отработал своих 1000+ клиентов без замечаний)
       
      В идеале утроил бы с  с трекингом для машины/машин и встроенным складом.
      Может подскажете варианты. Те что были в работе и стабильные.
       
    • Від pavlabor
      Продолжение темы
      В основу проекта "Firstprov" положен билинг.
      В данной теме предлагаю обсудить технические требования к билингу.
      1. В перспективе сертификация.
      2. Масштабируемость.
      3. Уровневая система доступа.
      Предусматривает три уровня
      - Дирекция (администрация),
      - оператор (реселлер), реселлер должен иметь два уровня доступа, доступ для постоянных и для временных участников.
      - пользователь.
      Дирекция(администрация) имеет самый высокий статус и имеет доступ ко всем объектам для внесения, редактирования, удаления информации.
      Оператор (реселлер) имеет возможность просматривать всю информацию но доступ к объектам для несения, редактирования, удаления информации имеет исключительно в своем разделе.
      Пользователь имеет стандартный доступ к своему кабинету.
      4. Перевод абона от реселлера к реселлеру.
      5. Билинг должен интегрироваться с платежными системами.
      6. Иметь возможность работать с картами, схемами сетей, показывать активность абонов.
      7. Возможность бекапирования, распределения нагрузки, синхронизация данных.
      8. Возможность доработок, создания дополнительных модулей.
       
      Цена и условия приобретения.
      На первом этапе требуется билинг для тестирования для дирекции и нескольких участников.
      Допустим если проект начнется с пяти реселлеров по 100 клиентов, а потом разростется до двадцати реселлеров и 50 тыс клиентов то хотелось бы увидеть ценник на динамику развития.
      Лично мое пожелание это стартовый взнос и абонка 25 копеек с абона (на 1000 абонов, это 250 грн. в месяц).
       
      Вносите свои предложения по тех условиям, но текущие билинги в стандартном состоянии предлагают довольно широкий ассортимент сервисов.
      К выбору билинга, формированию ТУ прошу подойти ответственно, так как выбранный билинг станет ВАШИМ основным инструментом ведения бизнеса, по финансам не стоит забывать золотое правило - "Любой каприз за ВАШИ деньги".
      Также нужно понимать что данное решение подразумевает "белое ведение бизнеса".
       
      Писателей билинга прошу озвучивать свои предложения. По крайней мере если мы даже не выберем Ваше предложение у Вас появилась возможность достойно презентовать свой товар.
       
      Поехали.
      =============================8<---------------------
       
      Сформировавшиеся предложения
       
    • Від 000000002010s
      Помогите настроить сервер для биллинга (ubiling) с нуля. Ето надо сделать удалено через нет.
      Задачак такова:
      1.Стадартная схема отключения клиета при отрицательном балансе.
      2. Страница о пополнение счета, через приват 24 на карточку.
      Регистрация клиентов по методу ip+mac.
      Есть сервер hp proliant G5.
      Все кто шарит в етом пишите мне.
      Разумеєтса ето не за даром.
      Пишите в личку.
    • Від Martin Odym
      Доброго времени суток уважаемые форумчане. Кратко о сути- даю интернет в частном секторе. построение сети- приход канала на медик-сетевая в серваке (старенький гробик 1 гб озу ддр1, проц на два ядра 1.6) сетевая на выход в 16 порт свитч (тупой)- медики на магистрали (оптику подводим к группе людей дальше от свитча витухой к абонам). Роль билинга выполняет Ubilling. На данный момент число абонентов + - 65 чел. (квартиранты и "периодические плательщики" колыхают  статистику). В последний месяц проц начал проседать (загрузка по cacti по вечерам до 80-90% на процессоре). Вопрос: посоветуйте на какую железку перейти, оставлять юбилинг или же присмотреть другой? 
       
      з.ы Бюджет сети как сами понимаете не резиновый хотелось бы подобрать что то не дорогое и функциональное с примерным запасом на человек 300-400. Сеть собирали сугубо по вторичному рынку так что б.у товары будут предпочтительней. В ответах прошу (по возможности) оставлять ссылки (ссылки на локал вообще чудесно). Большая просьба отвечать тем кто действительно может помочь!!!! Спасибо за внимание.
    • Від 49rpam
      Здравствуйте. Читал чтo мoжнo устанoвить билинг на рoутере нo никгда с этим не сталкивался нужнo пoдключить через негo 30-50 челoвек Ктo м0жет мне в эт0м п0м0чь ну или х0тябы п0дсказать (не бесплан0)

×
×
  • Створити нове...