Работа нагруженной системы

[mirk]

Наткнулся на статью Новые Бабушкины. «Инновационное» облачное видеонаблюдение
Там высмеивается одно решение видеонаблюдения:

Linux утилитка wget подключалась к удаленной камере и запрашивала один единственный JPEG, который записывался в файл. Далее вызывалась другая утилита с именем только что записанного и предыдущего JPEGа и, судя по всему, сообщала было ли движение в кадре или нет. Если движение было, то информация об этом записывалась в базу MySQL еще одним вызовом. А затем все повторялось снова и снова. Как говорится, все гениальное — просто! И неважно, что уже 30 камер вешали файловую систему и процессор достаточно мощного сервера почти намертво.

Ведь (если я правильно понимаю) потери идут на вызовах скриптов, но они должны бить минимальны. Особенно если сравнивать с общим временем выполнения (скачка файла, проверка движения и т.п.).

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

Как вообще правильно строить подобные системы?

[Xenar]

Скрипты конечно вряд ли грузят систему, а вот запись потока в виде отдельных кадров в Mysq (насколько я понял) должно нехило напрягать sql-движок и соответственно всю систему
Решение, ну вот например, в свое время делал на этой основе http://habrahabr.ru/post/72491/

[vada]

За такую реализацию разработчикам надо пальцы ломать чтоб больше клавиатуру не трогали

[mirk]

а вот запись потока в виде отдельных кадров в Mysq (насколько я понял) должно нехило напрягать sql-движок и соответственно всю систему

Нет.
Написано ведь: "утилитка wget подключалась к удаленной камере и запрашивала один единственный JPEG, который записывался в файл".
В MySql пишется только служебная информация: "Если движение было, то информация об этом записывалась в базу MySQL".

За такую реализацию разработчикам надо пальцы ломать чтоб больше клавиатуру не трогали

Что именно плохо и как надо было сделать?

P.S. Я к этой системе никакого отношения не имею. Просто обратил внимание и интересно было бы разобраться.

[NTFS]

Я не вижу, в каком месте эта система может быть нагружена.

wget - очень быстр.
Распознавание движения - может нагружать cpu, но не диск.
Запись в MySQL (одну из самых быстрых RDBMS) - вообще не проблема.

Вообще, разбиение системы на части в виде исполнимых файлов есть правильный unix-way.

[mig-31]

Простое решение, unixовый подход. Не вижу места, где бы система нагружалась.
А статья типичый пиар. Как вот мы такая супер фирма и не додумались до такого.

[debi12345]

wget - очень быстр.

Но в таком режиме ему придется каждый раз устанвливать соединение - что может замедлить операцию пепесылки раз эдак "в". Более ллогично было бы (и я бы так сделал) держать постоянный канал - например через "клиент-сервер" связку на CORBA, прочем CORBA-сервер может хранить в памяти (чтобы не читать с файловой системы или из БД) старый кадр и сличать его с вновь принятым. Одно "но" - эту связку придется писать либо на C, либо на Java. Для FPC рабочей CORBA-реализации не существует (хотя под DELPHI/Kylix есть - mtORB).

[STAKANOV]

Но так ли уж плох подобный подход?

ужасен, 30 камер и мощный сервер как детекторы движения это очень дорого

Если предположим, что это просто дополнительные функции к системе видеонаблюдения, то подход нормальный, а что именно там грузит систему посмотреть надо, подозреваю, что утилита которая изображения сравнивает. Из данных у нас только 30 камер, значит возможно одновременно обрабатываются 60 картинок. Короче тут все считать надо и тестировать. В зависимости от результата и стоимости делать выводы.

[mirk]

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

Спорный вопрос, по многим причинам:
1. Не такое уж большое время будет теряться на установление соиденения (по сравнению с другими операциями).
2. Некоторые (а может и многие - тут я не сильный специалист) камеры не позволяют все делать через одно соединение - каждый раз делается HTTP запрос.

ужасен

Чем именно?
Вопрос не в ошибке их скриптов или еще чем (почему у них виснет и теряется производительность).
Вопрос именно в архитектуре подобного решения.

Нашел описание системы пиарщиков.
Некоторые вещи насторожили - специалисты ли они вообще?
Идет постоянная подмена понятий, сравнение теплого с мягким и не совсем понятный пиар.

[debi12345]

Не такое уж большое время будет теряться на установление соиденения (по сравнению с другими операциями).

Зря так считаете. Особенно в облачном ("интернет") случае

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

Такой (с таймаутом для АКТИВНЫХ сессий) прошивки просто быть не может Точнее на трезвую голову не создается.

Нашел описание системы пиарщиков.

А что Вы хотели от "технарей" в стране, живущей торговлей ресурсами и адаптацией импорта. А-ля "Мексика" Купил и адаптирвал дешево - продал дорого - вот и весь "хайтек"

[dedm0zaj]

а с какой частотой запрашивается jpeg?

[STAKANOV]

Чем именно?

стоимостью...и хотя это был сарказм... датчик движения дешевле камеры, а для 30 датчиков и сервер не нужен, маломощного ПК хватит

Вопрос именно в архитектуре подобного решения.

Нормальная архитектура. Любой вариант имеет права на существование, если он справляется с задачей (в описанном примере проблема не архитектуре, а в реализации) + еще стоимость надо смотреть.