По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Двенадцатая часть тут.
Другая проблема, с которой сталкиваются решения мультиплексирования, - это возможность адресовать конкретный экземпляр службы, реализованной на нескольких хостах, используя один адрес. Рисунок 1 иллюстрирует это.
На рисунке 1 некоторые службы, S, должны быть спроектированы так, чтобы повысить их производительность. Для достижения этой цели была создана вторая копия службы, две копии которой называются S1 и S2. Эти две копии службы работают на двух серверах, M и N. Проблема, которую anycast пытается решить, заключается в следующем:
Как можно направить клиентов к наиболее оптимальному экземпляру сервиса?
Одним из способов решения этой проблемы является перенаправление всех клиентов на одно устройство и распределение нагрузки на серверы с помощью балансировщика нагрузки в зависимости от топологического расположения клиента, нагрузки на каждый сервер и других факторов. Однако это решение не всегда идеально. Например, что, если балансировщик нагрузки не может обработать все запросы на подключение, сгенерированные клиентами, которые хотят получить доступ к различным копиям службы? Какие сложности будут добавлены в сеть, чтобы балансировщик нагрузки мог отслеживать состояние различных копий службы?
Anycast решает эту проблему, присваивая один и тот же адрес каждой копии сервиса. В сети, показанной на рисунке 4, тогда M и N будут использовать один и тот же адрес, чтобы обеспечить достижимость для S1 и S2. M и N будут иметь разные адреса, назначенные и объявленные для обеспечения доступности для других служб, а также для самих устройств.
H и K, маршрутизаторы первого перехода за пределами M и N, будут объявлять этот же адрес в сети. Когда C и D получат два маршрута к одному и тому же пункту назначения, они выберут самый близкий маршрут с точки зрения метрик. В этом случае, если каждый канал в одной и той же сети настроен на одну и ту же метрику, то C будет направлять трафик, исходящий из A, и направленный на адрес службы, в направлении M. D, с другой стороны, будет направлять трафик, полученный из B и предназначен для адреса службы, к N. Что произойдет, если два экземпляра службы находятся на одинаковом расстоянии друг от друга? Маршрутизатор выберет один из двух путей, используя локальный алгоритм хеширования.
Anycast часто используется для крупномасштабных служб, которые должны масштабироваться путем предоставления большого количества серверов для поддержки одного сервиса. Например:
Большинство крупных серверов системы службы доменных имен (DNS) на самом деле представляют собой набор серверов, доступных через anycast адрес.
Многие крупномасштабные веб-сервисы, в частности социальные сети и поиск, где один сервис реализован на большом количестве периферийных устройств.
Службы кэширования контента часто используют anycast для распространения и обслуживания информации.
Правильно спроектированный anycast может обеспечить эффективную балансировку нагрузки, а также оптимальную производительность для служб.
Для пользователей, которые обладают премиальной лицензии на Cisco Unified Contact Center Express (UCCX), одной из самых крутых фич является наличие возможной интеграции и отправки запросов в базу данных. Сами запросы могут строиться на базе введенной звонящим информации, его номера – чего угодно.
Безусловно важно сделать ¬¬изначальный дизайн скриптов правильным и учитывать нагрузку. Большие и тяжелые скрипты, которые имеют много «плеч» в БД (базу данных), значительно увеличивают нагрузку на ресурсы сервера. А если БД еще и удалена от сервера CCX и имеет место сетевая задержка, то может иметь место прямое воздействие на бизнес и лояльность звонящего вам клиента.
Обзор Cisco Unified CCX Script Editor
Для создания и управления IVR скриптами в UCCX используется специальный инструмент - Cisco Unified CCX Editor. Он позволяет визуально управлять некими блоками, которые отвечают за то, или иное действие. Выглядит эта палетта следующим образом:
Давайте рассмотрим раздел Database. Здесь мы видимо 4 пункта:
DB Get - сопоставление полученных данных из БД к переменным скрипта;
DB Read - подключение к серверу и запрос;
DB Release - закрываем подключение к БД;
DB Write - если нужно внести изменения в БД, используем Write метод;
На скриншоте выше видно, что каждый скрипт начинается с события Start и заканчивается событием End. Во время звонка, по ходу выполнения скрипта, мы можем запрашивать данные из БД сколько угодно раз. Каждый запрос имеет свой отдельный список шагов, которые указаны в списке из 4х пунктов выше.
Мы рекомендуем предварительно обкатать все SQL запросы, доступ системы и прочие рабочие факторы перед выгрузкой в продуктивную среду
Например, давайте посмотрим, что скрыто внутри блока DB Read:
Взглянем на поля, которые доступны для конфигурации:
DB Resource Name - метка запроса. Своего рода метка;
Data Source Name - источник данных (DSN), указанное в административной консоли UCCX (Cisco Unified CCX Administration Database);
Timeout (in sec) - пауза выполнения запроса. Этот интервал защитит вашу систему от, например, потери связи с БД. То есть, максимум 7 секунд ожидания. Кстати, если указано как 0, то запрос не будет ограничен по времени;
Теперь из вкладки General переходим во вкладку Field Selection:
Запрос - SQL – команда (запрос), который вы ходите выполнить. Например, SELECT fld1, fld2 from tbl where fld1 = $variable - выбираем два поля из таблицы, где одно из полей равно переменной, которую, мы ранее, присвоили в скрипте (DTMF от клиента, например);
Test (кнопка) - нажмите на эту кнопку, чтобы проверить синтаксис запроса и подключение к БД;
Number of rows returned - количество вернувшихся строк запроса, в случае, если была нажата кнопка Test;
Show all fields (select table/view) - показать все поля в таблице, к которой выполняется подключение;
Отлично, разобрались. Теперь давайте взглянем на блок DB Get:
DB Resource Name - лэйбл или имя для этого запроса;
Data Source Name - имя БД (настраивается на стороне Cisco Unified CCX Administration);
Refresh Database Schema (кнопка) - кнопка, которая отвечает за подтягивание данных БД и таблицы в CCX Editor;
Переходим во вкладку Field Selection:
Table/View - данное поле показывает имя таблицы из БД, которая выбрана во вкладке General, которую мы описывали выше;
Табличное поле:
Field Name - имя поля, в выбранной БД;
Data Type - типа данных (строка/число и так далее);
Local Variable - переменная скрипта, которая будет хранить соответствующее поле;
Add/Modify (кнопки) - кнопки, которые отвечают за модификацию полей (кроме типа данных, он read only);
Полученные данные можно использовать в скрипте, например, чтобы озвучивать клиенту (TTS) его данные по номеру телефона, или по введенным цифрам (номер заказа). Кстати, аналогичную фичу мы реализовали в связке Yandex.SpeechKit и Asterisk.
Вот несколько команд Linux, которые могут проверять скорость соединения, анализировать задержки и проверять, доступны ли другие системы.
Существует довольно много инструментов, которые могут помочь проверить ваше подключение в командной строке Linux. В этой статье мы рассмотрим ряд команд, которые могут помочь оценить скорость вашего соединения, проверить, можете ли вы связаться с другими системами, проанализировать задержки соединения и определить, доступны ли определенные службы.
Ping
Команда ping-это самая простая и наиболее часто используемая команда для выполнения базового тестирования подключения. Он посылает пакеты, называемые эхо-запросами, и это пакеты, которые запрашивают ответ. Команда ищет ответы и отображает их вместе с тем, сколько времени занял каждый ответ, а затем сообщает, какой процент запросов был получен.
Время отклика будет в значительной степени зависеть от того, сколько маршрутизаторов должны пересечь запросы и перегружена ли ваша сеть. Пингинг локальной системы может выглядеть так. Обратите внимание на небольшое количество миллисекунд, необходимых для каждого ответа, и потерю пакетов в 0%.
В системах Linux эхо-запросы будут продолжаться, пока вы не наберете ^c (CTRL+C), чтобы их остановить. Некоторые системы, включая Windows, выдают четыре эхо-запроса, а затем останавливаются самостоятельно. Удаленная система будет реагировать значительно дольше. Отсутствие потери пакетов - это всегда хороший знак, и даже когда вы проверяете связь с удаленной системой, вы, как правило, ожидаете получить ответ от нее, если только не возникнет проблема.
Команда ping обеспечивает простой способ проверки сетевого подключения для домашней сети. Отправляйте запросы в общедоступную систему, и вы должны ожидать 0% потери пакетов. Если у вас возникли проблемы, команда ping, скорее всего, покажет значительную потерю пакетов.
Traceroute
Предварительно установите пакет traceroute
Traceroute-это гораздо более сложная команда, поскольку она выполняет серию проверок, чтобы увидеть, сколько времени занимает каждый переход между маршрутизаторами, и сообщает об этом обратно. Если общая проверка занимает много времени, это может означать, что один или два прыжка перегружены. Если сообщенные результаты сводятся к последовательности звездочек, то последний достигнутый маршрутизатор не может ответить на используемый тип пакета (UDP по умолчанию в системах Linux).
Команда traceroute использует хитроумную технику для определения времени каждого прыжка. Он использует параметр времени жизни (TTL), который уменьшается с каждым прыжком, чтобы гарантировать, что каждый маршрутизатор на маршруте в какой-то момент отправит обратно сообщение об ошибке. Это позволяет traceroute сообщать о продолжительности времени между каждым переходом.
Вот пример использования traceroute для доступа к локальной системе (один переход и быстрый ответ):
В следующем примере, команда traceroute пытается связаться с удаленной системой, но не может сообщить о каждом прыжке (те, которые показывают звездочки), потому что маршрутизаторы на некоторых прыжках не отвечают на тип используемого пакета. В этом нет ничего необычного.
По умолчанию максимальное количество переходов для traceroute составляет 30. Обратите внимание, что этот параметр отображается в первой строке вывода. Его можно изменить с помощью аргумента -m (например, traceroute -m 50 merionet.ru).
Netcat
Предварительно установите пакет netcat
Команда netcat-это многофункциональная сетевая утилита для записи данных по сети из командной строки, но в форме, показанной ниже, позволяет просто определить, можно ли подключиться к определенной службе. Первоначально он был написан для nmap (the network mapper).
Отправляя нулевые байты (параметр -z) на конкретный порт в удаленной системе, мы можем определить, доступна ли соответствующая служба, не прибегая к фактическому использованию соединения.
Как вы, наверное, заметили, команду netcat можно вызвать с помощью nc или ncat.
Speedtest
Предварительно установите пакет speedtest-cli
Инструмент speedtest проверяет скорость вашего соединения с вашим интернет-провайдером. Обратите внимание, что скорость загрузки нередко бывает значительно ниже скорости выгрузки (отдачи). Интернет-провайдеры понимают, что большинство людей загружают значительно больше данных, чем отправляют. Инструмент speedtest выделит любые различия. В приведенном ниже тесте скорость загрузки не намного превышает скорость загрузки.
Результаты команд будут несколько отличаться от теста к тесту.
Вы также можете использовать утилиту speedtest через браузер, зайдя на сайт speedtest.net.
nethogs
Команда methods использует совершенно иной подход, чем команды, описанные выше. Он группирует использование полосы пропускания по процессам, чтобы помочь вам точно определить конкретные процессы, которые могут вызвать замедление сетевого трафика. Другими словами, он помогает вам точно определить "net hogs".