Возможно я неправильно написал бенчмарк и он показывает неправильные результаты
require 'rubygems'
require 'benchmark'
class Test
def initialize(a, b)
@a = a
@b = b
end
def a
@a
end
def b
@b
end
end
Test1 = Struct.new(:a, :b)
cycles = 100_000_000
Benchmark.bm do |x|
x.report("Class") do
cycles.times do |t|
cl = Test.new(t, t+1)
result = cl.a + cl.b
end
end
x.report("Struct") do
cycles.times do |t|
st = Test1.new(t, t+1)
result = st.a + st.b
end
end
end
У меня вышло так:
user system total real
Class 26.309904 0.098226 26.408130 ( 26.427825)
Struct 25.518613 0.055952 25.574565 ( 25.576957)
Разница составила 3% по времени на таком размере операций, т.е. где-то 3.0e-10 секунды на операцию.
Вообще, согласно документации, Struct создает тоже класс
The Struct class generates new subclasses that hold a set of members and their values. For each member a reader and writer method is created similar to Module#attr_accessor.
Если требуется проанализировать M частотных составляющих в сигнале из N отсчётов, то при M < \log_2 N алгоритм Гёрцеля эффективнее, чем БПФ.
У меня проверяется 5 частот со сдвигом в +-5Hz, что дает нам для герцеля 54 частоты, если надо 10 добавить, то выйдет уже 88. M=88
При размере окна в 4096 (1 / 2 секунды) Log2(4096) = 12
Таким образом даже при +- 5 утверждение 54 < 12 неверно. Так что, согласно статье что вы привели, мы получаем что FFT будет быстрее. Я провел простой бенчмарк:
package main
import (
"testing"
"github.com/mjibson/go-dsp/fft"
"github.com/mjibson/go-dsp/window"
)
func BenchmarkFFT(b *testing.B) {
for n := 0; n < b.N; n++ {
w := make([]float64, 4096)
window.Apply(w, window.Hamming)
fft.FFTReal(w)
}
}
И получил следующие результаты:
goos: linux
goarch: amd64
pkg: github.com/userad/fas-detector
cpu: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz
BenchmarkFFT-8 3362 333615 ns/op
PASS
ok github.com/userad/fas-detector 1.163s
Думаю данной производительности хватит даже без оптимизации по различным потокам.
На моей тестовой выборке были случаи когда частота плавает на +-50Hz и Герцель показал себя гораздо хуже (порядка 10% ложноотрицательных результатов). Реализация в Asterisk основана на нем. В реализации DSP там проверяются тоны только для US, UK и Costa Rica (Конечно большая часть их будет по всему миру).
Я не проврял данный dialplan, но выглядеть должно примерно так.
В любом случае я взял Asterisk как систему на которой можно быстро экспериментировать, в нашем случае это один из фильтров включая определение AMD, FAS и некоторые другие характеристики звонка вроде щелчков, потери фреймов приводящие к искажению звука и другие проблемы.
Использование модулей к Asterisk или EAGI очень привязывает именно к нему и несет дополнительные издержки по деплою в случае модуля.
token.requests_count += 1 # добавляем 1 к счетчику в случае удачного извлечения токена
token.save() # сохраняем изменный экземпляр токена в БД
Я не особо хорош в django, но в нашем тесте про url shortener это было сигналом того, что человек не знает что бывают race conditions. Попробуйте сделать 1000 запросов с concurrency 5 с помощью siege и посмотреть результат. Что-то мне подсказывает, что это будет не 1000
А что делать если весь сервис упадет? На мой взгляд гораздо надежнее и без прыжков с патчами исходников взять kamailio и добавить надежность через keepalived или аналог. А за него уже убрать несколько asterisk с dialplan. Таким образом будет дублировано все. Если хочется еще - добавить несколько входов через kamailio и DNS-rr.
А использовать Asterisk realtime это путь получать много интересных и разных ошибок по любому поводу и креши.
Возможно там будет проверка по таблице откуда пришел звонок, так что если операторы не совпадают, то ничего в жизни не поменяется. Другое дело как будут жить банки и прочие крупные колцентры.
В качестве компенсации Belka Games предлагает разработчикам уволиться сразу с выплатой в размере двух заработных плат, либо отработать месяц и получить компенсацию в размере одной
Все очень хорошо пока не меняется база данных так что добавляется, допустим, поле NOT NULL и старая версия не перестает работать на вставку данных. К сожалению в таком случае надо будет делать 2 последовательных релиза первый из которых добавит поле, а второй добавит условие NOT NULL
Возможно я неправильно написал бенчмарк и он показывает неправильные результаты
У меня вышло так:
Разница составила 3% по времени на таком размере операций, т.е. где-то 3.0e-10 секунды на операцию.
Вообще, согласно документации, Struct создает тоже класс
В данном варианте можно вообще Array#sum использовать
Если вам не нравятся классы, то зачем вы используете язык который основан на концепции ООП?
У меня проверяется 5 частот со сдвигом в +-5Hz, что дает нам для герцеля 54 частоты, если надо 10 добавить, то выйдет уже 88. M=88
При размере окна в 4096 (1 / 2 секунды) Log2(4096) = 12
Таким образом даже при +- 5 утверждение 54 < 12 неверно. Так что, согласно статье что вы привели, мы получаем что FFT будет быстрее. Я провел простой бенчмарк:
И получил следующие результаты:
Думаю данной производительности хватит даже без оптимизации по различным потокам.
На моей тестовой выборке были случаи когда частота плавает на +-50Hz и Герцель показал себя гораздо хуже (порядка 10% ложноотрицательных результатов). Реализация в Asterisk основана на нем. В реализации DSP там проверяются тоны только для US, UK и Costa Rica (Конечно большая часть их будет по всему миру).
Возможно можно использовать его
Я не проврял данный dialplan, но выглядеть должно примерно так.
В любом случае я взял Asterisk как систему на которой можно быстро экспериментировать, в нашем случае это один из фильтров включая определение AMD, FAS и некоторые другие характеристики звонка вроде щелчков, потери фреймов приводящие к искажению звука и другие проблемы.
Использование модулей к Asterisk или EAGI очень привязывает именно к нему и несет дополнительные издержки по деплою в случае модуля.
А кто сказал что app server запустит только один поток?
Я не особо хорош в django, но в нашем тесте про url shortener это было сигналом того, что человек не знает что бывают race conditions. Попробуйте сделать 1000 запросов с concurrency 5 с помощью siege и посмотреть результат. Что-то мне подсказывает, что это будет не 1000
я имел ввиду сам Asterisk, у него нет восстановления после падений. Все регистрации потеряются например.
А что делать если весь сервис упадет? На мой взгляд гораздо надежнее и без прыжков с патчами исходников взять kamailio и добавить надежность через keepalived или аналог. А за него уже убрать несколько asterisk с dialplan. Таким образом будет дублировано все. Если хочется еще - добавить несколько входов через kamailio и DNS-rr.
А использовать Asterisk realtime это путь получать много интересных и разных ошибок по любому поводу и креши.
Как раз будет куча рандомных номеров, а не один ведущий обратно на общий колцентр.
Возможно там будет проверка по таблице откуда пришел звонок, так что если операторы не совпадают, то ничего в жизни не поменяется. Другое дело как будут жить банки и прочие крупные колцентры.
Какое заманчивое предложение
Обычно все как раз забывают про конфликт и все падает.
Все очень хорошо пока не меняется база данных так что добавляется, допустим, поле NOT NULL и старая версия не перестает работать на вставку данных. К сожалению в таком случае надо будет делать 2 последовательных релиза первый из которых добавит поле, а второй добавит условие NOT NULL
Ну мне нужен был именно OpenVPN
простой SOCKS5 будет срезаться так-же DPI
Да, телефония ломалась. Они SIP по моему просто срезают по заголовкам весь.
А скорость не замеряли?
После туннелирования трафика. До этого не работало вообще
Я пробовал. Для тестов запускал на телефоне ssltunnel и все проходило.
С телефона UDP, TCP:443 не работали