Что такое пулинг в программировании
Перейти к содержимому

Что такое пулинг в программировании

  • автор:

13.5.2. Pooling

Один из способов узнать, нет ли на сервере каких либо обновлений, применять технологию AJAX, с определенным интервалом времени делать запрос на сервер (рис. 13.5) [15].

Рис. 13.5. Пример асинхронных запросов в AJAX – short polling

Такой тип взаимодействия называется polling (от англ. poll – тянуть), именно вытягиванием данных и занимается браузер. Преимущества перед полным обновлением страницы очевидны, но есть и недостатки. Главным из них является «холостая работа» – часто браузер делает сотни запросов, а в ответ узнает, что новых данных нет. Именно для решения этой проблемы и появилась технология long polling, позволяющая делать запросы, которые возвращают результат, как только он появляется. Пример взаимодействия показан на рис. 13.6 [15].

Рис. 13.6. Пример долгих асинхронных запросов – long polling

Эта техника является золотой серединой между простым AJAX и сложным HTTP-streaming. Главным преимуществом является то, что клиент создает всего одно соединение, через которое получает данные от сервера в реальном времени. Главными недостатками можно назвать сложность реализации и несоответствие духу протокола HTTP.

13.6. Ключевые термины

JSON, JavaScript, AJAX, ExtJS, Prototype, jQuery, Comet.

13.7. Краткие итоги

JSON – текстовый формат обмена данными, основанный на JavaScript и обычно используемый именно с этим языком.

Практическая польза использования JSON открывается при использовании технологии AJAX.

