acuity scheduling что это
Acuity Scheduling: внедрение и интеграция разработчиков
This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.
Решения для разработчиков Acuity Scheduling
Сегодня я познакомлю вас с платформой для разработчика Acuity Scheduling для встроенного бронирования и, отдельно, ее API для индивидуальной интеграции. Если вы ее не видели, я рекомендую вам ознакомиться с нашим основным введением в службу бронирования и назначения календаря Acuity Scheduling из первого эпизода.
Встраивание обеспечивает легкий способ добавления расписания и назначения на любой сайт. С Acuity’s Appoint Scheduling API вы можете интегрировать все свои сложные функции календаря в свой собственный веб-сайт, службу или мобильное приложение.
Acuity Scheduling гордится тем, что является самым доступным для разработчиков решением для планирования. Но это также чрезвычайно эффективный веб-сервис для всех ваших потребностей в планировании, бронировании и назначении календаря.
Если вы хотите узнать больше о своих возможностях планирования, ориентированных на потребителя, посмотрите видео по расписанию ниже:
Поскольку пространство здесь ограничено, я призываю вас зарегистрироваться в Acuity и изучить больше. Но теперь давайте погрузиться в портал разработчика Acuity.
Прежде, чем я начну, я хочу, чтобы вы обратились к нам с любыми вопросами, которые могут возникнуть по поводу Acuity Scheduling и нашей серии учебников. Пожалуйста, разместите их в комментариях ниже или не стесняйтесь обращаться ко мне @lookahead_io в Twitter.
Интеграция с Acuity’s Calendar Booking
Вам не обязательно быть программистом или использовать API Acuity для интеграции своих функций планирования и календаря на ваш сайт. Существует несколько простых подходов.
Связывание с функциями планирования Acuity
Достаточно просто связать свой веб-сайт или приложение с веб-сайтом Acuity. Это приводит клиентов к настроенному графическому интерфейсу на веб-сайте Acuity. Вот один из примеров из первого эпизода:
Документация по внедрению разработчика Acuity также содержит инструкции по доставке общих полей из вашего приложения в Acuity Scheduler, что экономит ваше время пользователя.
Вот пример URL, передающий значения Acuity с вашего сайта:
И вы можете отправлять различные поля:
Если вы настроили пользовательские поля формы приема в Acuity, вы также можете перенести их посредством ссылки:
Они даже поддерживают отправку предварительной конфигурации полей раскрывающегося списка и флажков.
Внедрение Планировщика на вашем сайте
Вы также можете разместить iframe из своей учетной записи Acuity на свой собственный веб-сайт.
Код для моей учетной записи выглядит следующим образом:
Они предлагают руководства для общих платформ:
И их разработчики также могут сделать интеграцию для вас, если вы спросите. У них есть простая веб-форма для этого (для этого требуется, чтобы вы поделились своей регистрационной информацией, которую, конечно же, можете изменить после интеграции):
Встраивание в приложения
Вы также можете легко встраивать планировщик Acuity в приложения для iOS и Android. Код для встраивания HTML в Acuity также можно использовать для встраивания планировщика в собственные приложения с помощью WKWebView на iOS или WebView на Android.
Acuity предоставляет примерный код для размещения в iOS и Android для GitHub. В основном, вы просто загружаете репозиторий и открываете iOSWebviewAcuity с помощью Xcode или AndroidWebviewAcuity с Android Studio.
Теперь давайте поговорим о API-интерфейсе планирования и бронирования Acuity.
API-интерфейс разработчика Acuity Scheduling
Мы рассмотрели связь с клиентом и встраивание платформы разработчика Acuity, поэтому перейдем к аспекту API Планирования.
Если вы хотите расширить возможности своего веб-сайта, сервиса или мобильного приложения с возможностями планирования, календаря и бронирования Acuity, вы можете использовать API для расширения набора функций и услуг, которые вы предлагаете. И вы можете настроить пользовательский интерфейс планирования по своему усмотрению.
Документация разработчика Acuity
Я рекомендую начать с документации API планирования (см. выше) и ее руководств, в которых описывается, как использовать свой API для общих сценариев.
Ресурсы API Acuity Scheduling
Существует также отличный API Quickstart:
Acuity предоставляет языковые комплекты для разработки для PHP и Node.js.
Каждый из них содержит общий интерфейс для API и служебных методов, а также множество примеров.
Планирование с помощью Acuity API Scheduling
Давайте рассмотрим основы планирования с помощью PHP SDK.
Начинаем
Настройка SDK для Acuity очень простая с использованием Composer. Просто запустите команду:
Создание инстанса
Используя ключи API, вы создадите экземпляр библиотеки:
Сегодня я пропущу проверку доступности, но вы можете найти более подробные сведения об этом примере в моем учебном пособии Как назначить встречу с помощью API планирования Acuity.
Планирование
Вот как вы назначаете встречу с помощью библиотеки:
После того, как новая встреча находится в системе, внутренние службы Acuity управляют важными вещами. Админы могут просматривать назначение на своей панели, и они отправляют автоматические письма с подтверждением и выполняют любую интеграцию, такую как синхронизация календаря Acuity.
В заключение
Мы много узнали о возможностях Acuity Scheduling. Я по-прежнему лично впечатлен их возможностями.
До сих пор мы рассмотрели внешний интерфейс, ориентированный на потребителя, и сегодня мы рассмотрели встроенное планирование, мобильную интеграцию и введение в API-интерфейс Acuity для разработчиков. Мы даже показали вам, как планировать свую первую встречу.
Когда мы завершаем этот эпизод, стоит отметить, что после того, как новая система назначается в систему, бэкэнд-услуги Acuity управляют важными вещами. Администратор может просмотреть назначение на бэкэнд, и они отправляют автоматические письма с подтверждением и выполняют любые интеграционные функции, такие как двухсторонняя синхронизация календаря Acuity.
В следующем эпизоде я опишу некоторые оставшиеся аспекты платформы планирования и резервирования Acuity. Мы коснемся собственной интеграции OAuth от Acuity, которая полезна, если у вас есть команда людей, зарегистрированных в Acuity, используя ваше собственное приложение для календарных операций. И мы рассмотрим, как вы можете вернуть данные из Acuity, либо для пользовательской отчетности, либо добавить ее в свою собственную базу данных, либо стороннюю программу, такую как создание событий Salesforce для встреч, созданных в Acuity. Мы также рассмотрим webhook notifications, чтобы знать, когда была запланирована работа по планированию, а также API отчетов.
Пожалуйста, продолжайте сообщать нам, какие области вы хотели бы видеть более подробно в предстоящих эпизодах. Пишите свои идеи и вопросы в комментариях ниже или подпишитесь на меня в Twitter @lookahead_io.
Если вам понравился этот учебник, обязательно ознакомьтесь с моей страницей инструктора Envato Tuts +, чтобы увидеть некоторые из моих других учебников и серий.
All you need to do is show up at the right time.
Your online assistant, working 24/7 to fill your schedule.
It’s easy & user-friendly. No credit card or commitments. We promise you’ll love it!
Never ask “what time works for you?” again.
Say goodbye to phone tag. With your customized scheduling page, clients can easily view your real-time availability and self-schedule their own appointments.
Simplicity,
Meet Power.
Control your availability 24/7.
Manage multiple locations and employees, only show your clients the calendar you want them to see, and harness all the flexibility to make scheduling work for you.
Organize your schedule.
Auto-adjust for time zones, let clients easily cancel & reschedule themselves, and send automated reminders to keep clients prompt.
Organize client information.
Ask clients to fill out intake forms at the point of booking, so you’ll have everything you need to know about them in one place.
Adapts to any business.
Explore these (fake) businesses to experience the (real) powerful features your clients can rely on.
“When I first started I had new clients come to me not because of my experience, but because I was the easiest to schedule with.”
More than just a scheduling tool.
It’s a cohesive, user-friendly system for running your business end-to-end.
Integrate with powerful third-party apps.
Knowing your name is only the beginning.
Our global award-winning team of real (awesome) humans proudly support over 100,000 businesses. Whatever you need, we’ll be there to help you take over the world, one problem-solving conversation at a time.
Acuity scheduling что это
Топ-менеджеры компании в Калифорнии говорят, что хотят максимально упростить транзакции между бизнесом и клиентами.
Приложения для консультантов и тренеров: маркетологов, репетиторов, а также стилистов, массажистов и пр. Вы выставляете длительность, стоимость и доступность консультации или приема в салоне.
C Acuity Scheduling и Booksy можно полноценно работать из России (включая платежи). Первый бесплатен, второй стоит смешные 40 рублей в месяц. У Booksy есть даже русскоязычный сайт
Российское название кнопки: Записаться.
Комиссия: от 2,5% для западных игроков.
Российское название кнопки: Купить билеты.
Приложения для рестораторов и владельцев отелей. Правда, все они нацелены на рынки США, Европы и Латинской Америки. Впрочем, у сервиса SevenRooms есть возможность запросить бесплатное демо программы именно для России.
Приложения для доставки еды.
Увы, пока Delivery Club и Яндекс.Еда не съездят к Кевину Систрому на поклон в Калифорнию, этого фукционала нам в России не видать. И Европе тоже: данные сервисы работают исключительно в Америке.
Российское название кнопки: «Оформить заказ».
Продажи в Инстаграм: кнопка ЗАПИСАТЬСЯ в бизнес-аккаунте
Бизнес в Инстаграм – это уже также привычно, как котики и еда когда-то. Теперь главная задача – получить из Инстаграма заказы! Эту задачу упрощает бизнес-аккаунт, который позволяет добавить кнопки «Позвонить» и «Как добраться». Но мало, кто знает, что есть ещё кнопка ЗАПИСАТЬСЯ. Вот о ней-то и поговорим.
Клиенты из Инстаграма
Многие думают, что Инстаграм – это какое-то волшебное место, где отсыпают деньги мешками, а клиенты выстраиваются в очереди. Если вы тоже так думаете, то у меня для вас плохая новость.
Инстаграм сам по себе не приводит вам клиентов. Чтобы получать клиентов из Инстаграма, нужно поработать над своим аккаунтом, контентом, рекламными кампаниями. Это много времени и ресурсов. И к этому нужно быть морально готовым.
Кроме того, для того, чтобы заработали продажи в Инстаграме, у вас должно быть легко купить. Чем проще потенциальному клиенту сделать заказ, тем больше вероятность, что он его сделает, а не соскочет где-то на середине пути.
Кнопка «Записаться» в Инстаграм
Чаще всего в инстаграм-аккаунте можно увидеть кнопки:
Эти кнопки появились первыми, поэтому появление ещё одной кнопки – «Записаться» — мало, кто заметил.
Чтобы добавить эту кнопку в аккаунт, нужно зайти в раздел «Редактировать профиль» и там найти «Способы связи».
В способах связи нам нужна опция «Добавьте кнопку действия». Когда вы на неё нажимаете, Инстаграм выдаёт вам список сервисов, через которые ваши клиенты смогут записываться к вам на приём.
Дальше немного сложно.
Кнопка «Записаться» придумана для тех, кто оказывает услуги: консультанты, тренеры, психологи, мастера маникюра и другие специалисты. Инстаграм позволяет сделать так, чтобы ваши клиенты могли записаться к вам на приём (выбрать удобный день и удобное время) прямо через Инстаграм. Не нужно писать в директ, не нужно звонить, не нужно переходить на сайт. Потыкал в кнопочки в Инсте и всё. Удобная онлайн-запись.
Сложность заключается в том, что запись производится через специальные одобренные Инстаграмом сервисы.
Эти сервисы можно разделить на несколько групп:
Сервисы для бронирования мероприятий и еды нам сразу не подходят. Они все работают в США или Европе.
Большинство оставшихся сервисов платные (с бесплатным тестовым периодом).
Из бесплатных есть 2: Acuity Scheduling и Setmore. На мой взгляд, Setmore симпатичнее и удобнее, но цены он пишет в долларах, поэтому я себе установила кнопку из Acuity Scheduling.
Как добавить кнопку «Записаться»
Чтобы сделать кнопку «Записаться» в инстаграм-аккаунте, нужно зарегистрироваться в выбранном сервисе. В моём случае – в Acuity Scheduling.
После регистрации нужно заполнить свой профиль. Здесь можно прописать ваш рабочий график: дни недели и часы, доступные для записи.
Также нужно добавить описание ваших услуг, на которые может записаться клиент. Если у вас их несколько – добавляйте несколько. Я добавила только скайп-консультацию.
Сервис позволяет подключить и систему оплаты (я не стала этого делать).
Когда вся нужная информация будет заполнена, нужно соединить Acuity Scheduling с инстой. В сервисе генерируется специальная ссылка. Её нужно скопировать, чтобы затем вставить в Инстаграм.
Вот такая будет ссылка:
Чтобы вставить её в Инстаграм, нужно зайти в раздел «Редактировать профиль» — Способы связи – выбрать сервис Acuity Scheduling – нажать «Дальше» — вставить ссылку в поле для ссылки.
Как записаться через Инстаграм
Когда клиент нажмёт на кнопку «Записаться» в вашем аккаунте, он увидит описание ваших услуг и доступные слоты для записи. Они кликабельны. Можно выбрать удобный день и время, нажать и заполнить свои контакты.
После записи и вам, и вашему клиенту на почту придут уведомления. В вашем уведомлении будут контакты клиента. Вы сможете с ним связаться, всё уточнить и подтвердить.
Забронированное кем-то время пропадает из доступных слотов. Дважды на один слот записаться нельзя.
Честно говоря, не могу сказать, что этой кнопкой активно пользуются. У меня она подключена уже пару месяцев и на момент написания статьи не было ни одной заявки клиента по кнопке, только по старинке – через директ, почту и сайт. Но, с другой стороны, я эту опцию никак особенно и не презентовала.
С интересом почитаю про ваш опыт! Пользуетесь ли вы этой кнопкой? Как вам эффект?
И да, если вам нужна консультация по работе с инстаграм-аккаунтом, то записаться ко мне и узнать всё о формате скайп-консультации можно в разделе «Мои услуги».
Scheduling: мифы и реальность. Опыт Яндекса
В последние пару лет я занимаюсь построением различных планировщиков, и мне пришло в голову поделиться своим нелёгким опытом с коллегами. Речь идёт о двух категориях коллег. Первые — это желающие узнать, как разработать свой scheduler за 21 день. Вторые — те, кому нужен новый scheduler совсем без смс и регистрации, просто чтобы работал. Особенно хотелось бы помочь второй категории людей.
Сначала, как водится, стоит сказать несколько общих слов. Что такое scheduler (планировщик, или, для простоты, «шедулер»)? Это такая компонента системы, которая занимается распределением ресурса или ресурсов системы по потребителям. Разделение ресурса может происходить в двух измерениях: в пространстве и времени. Планировщики чаще всего фокусируются на втором измерении. Обычно под ресурсом подразумевают процессор, диск, память и сеть. Но, что греха таить, шедулить можно и любую виртуальную ерунду. Конец общих слов.
Вместе со словом «планировщик» часто мелькают другие слова, вызывающие куда больший интерес публики: изоляция, честность, гарантии, задержки, дедлайны. Встречаются и некоторые словосочетания: quality of service (QoS), real time, temporal protection. Люди, как показывает практика, часто ждут от планировщиков магических сочетаний свойств, которые не могут быть достигнуты одновременно — с шедулером или без него. Если же нужные свойства достигаются, то обычно планировщики всё равно остаются непредсказуемой вещью в себе и во время их эксплуатации список вопросов только увеличивается. Я попытаюсь приоткрыть завесу тайны их поведения. Но обо всем по порядку.
Миф №1. Что тут сложного?
Чтобы объяснить и предсказать поведение систем, где есть шедулер, люди написали очень много книг, а также разработали целую теорию — и даже не одну. Как минимум стоит упомянуть scheduling theory (теорию расписаний) и queueing theory (неожиданно: в русском варианте это теория массового обслуживания). Все подобные теории довольно сложные и, если честно, просто необозримые. Одних формулировок задач планирования существует целый зоопарк со специальной классификацией. Дело не облегчается тем, что про бóльшую часть задач известно, что они NP-полные или NP-трудные. Даже в удачных случаях, когда есть полиномиальный алгоритм поиска оптимального решения или его неплохое приближение, частенько выясняется: для онлайн-версии задачи (когда заранее неизвестно, какие запросы нужно шедулить или когда они появятся) оптимального алгоритма вообще не существует и надо быть оракулом, чтобы отшедулить всё «как надо». Тем не менее, дела обстоят не так плохо, как может показаться. Человечество уже очень много знает о шедулерах, а некоторые из них даже работают.
Миф №2. Шедулеры решают все проблемы
Отличная иллюстрация непредсказуемого поведения системы с шедулером — сегодняшний интернет. Это система с множеством шедулеров и абсолютным отсутствием гарантий по полосе и задержке, отсутствием изоляции и подобием справедливости в формате протокола TCP — который, кстати, даже сейчас, спустя десятилетия, изучают и улучшают, и такие улучшения могут давать значимые результаты.
Вспомним TCP BBR от Google. Авторы неожиданно говорят, что создать TCP BBR было невозможно без последних достижений в теории управления, основа которых — нестандартная max-plus-алгебра. Вот, оказывается, куда ушло 30 с лишним лет.
Но это же всё не про шедулер, скажете вы, а про flow control. И будете абсолютно правы. Дело в том, что они очень сильно связаны. В обычных системах шедулеры ставят перед некоторым узким местом — ограниченным ресурсом. Логично: ресурс в дефиците и вроде бы его надо делить справедливо. Допустим, у вас есть такой ресурс — дорожная сеть города — и вы хотите сделать для него шедулер (условно, на выезде из гаража), чтобы уменьшить среднее время в пути. Так вот, оказывается, что среднее время в пути легко вычислить, применив теорему Литтла: оно равно отношению количества машин в системе к скорости их поступления в систему. Если уменьшить делимое, то при прежней пропускной способности время в пути падает. Получается, чтобы не было пробок, надо попросту сделать так, чтобы машин на дорогах стало меньше (ваш капитан). Шедулер с такой задачей не поможет, если нет flow control. В интернете описанную проблему называют bufferbloat.
Если бы я писал свод правил «шедулеростроения», то первое правило было бы таким: контролируй очереди, возникающие за шедулером. Самый часто встречающийся мне способ контролировать размер очереди — MaxInFlight (его продвинутая версия называется MaxInFlightBytes). С ним есть проблема: дело в том, что невозможно правильно выбрать число. Выбор любого фиксированного числа будет гарантировать вам либо неполное использование полосы (1), либо излишнюю буферизацию (2) и, как следствие, увеличение среднего latency, либо, если вам очень повезёт, таймауты и потерю полосы.
Хороший flow control должен удерживать систему в точке Кляйнрока между режимами (1) и (2), максимизируя отношение throughput/latency (см. TCP BBR).
Миф №3. Справедливость нужна для изоляции
Есть две классические области применения справедливого планирования — сеть и процессор. GPS — не система позиционирования, а идеальный шедулер, одновременно обслуживающий всех своих пользователей бесконечно малыми порциями. Такой шедулер обеспечивает справедливость max-min. Настоящие шедулеры (WFQ, DRR, SFQ, SCFQ, WF2Q) обслуживают потребителей порциями конечного размера — пакетами, если мы говорим про сеть, или квантами времени, если про процессор. Эти шедулеры разрабатывают так, чтобы их поведение было максимально приближено к идеальному и чтобы они минимизировали лаг — разницу в объёме обслуживания, полученного разными пользователями. Затем для управления выделенной полосой разработчик вводит веса пользователей и начинает говорить, будто они находятся в изолированных системах с меньшей пропускной способностью. Здесь-то и кроется обман. На самом деле изоляции нет.
Пусть у нас есть процессор, который мы хотим потенциально разделять между ста пользователями. Допустим, Витя — хороший пользователь. Он отправляет на обслуживание задачи, которые выполняются за 10 мс, и готов подождать 1 с, потому что понимает: есть еще 99 пользователей. Однако другие могут отправлять задачи, которые иногда выполняются до 1 с. Предположим, что preemption невозможен. Тогда Вите в худшем случае придётся ждать 99 с. Витя, скорее всего, захочет выйти из подобной системы.
Так неинтересно, скажете вы. Что за система такая — без preemption? Система должна уметь обижать, и будет ей счастье. Хорошо, пусть при времени выполнения запроса более 10 мс мы будем включать preemption, передавать управление следующему запросу и вообще использовать лучший из известных науке справедливых шедулеров. Увидит ли Витя ответ за 1 с, как будто он в изоляции? 10 мс (текущий запрос в обслуживании) + 99*10 мс (запросы других пользователей) + 10 мс (Витин запрос) = 1010 мс. Это максимум времени ожидания — другими словами, в такой системе дела обстоят получше.
Витя говорит — отличная система! — и отправляет запрос на 1 мс. А он опять выполняется за 1 с (в худшем случае). В идеально изолированной системе такой запрос выполнился бы за 100 мс, а здесь получилось в 10 раз хуже. Мало того, что от этой секунды никуда ни деться, так ещё и в реальной системе обязательно встретятся другие проблемы:
Миф №4. Справедливость нужна, чтобы разделить полосу в соответствии с весом
Получается, справедливость не обеспечивает настоящую изоляцию, зато хорошо делит полосу. Но не тут-то было. Справедливость в таких классических шедулерах мгновенная. Это означает, что, не прислав запрос, когда придёт ваша очередь, вы не получите ресурс, и он будет разделён между остальными желающими. По прошествии длительного промежутка времени (например, 24 часов) может оказаться, что ресурс съелся совсем не в той пропорции, в которой веса были заданы потребителям. В худшем случае потребители могут приходить в любых пропорциях только в те моменты, когда нет других потребителей. В результате веса и потреблённый ресурс могут оказаться вообще никак не связаны. Это шутка, скажете вы, — так никогда не бывает. Но пусть у нас есть распределённая система со своим шедулером на каждой машине. Запросы двух пользователей приходят на две разные машины и никогда не конкурируют за ресурс, потому что на самом деле здесь два ресурса.
Если вы хотите увидеть на графиках ровные линии для агрегированного потока, стоит использовать историческую (long-term) справедливость или квотирование. Но вначале спросите себя, зачем вам это надо.
Миф №5. Выдели мне узенький канал для приоритетного трафика
Предположим, у вас есть справедливый шедулер с весами и вы хотите выделить 0,1% полосы для какого-нибудь служебного трафика, а оставшиеся 99,9% — для остального. В итоге вы получите максимальную задержку x1000. Такой феномен называется bandwidth-latency coupling. Он является прямым следствием из предыдущего рассуждения. Максимальное время задержки обратно пропорционально ширине выделенной полосы. Значит, для приоритетного трафика нужны другие механизмы.
Миф №6. Я загрузил систему на полную и начал мерить задержку
Теорема. В любой системе, загруженной больше чем на 100%, задержка ответов не ограничена сверху никаким числом. Доказательство, я надеюсь, очевидно. Очереди будут копиться, пока что-то не лопнет. Как неправильно измерять и сравнивать временны́е характеристики систем (в том числе с шедулером), рассказывает Гил Тене (можно посмотреть или почитать). Я оставлю тут только иллюстрацию:
Миф №7. Real-time scheduler может гарантировать выполнение моих дедлайнов
Если вам больше не нужен справедливый шедулер, вам, возможно, нужен шедулер, который используется в системах реального времени. Уж там-то всё наверняка хорошо и быстро. Помимо прочего, корректность работы системы реального времени зависит от выполнения задач в заданные сроки. Однако это вовсе не значит, что всё происходит быстро. Например, сроки и задачи бывают вида «сделать и внедрить новый шедулер до начала весеннего ревью». Более того — среднее время ответа в таких системах может быть очень близким к худшему случаю.
Отличительная черта RT-систем: они заранее проверяют расписание на осуществимость. «Осуществимость» здесь означает возможность соблюдения дедлайнов всех задач, а «заранее» — это, скажем, при сборке, при конфигурации системы или при запуске в ней новой задачи. Далее, есть простой способ соблюдать все дедлайны в системе, где это принципиально возможно. Речь идёт про real-time-шедулер. Например, доказано, что алгоритмы EDF (Earliest Deadline First) являются оптимальными для одного процессора. Оптимальность означает, что если для данного набора задач существует хоть какое-то выполнимое расписание, то EDF выполнит задачи до дедлайнов.
Но есть условия, при которых стройная картина мира рушится и система перестаёт укладываться в дедлайны.
Миф №8. Систему нельзя загрузить больше чем на 100%
Для определения загрузки (load factor) в RT-системах используется простая периодическая модель следующего вида. Есть задачи, которые поступают раз в Ti мс и требуют эксклюзивного владения ресурсом в течение Ci мс в худшем случае. Тогда load factor определяется как запрошеное время ресурса на одну секунду реального времени, то есть U = C1/T1 +… + Cn/Tn. В такой простой модели всё понятно, но как подсчитать load factor, если у нас нет никаких периодов, а есть только текущие задачи и их дедлайны?
Тогда load factor определяется иначе. Текущие задачи сортируются по дедлайнам. Далее, начав с одного запроса с наименьшим дедлайном во множестве M, проходим по всем запросам и добавляем их в это множество. М на каждом шаге содержит запросы, которые должны быть полностью выполнены к определённому моменту времени t. Делим их суммарную остаточную стоимость (если вдруг мы уже частично выполнили какие-то из них) на оставшееся время t – now. Полученная величина — load factor U множества M. Чтобы получить текущий load factor, остаётся найти максимум из всех полученных U. Найденная величина, как несложно догадаться, сильно меняется во времени и легко может оказаться больше 1. Расписание невыполнимо c помощью EDF тогда и только тогда, когда load factor > 1.
Если вам важно соблюдать дедлайны, то в качестве метрики, за которой стоит следить, нужно использовать описанный load factor, а не традиционную утилизацию (долю времени, когда система находилась в занятом состоянии).