Общий внешний вид Реальное применение - umotnas.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Общий внешний вид Реальное применение - страница №1/1

Общий внешний вид






Реальное применение




FindImage

В ЛайнАкт есть функция – подбор изображений к материалу. Когда человек вводит информацию на сайт, система предлагает ему подобрать картинку к тексту. Человек нажимает «подобрать картинку», открывается окно:





Рисунок. Первые результаты – изображения с IconFinder.Com, вторые – с Bing.


  • Происходит запрос к Microsoft Bing Search API на картинки, по имени заголовка вводимой информации.

  • Запрос к Bing Translate API на перевод с русского на английский этого заголовка. Перевод нужен для запроса к IconFinder.Com, так как его база английская.

  • Переведенный текст – запрос к IconFinder на дизайнерские иконки с лицензией Creative Commons (свободные к использованию).

В результате человек может кликнуть на результат Bing или IconFinder и таким образом за несколько секунд снабдить материал (лицензионной) картинкой. Эта функция уникальна, нет информации о её наличии в конкурирующих системах конструкторов сайтов или CMS.


Ситуация

1 июля 2012 года пришло письмо от Bing – что с 1 августа 2012 Bing Search API закрывается и переходит на Azure Data Marketplace. На Data Marketplace – другое API и платная подписка.


Задача – принять решение, как сильно используется функция подбора изображений, и какую подписку оформлять.
Решение. В функцию ЛайнАкт engine/find_image добавлено отслеживание её вызова.

Визуальные результаты:

http://svn.lact.ru:5000/graphs/lineactworld.com%2Fengine%2Ffind_image



c:\users\contact\downloads\chart (2).png
Результат. Видно, что функция используется примерно 10-20 раз в сутки. С учётом, что пользователь может ввести новое имя для поиска, и это происходит ~5 раз за запрос (ох как нужно JS-API!!!! Для точного выяснения), всего в сутки делается 50-100 запросов. Итого в месяц – 100*30 = 3000 запросов.

Становится ясно, какую подписку на Microsoft Azure Data Marketplace оформлять (там пакеты по 5000 запросов в месяц), становится ясно, что функция используется людьми, и её следует оставить в системе.



DB Backup size


ЛайнАкт – ежедневно бекапит базы данных со всех автономных установок (сейчас их две – в Ирландии и в Белоруси). Бекап – это sql-файл с базой. Он готовится на головном сервере установки, и затем внешняя машина-бекапер по рсинху затягивает его к себе. Затем делает из него rar-архив и кладет в папку с датой.

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

Решение. Для контроля за процессом решено отслеживать размер rar-архива ежедневного бекапа. Если значения есть и они ежедневно различны – значит sql-дамп создаётся, по рсинху забирается, и в архив пакуется – то есть бекап идет.
Добавлена команда на отправки события в конец скрипта бекапа на машине-бекапере.

Например, график для архива базы лакт.ру:



Пояснение. Уменьшение размера архива – это тоже хорошо, так как это означает, что работают скрипты реального удаления «удаленных» данных. Провал графика на 2 августа – это 1го были тесты удаления удаленных сайтов и всех их данных.



Уточнение. Коммент Виталия: По-нормальному удалять я стал только с 3его (этим же днем датируется коммит, в котором появился соответствующий named_scope). Итого – выяснить, что это было, совместив графики данных (element) с этой базой. Так поймем ист. причину.

Пояснение 2. Конечно это не совсем достаточный контроль, но на 80% проблем сработает.


Результат. Функция визуального контроля ежедневного бекапа.

Exceptions Hang Log

AntiHacker tracker



Запуски SharpEye

Rails Models

Перегрузка серверов




Сбой бекапа Lepshy 10/2012



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

5 октября сломался диск Lepshy. (вот повезло то!) Восстановили из локального бекапа хостера. После восстановления забыли открыть порт рсинха для удаленного бекапа базы.

В конце октября случайно это выяснили.

Evented помог выяснить ситуацию и картину происходящего.

Пояснения к графику.

График показывает объем rar-архива sql-дампа. Событие постится после ежедневного бекапа с бекапящего сервера.

1 октября – последнее событие о бекапе.

Затем несколько дней событий нет – бекап-сервер не работал.

А затем 3 недели – бекап заработал, но не мог бекапить, поэтому посылал одно и то же значение – размер последней удачно пробекапленой базы. Это подчеркнуто красным.

Визуальное представление ситуации позволило быстрее понять причину – бекап запускается, но не идет – и выяснить первопричину – закрыт 873 rsync порт на Lepshy.



Сбой rsync-а




Видим 2 точки роста - 28 октября и 15 ноября. Это очень подозрительно. Идем проверять - видим что работа рсинха прервана на половине, в результате есть файл бекапа и плюс к нему еще 1 файл с полускачанными изменениями. Вот эти росты - это добавился такой файл. Два раза.