Лет 5 назад держал ВПС-ку у одного крупного хостинга. При очередном пополнении баланса был из процессинга перенаправлен на страничку super-hosting.xx/index.php?id_client=12345&add_balans=500, через пару минут мой баланс на хостинге превышал годовой бюджет РФ. Написал 3 безответных письма. Отчаявшись позвонил, поинтересовался можно ли вернуть ошибочно совершённый платёж… Не «вернули», не поблагодарили, ещё и судом угрожали.
Заказал партию оборудования. Чётко обговорили, что доставка будет послезавтра, поэтому указал домашний адрес. Привезли назавтра, когда я был на работе и везти по рабочему адресу отказались т.к. «у меня в путевом листе уже указан этот адрес и переписывать я не буду» Поэтому муводила ждёт меня возле дома пока я приеду и заберу доставленный товар.
Частично Вы сами ответили на свой вопрос — можно держать счётчики.
Ну или, например, сделайте выборку из файла всех запросов сделанных с ip 1.2.3.4 к локейшину /test/ за последние 20 сек
А если хранить логи просто «чтобы было», то в redis, конечно, необходимости нет.
ab запустил с 9 PC непрерывно и с локального снимаю статистику
redis
# ab -n 100000 -c 16 -v 0 127.0.0.1:80/
Time taken for tests: 20.768 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 84400000 bytes
HTML transferred: 61200000 bytes
Requests per second: 4815.09 [#/sec] (mean)
Time per request: 3.323 [ms] (mean)
Time per request: 0.208 [ms] (mean, across all concurrent requests)
Transfer rate: 3968.69 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 2 0.3 2 5
Processing: 1 2 0.3 2 6
Waiting: 1 2 0.3 2 5
Total: 2 3 0.4 3 8
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 4
80% 4
90% 4
95% 4
98% 4
99% 4
100% 8 (longest request)
файл
# ab -n 100000 -c 16 -v 0 127.0.0.1:80/
Concurrency Level: 16
Time taken for tests: 19.616 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 84400000 bytes
HTML transferred: 61200000 bytes
Requests per second: 5097.93 [#/sec] (mean)
Time per request: 3.139 [ms] (mean)
Time per request: 0.196 [ms] (mean, across all concurrent requests)
Transfer rate: 4201.81 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 2 0.2 2 5
Processing: 1 2 0.2 2 5
Waiting: 1 2 0.2 2 5
Total: 2 3 0.4 3 7
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 4
95% 4
98% 4
99% 4
100% 7 (longest request)
оттетстил раз 10, разница в пределах статистической погрешности, большей нагрузки создать нечем
В таком виде эта связка родилась сегодня утром )
Выложил на хабр именно для того чтобы услышать мнения о возможных доработках.
Использовать её планирую только в варианте с SETEX, т.е. ротация априори включена.
Вариант с падением redis оттестирую и отпишусь.
Да, согласен, вывод несколько преждевремен.
Изначально меня интересовало сравнение SETEX/EVALSHA, где этого теста оказалось достаточно.
Попытаюсь завтра нагрузить сильнее.
Вы имеете ввиду, что я не «довёл» сохранялку до неработоспособного состояния, чтобы понять в каком случае раньше начнутся проблемы? Да, возможно, стоило попытаться, но задача сохранения логов стоит не только в самом хранении, а ещё и в анализе/выборке/парсинге и ротации этих логов.
Если же сравнивать голое сохранение, то здесь, пожалуй надо использовать SET, а не SETEX.
Прокси — это типичная реализация nginx (http://nginx.org/en/docs/http/ngx_http_proxy_module.html), что используется в качестве бакенда не принципиально. У меня в качестве бакендов есть и webrick(ruby) и apache(php) и IIS и даже небольшой самописанный. Также десяток-другой VPS'ок, которые «упадут» задолго до преславутых C10k.
Да, собственно, ничего не мешает использовать такое логирование только на нгинкс, но у меня, обычно, всё в связке (apache, WEBrick или тот-же nginx на бакенде) и nginx на высокопроизводительном фронтенде, который их «прикрывает».
Посетил Ваш сайт, но он не дал мне вопрос, который интересует простого админа — каким образом я могу идентифицировать Ваших ботов.
Хотелось бы увидеть информацию о том с какой автономки осуществляются запросы, либо просто список IP (в удобоваримом для автоматизации процесса виде), какие они используют User-Agent'ы и применима ли к ним идентификация обратным DNS-запросом.
Аттенюатор при монтаже незаменимая вещь. Наибольшее применение они находят в телевидении. Например, на новой линии ставится оборудование отрегулированное под старую оптическую сеть или просто рассчитанное для работы на большие расстояния и имеющее высокую чувствительность фотоэлемента. На коротких длинах кабельных трактов это может привести к перегрузке входных каскадов фотоприемника и как следствие неправильной работе устройства. В принципе, можно даже сжечь оптический приёмник (а цены на них недемократичные).
Поэтому при монтаже телевизионных сетей используют тот момент, что при макроизгибе волокон с увеличением длины световой волны затухание резко возрастает. Несколько витков одномодового волокна вокруг тонкого сердечника (карандаша, гвоздя) вносит затухание в 2-4 дб. Т.е. перед подключением устройства наматывают патчкорд на гвоздь и после подключения отматывают по витку следя за шкалой прибора. Иногда их меняют на постоянные, иногда оставляют такими, чтобы можно было всегда «подрегулировать».
муводила ждёт меня возле дома пока я приеду и заберу доставленный товар.А если секунды не уложились в одну минуту/день/год? :)
И какова производительность этого комбайна?
Ну или, например, сделайте выборку из файла всех запросов сделанных с ip 1.2.3.4 к локейшину /test/ за последние 20 сек
А если хранить логи просто «чтобы было», то в redis, конечно, необходимости нет.
Time taken for tests: 20.768 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 84400000 bytes
HTML transferred: 61200000 bytes
Requests per second: 4815.09 [#/sec] (mean)
Time per request: 3.323 [ms] (mean)
Time per request: 0.208 [ms] (mean, across all concurrent requests)
Transfer rate: 3968.69 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 2 0.3 2 5
Processing: 1 2 0.3 2 6
Waiting: 1 2 0.3 2 5
Total: 2 3 0.4 3 8
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 4
80% 4
90% 4
95% 4
98% 4
99% 4
100% 8 (longest request)
Concurrency Level: 16
Time taken for tests: 19.616 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 84400000 bytes
HTML transferred: 61200000 bytes
Requests per second: 5097.93 [#/sec] (mean)
Time per request: 3.139 [ms] (mean)
Time per request: 0.196 [ms] (mean, across all concurrent requests)
Transfer rate: 4201.81 [Kbytes/sec] received
Connection Times (ms)
min mean[±sd] median max
Connect: 0 2 0.2 2 5
Processing: 1 2 0.2 2 5
Waiting: 1 2 0.2 2 5
Total: 2 3 0.4 3 7
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 4
95% 4
98% 4
99% 4
100% 7 (longest request)
оттетстил раз 10, разница в пределах статистической погрешности, большей нагрузки создать нечем
Выложил на хабр именно для того чтобы услышать мнения о возможных доработках.
Использовать её планирую только в варианте с SETEX, т.е. ротация априори включена.
Вариант с падением redis оттестирую и отпишусь.
Изначально меня интересовало сравнение SETEX/EVALSHA, где этого теста оказалось достаточно.
Попытаюсь завтра нагрузить сильнее.
Если же сравнивать голое сохранение, то здесь, пожалуй надо использовать SET, а не SETEX.
Хотелось бы увидеть информацию о том с какой автономки осуществляются запросы, либо просто список IP (в удобоваримом для автоматизации процесса виде), какие они используют User-Agent'ы и применима ли к ним идентификация обратным DNS-запросом.
А какова всё-таки максимальная длина ключа?
Здесь antirez сообщает о , но в официальной документации подтверждения я не смог обнаружить.
Поэтому при монтаже телевизионных сетей используют тот момент, что при макроизгибе волокон с увеличением длины световой волны затухание резко возрастает. Несколько витков одномодового волокна вокруг тонкого сердечника (карандаша, гвоздя) вносит затухание в 2-4 дб. Т.е. перед подключением устройства наматывают патчкорд на гвоздь и после подключения отматывают по витку следя за шкалой прибора. Иногда их меняют на постоянные, иногда оставляют такими, чтобы можно было всегда «подрегулировать».
p.s. можно добавить в статью…