Хотя JSON предназначен для передачи данных в сериализованном виде, его синтаксис соответствует синтаксису JavaScript и это создает ряд проблем безопасности:

  • JavaScript eval();
  • подделка кроссдоменного запроса.
  • Ext.namespace;
  • Ext.override;
  • Ext.extend и соглашения о параметрах конструкторов;
  • Ext.apply;
  • Ext.applyIf.
  • Самый нижний слой;
  • Core:
    • ядро;
    • модуль для использования визуальных компонентов;
    • утилиты;
    • поддержка кросс-браузерного Drag&Drop;
    • возможность хранить состояние интерфейса в независимом хранилище;
    • Store;
    • Reader;
    • Proxy;
    • объект Record.
    • Layout;
    • Tooltip;
    • Таб-панель;
    • Tree;
    • Форма;
    • Grid.
    • $();
    • $$();
    • $F();
    • $A();
    • $H();
    • объект Ajax;
    • Element.
    • переход по дереву DOM, включая поддержку XPath как плагина;
    • события;
    • визуальные эффекты;
    • AJAX-дополнения;
    • JavaScript-плагины.

    Pooling

    В примере создания пулов показано, как расширить Windows Communication Foundation (WCF) для поддержки пулов объектов. Этот образец демонстрирует, как создать атрибут, синтаксически и семантически аналогичный функциям атрибута ObjectPoolingAttribute служб Enterprise Services. Использование пулов объектов может значительно повысить производительность приложения. Однако при неправильном использовании эффект может быть противоположным. Использование пулов объектов позволяет снизить накладные расходы на повторное создание часто используемых объектов, требующих большого объема инициализации. Однако если завершение вызова метода для объекта из пула занимает много времени, сразу после достижения максимального размера пула функция пулов объектов ставит дополнительные запросы в очередь. В результате возможен сбой обслуживания запросов создания некоторых объектов из-за возникновения исключения времени ожидания.

    Процедура настройки и инструкции по построению для данного образца приведены в конце этого раздела.

    Первым шагом при создании расширения WCF является выбор точки расширяемости для использования.

    В WCF термин dispatcher относится к компоненту времени выполнения, ответственному за преобразование входящих сообщений в вызовы методов в службе пользователя и за преобразование возвращаемых значений из этого метода в исходящее сообщение. Служба WCF создает диспетчер для каждой конечной точки. Клиент WCF должен использовать диспетчер, если контракт, связанный с этим клиентом, является дуплексным.

    Диспетчеры каналов и конечных точек обеспечивают расширяемость на уровне канала и контракта, предоставляя различные свойства, которые управляют поведением диспетчера. Свойство DispatchRuntime также позволяет контролировать, изменять или настраивать диспетчерский процесс. В этом образце рассматривается свойство InstanceProvider, которое указывает на объект, предоставляющий экземпляры класса службы.

    IInstanceProvider

    В WCF диспетчер создает экземпляры класса службы с помощью InstanceProvider, который реализует IInstanceProvider интерфейс . У этого интерфейса есть три метода.

    • GetInstance(InstanceContext, Message). Когда прибывает сообщение, объект Dispatcher вызывает метод GetInstance(InstanceContext, Message), чтобы создать экземпляр класса службы для обработки сообщения. Частота вызовов этого метода определяется свойством InstanceContextMode. Например, если свойство InstanceContextMode имеет значение PerCall, для обработки каждого получаемого сообщения создается новый экземпляр класса службы, поэтому метод GetInstance(InstanceContext, Message) вызывается каждый раз, когда приходит сообщение.
    • GetInstance(InstanceContext). Этот метод идентичен предыдущему методу, за исключением того, что он вызывается при отсутствии аргумента Message.
    • ReleaseInstance(InstanceContext, Object). Когда истекает время существования службы, Dispatcher вызывает метод ReleaseInstance(InstanceContext, Object). Как и в случае метода GetInstance(InstanceContext, Message), частота вызовов этого метода определяется свойством InstanceContextMode.

    Пул объектов

    Пользовательская реализация IInstanceProvider обеспечивает необходимую семантику пула объектов для службы. Поэтому в образце имеется тип ObjectPoolingInstanceProvider , который предоставляет пользовательскую реализацию интерфейса IInstanceProvider для создания пула. Когда Dispatcher вызывает метод GetInstance(InstanceContext, Message), пользовательская реализация вместо создания нового экземпляра ищет существующий объект в находящемся в памяти пуле. Если такой объект доступен, метод возвращает его. В противном случае создается новый объект. Реализация метода GetInstance показана в следующем образце кода.

    object IInstanceProvider.GetInstance(InstanceContext instanceContext, Message message) < object obj = null; lock (poolLock) < if (pool.Count >0) < obj = pool.Pop(); >else < obj = CreateNewPoolObject(); >activeObjectsCount++; > WritePoolMessage(ResourceHelper.GetString("MsgNewObject")); idleTimer.Stop(); return obj; > 

    Пользовательская реализация ReleaseInstance добавляет освободившийся экземпляр обратно в пул и уменьшает значение ActiveObjectsCount на единицу. Dispatcher может вызывать эти методы из различных потоков, поэтому требуется синхронизированный доступ к членам уровня класса в классе ObjectPoolingInstanceProvider .

    void IInstanceProvider.ReleaseInstance(InstanceContext instanceContext, object instance) < lock (poolLock) < pool.Push(instance); activeObjectsCount--; WritePoolMessage( ResourceHelper.GetString("MsgObjectPooled")); // When the service goes completely idle (no requests // are being processed), the idle timer is started if (activeObjectsCount == 0) idleTimer.Start(); >> 

    Метод ReleaseInstance предоставляет функцию очистки инициализации. Обычно пул поддерживает минимальное число объектов в течение времени существования пула. Однако возможны периоды интенсивного использования, когда требуется создавать в пуле дополнительные объекты, пока не будет достигнуто заданное в конфигурации максимальное значение. В конце концов, когда активность пула снизится, эти дополнительные объекты могут стать излишней нагрузкой. Поэтому когда значение activeObjectsCount достигает нуля, запускается таймер бездействия, по истечении времени ожидания которого выполняется цикл очистки.

    Добавление поведения

    Расширения уровня диспетчера подключаются с помощью следующих поведений.

    • Поведения служб. Позволяют настраивать всю среду выполнения службы.
    • Поведения конечных точек. Позволяют настраивать конечные точки службы, включая диспетчера каналов и конечных точек.
    • Поведения контрактов. Эти поведения позволяют настраивать классы ClientRuntime и DispatchRuntime в клиенте и службе соответственно.

    С целью реализации расширения создания пулов объектов должно быть создано поведение службы. Поведения служб создаются путем реализации интерфейса IServiceBehavior. Имеется несколько способов сообщить модели службы о пользовательских поведениях:

    • с помощью пользовательского атрибута;
    • Принудительно добавьте его в коллекцию поведения описания службы.
    • путем расширения файла конфигурации.

    В этом образце используется пользовательский атрибут. ServiceHost При создании он проверяет атрибуты, используемые в определении типа службы, и добавляет доступные варианты поведения в коллекцию описаний служб.

    У интерфейса IServiceBehavior имеется три метода — Validate, AddBindingParameters и ApplyDispatchBehavior. Метод Validate используется для обеспечения того, что поведение может быть применено к службе. В этом образце реализация обеспечивает, что служба не настраивается с Single. Метод AddBindingParameters используется для настройки привязок службы. Это не требуется в данном сценарии. Метод ApplyDispatchBehavior используется для настройки диспетчеров службы. Этот метод вызывается WCF при инициализации ServiceHost . Этому методу передаются следующие параметры.

    • Description : этот аргумент содержит описание службы для всей службы. Его можно использовать для проверки данных описания конечных точек, контрактов, привязок и других данных службы.
    • ServiceHostBase : этот аргумент содержит инициализируемый в данный момент объект ServiceHostBase.

    В пользовательской реализации IServiceBehavior создается новый экземпляр ObjectPoolingInstanceProvider , который присваивается свойству InstanceProvider в каждом объекте DispatchRuntime в ServiceHostBase.

    void IServiceBehavior.ApplyDispatchBehavior(ServiceDescription description, ServiceHostBase serviceHostBase) < // Create an instance of the ObjectPoolInstanceProvider. ObjectPoolingInstanceProvider instanceProvider = new ObjectPoolingInstanceProvider(description.ServiceType, minPoolSize); // Forward the call if we created a ServiceThrottlingBehavior. if (this.throttlingBehavior != null) < ((IServiceBehavior)this.throttlingBehavior).ApplyDispatchBehavior(description, serviceHostBase); >// In case there was already a ServiceThrottlingBehavior // (this.throttlingBehavior==null), it should have initialized // a single ServiceThrottle on all ChannelDispatchers. // As we loop through the ChannelDispatchers, we verify that // and modify the ServiceThrottle to guard MaxPoolSize. ServiceThrottle throttle = null; foreach (ChannelDispatcherBase cdb in serviceHostBase.ChannelDispatchers) < ChannelDispatcher cd = cdb as ChannelDispatcher; if (cd != null) < // Make sure there is exactly one throttle used by all // endpoints. If there were others, we could not enforce // MaxPoolSize. if ((this.throttlingBehavior == null) && (this.maxPoolSize != Int32.MaxValue)) < throttle ??= cd.ServiceThrottle; if (cd.ServiceThrottle == null) < throw new InvalidOperationException(ResourceHelper.GetString("ExNullThrottle")); >if (throttle != cd.ServiceThrottle) < throw new InvalidOperationException(ResourceHelper.GetString("ExDifferentThrottle")); >> foreach (EndpointDispatcher ed in cd.Endpoints) < // Assign it to DispatchBehavior in each endpoint. ed.DispatchRuntime.InstanceProvider = instanceProvider; >> > // Set the MaxConcurrentInstances to limit the number of items // that will ever be requested from the pool. if ((throttle != null) && (throttle.MaxConcurrentInstances > this.maxPoolSize)) < throttle.MaxConcurrentInstances = this.maxPoolSize; >> 

    Помимо реализации интерфейса IServiceBehavior у класса ObjectPoolingAttribute имеется несколько членов для настройки пула объектов с помощью аргументов атрибута. К этим членам относятся MaxPoolSize, MinPoolSize и CreationTimeout, и они должны соответствовать набору возможностей пула, предоставляемому службами .NET Enterprise Services.

    Поведение пула объектов теперь можно добавить в службу WCF, заметив реализацию службы только что созданным настраиваемым ObjectPooling атрибутом.

    [ObjectPooling(MaxPoolSize=1024, MinPoolSize=10, CreationTimeout=30000)] public class PoolService : IPoolService < // … >

    Запуск примера

    В этом образце демонстрируются преимущества в производительности, которые могут быть получены при использовании пула объектов в различных сценариях.

    Приложение службы реализует две службы — WorkService и ObjectPooledWorkService . Обе службы совместно используют одну реализацию — обеим требуется обширная инициализация, а затем обе предоставляют метод DoWork() , требующий относительно малых затрат. Единственное отличие заключается в том, что в службе ObjectPooledWorkService настроено использование пула объектов.

    [ObjectPooling(MinPoolSize = 0, MaxPoolSize = 5)] public class ObjectPooledWorkService : IDoWork < public ObjectPooledWorkService() < Thread.Sleep(5000); ColorConsole.WriteLine(ConsoleColor.Blue, "ObjectPooledWorkService instance created."); >public void DoWork() < ColorConsole.WriteLine(ConsoleColor.Blue, "ObjectPooledWorkService.GetData() completed."); >> 

    При выполнении клиента он измеряет время 5-кратного вызова службы WorkService . Затем измеряется время 5-кратного вызова службы ObjectPooledWorkService . Затем отображается разница во времени:

    Press to start the client. Calling WorkService: 1 - DoWork() Done 2 - DoWork() Done 3 - DoWork() Done 4 - DoWork() Done 5 - DoWork() Done Calling WorkService took: 26722 ms. Calling ObjectPooledWorkService: 1 - DoWork() Done 2 - DoWork() Done 3 - DoWork() Done 4 - DoWork() Done 5 - DoWork() Done Calling ObjectPooledWorkService took: 5323 ms. Press to exit. 

    При первом запуске клиента обращение к обеим службам занимает приблизительно одинаковое время. При повторном запуске образца видно, что служба ObjectPooledWorkService возвращает результаты намного быстрее, потому что экземпляр этого объекта уже существует в пуле.

    Настройка, сборка и выполнение образца
    1. Убедитесь, что вы выполнили процедуру однократной установки для примеров Windows Communication Foundation.
    2. Чтобы создать решение, следуйте инструкциям в разделе Создание примеров Windows Communication Foundation.
    3. Чтобы запустить пример в конфигурации с одним или несколькими компьютерами, следуйте инструкциям в разделе Запуск примеров Windows Communication Foundation.

    Если для восстановления конфигурации этого образца используется программа Svcutil.exe, измените имя конечной точки в конфигурации клиента, чтобы оно соответствовало клиентскому коду.

    Polling и long polling

    Чат-боты должны получать уведомления от соцсети моментально. Они не могут проверять обновления каждую секунду, это неэффективно. Большинство ответов от сервера будут неинформативны, вроде «У вас пока нет новых сообщений».

    Такой подход, когда раз в n секунд опрашивается сторонний сервис, называется polling.

    Чтобы сэкономить на ресурсах, можно использовать long polling. Устроен он так же, как и polling, с одним отличием: сервер дольше отвечает. Вообще, при лонг-поллинге сервер отвечает в двух случаях: или потому, что пришло новое сообщение, или потому, что соединение пора разрывать.

    У каждого запроса есть timeout — время, в течении которого нужно ответить. Если на запрос не ответили за это время, считается, что сервер не ответит вообще. Поэтому сервер смотрит на timeout и решает так:

    1. Если за это время у меня не появится обновлений для клиента, я отвечу ему, что их нет.
    2. Если появятся, я отправлю ему обновления сразу, не дожидаясь таймаута.

    Чтобы реализовать long polling на стороне клиента, нужно выставить большой timeout: 30 или 60 секунд.

    Вот так выглядит polling со стороны клиента на Python:

    from time import sleep import requests while True: response = requests.get("http://someurl.com") for message in response: bot.answer(message) sleep(1) 

    А вот так выглядит long polling:

    import requests while True: response = requests.get("http://someurl.com", timeout=60) for message in response: bot.answer(message) 

    Попробуйте бесплатные уроки по Python

    Получите крутое код-ревью от практикующих программистов с разбором ошибок и рекомендациями, на что обратить внимание — бесплатно.

    Переходите на страницу учебных модулей «Девмана» и выбирайте тему.

    Принцип работы свёрточных нейронных сетей

    Глубокие нейронные сети привели к прорыву во множестве задач распознавания образов, таких как компьютерное зрение и распознавание голоса. Сверточная нейронная сеть один из популярных видов нейронных сетей.

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

    2D сверточная нейронная сеть

    Этот приём с несколькими копиями одного и того же нейрона имеет близкую аналогию с абстракцией функций в математике и информатике. При программировании функция пишется один раз и затем повторно используется, не требуя писать один и тот же код множество раз в разных местах, что ускоряет выполнение программы и уменьшает количество ошибок. Аналогично сверточная нейронная сеть, однажды обучив нейрон, использует его во множестве мест, что облегчает обучение модели и минимизирует ошибки.

    Структура сверточных нейронных сетей

    Предположим, дана задача в которой требуется предсказать по аудио,есть ли голос человека в аудиофайле.

    На входе получаем образцы аудио в разные моменты времени. Образцы равномерно распределены.

    Подпишись на рассылку новостей о AI

    Только полезные материалы о машинном обучении и искусственном интеллекте. Мы уважительно относимся к нашим читателям и рассылаем письма не чаше 1 раза в неделю!

    Самый простой способ классифицировать их с нейронной сетью — подключить все образцы к полносвязному слою. При этом каждый вход соединяется с каждым нейроном.

    Более сложный подход учитывает некоторую симметрию в свойствах, которые которая находится в данных. Мы уделяем много внимания локальным свойствам данных: какая частота звука в течение определенного времени? Увеличивается или уменьшается? И так далее.

    Мы учитываем те же свойства во все моменты времени. Полезно знать частоты вначале, середине и в конце. Обратите внимание, что это локальные свойства, поскольку нужно только небольшое окно аудиопоследовательности, чтобы определить их.

    Таким образом, возможно создать группу нейронов A, которые рассматривают небольшие сегменты времени в наших данных. A смотрит на все такие сегменты, вычисляя определенные функции. Затем, выход этого сверточного слоя подается в полносвязный слой F.

    В приведенном выше примере A обрабатывало только сегменты, состоящие из двух точек. Это редко встречается на практике. Обычно, окно слоя свертки намного больше.

    В следующем примере A получает на вход 3 отрезка. Это тоже маловероятно для реальных задач, но, к сожалению, сложно визуализировать A, соединяющее множество входов.

    Одно приятное свойство сверточных слоев состоит в том, что они являются составными. Можно подавать вывод одного сверточного слоя в другой. С каждым слоем сеть обнаруживает более высокие, более абстрактные функции.

    В следующем примере есть новая группа нейронов B. B используется для создания еще одного сверточного слоя, уложенного поверх предыдущего.

    Сверточные слои часто переплетены pooling (объединяющими) слоями. В частности, есть вид слоя, называемый max-pooling, который чрезвычайно популярен.

    Часто, нас не волнует точный момент времени, когда присутствует полезный сигнал в данных. Если изменение частоты сигнала происходит раньше или позже, имеет ли это значение?

    Max-pooling вбирает максимум фичей из небольших блоков предыдущего уровня. Вывод говорит, присутствовал ли полезный сигнал функции в предыдущем слое, но не точно где.

    Max-pooling слоев — это «уменьшение». Оно позволяют более поздним сверточным слоям работать на больших участках данных, потому что небольшие патчи после слоя объединения соответствует гораздо большему патчу перед ним. Они также делают нас инвариантными к некоторым очень небольшим преобразованиям данных.

    В наших предыдущих примерах использовались одномерные сверточные слои. Однако сверточные слои могут работать и с более объемными данными. Фактически самые известные решения на базе сверточных нейронных сетей используют двумерные сверточные нейронные сети для распознавания образов. .

    В двумерном сверточном слое вместо того, чтобы смотреть на сегменты, A будет смотреть патчи.

    Для каждого патча, A будет вычислять функции. Например, она может научиться обнаруживать наличие края, или текстуру, или контраст между двумя цветами.

    В предыдущем примере вывод сверточного слоя подавался в полносвязный слой. Но, возможно составить два сверточных слоя, как это было в рассмотренном одномерном случае.

    Мы, также можем выполнять max-pooling в двух измерениях. Здесь мы берем максимум фичей из небольшого патча.

    Это сводится к тому, что при рассмотрении целого изображения не важно точное положение края, вплоть до пикселя. Достаточно знать, где он находится в пределах нескольких пикселей.

    Также, иногда используются трехмерные сверточные сети для таких данных, таких как видео или объемные данные (например, 3D-сканирование в медицине). Однако, такие сети не очень широко используются, и гораздо сложнее в визуализации.

    Ранее, мы говорили, что A — группа нейронов. Будем более точными в том: что такое А?

    В традиционных сверточных слоях A представляет собой параллельную связку нейронов, все нейроны получают одинаковые входные сигналы и вычисляют разные функции.

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

    В статье ‘Network in Network’ (Lin et al. (2013)) предлагается новый слой «Mlpconv». В этой модели, A имеет несколько уровней нейронов, причем последний слой выводит функции более высокого уровня для обрабатываемого региона. В статье, модель достигает впечатляющих результатов, устанавливая новый уровень техники в ряде эталонных наборов данных. Для целей этой публикации мы сосредоточимся на стандартных сверточных слоях.

    Результаты сверточных нейронных сетей

    В 2012 году Alex Krizhevsky, Ilya Sutskever, и Geoff Hinton достигли существенного улучшения качества распознавания в сравнении с известными на тот момент решениями (Krizehvsky et al. (2012)).

    Прогресс был результатом объединения нескольких подходов. Использовались графические процессоры для обучения большой (по меркам 2012 года), глубокой нейронной сети. Использовался новый тип нейронов (ReLU) и новая техника для уменьшения проблемы, называемой «overfitting» (DropOut). Использовали большой набор данных с большим количеством категорий изображений (ImageNet). И конечно же, это была сверточная нейронная сеть.

    Архитектура, показанная ниже, была глубокой. Она имеет 5 сверточных слоев, 3 pooling с чередованием и три полносвязных слоя.
    .

    Сеть была обучена классификации фотографий в тысячи разных категорий.

    Модель Крижевского и др. была способна дать правильный ответ в 63% случаев. Кроме того, правильный ответ из 5 лучших ответов, присутствует 85% прогнозов!

    Проиллюстрируем, что узнает первый уровень сети.

    Напомним, что сверточные слои были разделены между двумя графическими процессорами. Информация не идет назад и вперед по каждому слою. Оказывается, каждый раз, когда модель запускается, обе стороны специализируются.

    Фильтры, полученные первым сверточным слоем. Верхняя половина соответствует слою на одном графическом процессоре, нижняя — на другом. From Krizehvsky et al. (2012)

    Нейроны с одной сторону, фокусируются на черно-белом цвете, учась обнаруживать края разных ориентаций и размеров. Нейроны с другой стороны, специализируются на цвете и текстуре, обнаруживают цветовые контрасты и узоры. Помните, что нейроны случайным образом инициализируются. Ни один человек не пошел и не поставил их пограничными детекторами, или разделил таким образом. Это произошло при обучении сети классификации изображений.

    Эти замечательные результаты (и другие захватывающие результаты примерно в то время) были только началом. За ними быстро последовало множество других работ, которые тестировали измененные подходы и постепенно улучшали результаты или применяли их в других областях.

    Сверточные нейронные сети являются важным инструментом в компьютерном видении и современном распознавании образов.

    Формализация сверточных нейронных сетей

    Рассмотрим одномерный сверточный слой с входами и выводами :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *