Интернет пришел в Россию в 1995-96 годах.
Средний компьютер тогда представлял собой AMD 486DX150 или Intel Pentium100 с 4–8 МБ ОЗУ и 100–400 МБ жесткого диска.
Как раз тогда появилась Windows 95, и именно новая ОС требовала апгрейда железа до заданных значений, т.к.
на типичных компьютерах 1994 года 486 SX25 или DX66 с 2-4 Мб Win95 еле двигались.
Интернет-серверы и роутеры от провайдеров в те годы были точно такими же машинами, а то и более слабыми, потому что.
Linux тогда еще вполне комфортно чувствовал себя на 2 МБ (без GUI), сайты были в основном статичными, а почтового спама еще не было.
.
Доступ в Интернет имел в лучшем случае один на тысячу человек — несколько сотен человек в среднестатистическом российском райцентре, и все они работали через почтовые и веб-серверы одного провайдера.
То есть один сервер указанной незначительной по современным меркам конфигурации обслуживал примерно столько людей, сколько сейчас пользователей Интернета на достаточно крупном предприятии.
И мне удалось.
Существуют ли сейчас компьютеры сопоставимой мощности (если слово мощность еще применимо к такому оборудованию) и как они используются? Есть.
Нет, это не роутеры и уж тем более не смартфоны — оба заметно производительнее, даже если рассматривать только домашние роутеры и самые простые телефоны.
Роутеры запросто качают 100Мбит/с, а телефоны запросто транслируют видео, а телефоны имеют сотни мегабайт памяти - ничего подобного в 1996 году и близко не было.
Надо искать более слабые процессоры, сравнимые с Pentium100, то есть около 100 МГц или до 200 ДМИПС.
Ближайшим кандидатом для сравнения является микроконтроллер ARM Cortex-M3 или -M4. У первого частота чуть меньше 100 МГц, у второго чуть больше, заявленная производительность 125-210 DMIPS (2,19 CoreMark/МГц - 1,25 DMIPS/МГц - как у Pentium 96m).
Объем встроенной SRAM контроллера составляет всего около 100 Кб, но к контроллеру можно подключить мегабайты внешней SDRAM, работающей точно на той же частоте, что и первые Pentium. В сумме мы получим примерный эквивалент материнской платы тех лет, но размер всей платы будет меньше сокета Pentium, а энергопотребление на порядок меньше тогдашнего (всего 10 Ватт!) Пентиумы.
Как и что мы будем сравнивать, а главное почему.
Мы будем измерять производительность Cortex-M3 на нетипичных сетевых задачах.
Многие Cortex-M3 имеют контроллеры Ethernet, а версии TI даже имеют встроенный PHY (т.е.
не требует никаких внешних чипов, подключается напрямую к RJ45 MagJack), но считается, что это следует использовать либо для промышленной автоматизации - отправлять команды управления/мониторинга по сети, или в быту - сетевые счетчики потребления коммунальных услуг, управление умным домом и т. д., т.е.
задачи важные, но «совсем из другой истории».
Но поскольку по ожидаемой производительности он соответствует серверам, которые в прошлом «обслуживали» целые города, то, может быть, не стоит ограничиваться этой традиционной нишей и имеет смысл оценить применимость контроллера для серверных задач? Не в масштабах Интернета, а для локальной сети.
В то время, когда космические корабли бороздят Вселенную, а ИТ-отделы предприятий передают свои внутренние задачи внешним облакам, задача предоставления реальной сетевой услуги машине, которая в сотни или тысячи раз медленнее, чем типичный офисный ПК, может показаться бессмысленной.
Но с другой стороны, если контроллер (вдруг) справится с задачей, то не делает ли это аппаратную «гонку вооружений» бессмысленной в решении именно этой задачи? И не в этом ли в конечном итоге состоит наша инженерная работа – повышении операционной эффективности, в т.ч.
и за счет снижения издержек производства? Таким образом, либо (1) за те же деньги делается больше работы, либо (2) делается тот же объем работы, но за меньшие деньги.
Границы наших возможностей мы узнаем при втором варианте.
Теперь о выборе тестового задания.
Есть одна ИТ-задача, в которой объём операций постоянен во времени, поскольку ограничен не возможностями технологии, а производительностью самого медленного участника технических процессов — человека.
Более того, в этом случае выключить это слабое звено из процесса не получится, к сожалению (или к счастью), потому что этот процесс самый человечный – процесс принятия решений! — его человек предпочитает пока не доверять это технике, потому что техника с такими возможностями может решить, что человек не нужен.
В чем суть процесса: человек анализирует текущую ситуацию (на основе доступной ему информации ) и решает, что делать дальше, фиксируя это решение либо в прямых физических действиях, либо в изменении внутреннего состояния («Теперь я знаю, что делать» или «Я подумаю об этом завтра.
»).
Если не считать мелких автоматических решений, принимаемых на автопилоте — куда поставить ногу или из какого кармана достать телефон, — а только сознательных решений, требующих фиксации внимания, то «тактовая частота» человека составляет не более 200- 300 решений в день.
Если человеку приходится синхронизировать все свои решения с другими людьми, т.е.
совместно одновременно решать общие проблемы, то индивидуальная продуктивность падает на порядок – проводить больше 20 совещаний в день вряд ли получится, а ведь время на это все равно нужно.
готовить информацию и реализовывать решения (лично или поручив кому-то другому, что также требует синхронизации).
Компьютерные системы групповой работы (GWS) предназначены для повышения эффективности совместной работы, и сделать это они могут только за счет превращения синхронных событий в асинхронные, устранение блокировок и ожидания между людьми: после решения/выполнения очередной задачи человек должен сразу получить от GWS полную информацию для принятия следующего решения.
В этом случае GWS работает как планировщик задач в операционной системе, а люди работают как кассиры в супермаркетах — каждый делает свою работу на пределе своих возможностей (если есть очередь клиентов, т.е.
«заданий»), работая только своей очередью, не отвлекаясь на взаимодействие с коллегами (любое такое взаимодействие типа звонка соседней кассе «Лена, смени 5 тысяч» сразу заметно останавливает две очереди сразу), коллеги должны работать асинхронно — обеспечивать запасы мелочи, наличных регистрируйте ленты, товары на полках, покупателей в зале и т. д. Таким образом, в GWS можно оценить необходимую максимальную производительность системы: 200 умножить на количество пользователей системы.
На практике, конечно, такие параметры потребуются только в очень хорошо развитых организационных процессах.
Типичным для небольшого офиса или предприятия (до 100 человек) будет более 200-300 решений в день для каждого, тем более, что не все события отражаются в GWS. Предположим, что несколько тысяч в день покрывают (с запасом) все текущие потребности типичного офиса — практически для любой отрасли и вне зависимости от развития технологий вокруг.
Если вы еще здесь, давайте начнем переводить это на компьютерный язык.
Что такое событие или задача в GWS? Сообщение электронной почты, событие в календаре, задача в трекере, заявка/счет на сайте и т. д. В большинстве случаев размер такого файла или записи в базе данных варьируется от единиц до десятков КБ.
Я посчитал средний размер задач в наших календарях (ICS-файлы формата VCALENDAR с задачами VTODO или событиями VEVENT внутри) за несколько лет — 700 байт. Сообщение на форуме - полтора Кб.
Внутренняя вики-страница - 4 КБ.
Письмо в техподдержку занимает 12 КБ (часто с прикрепленными файлами, т.е.
средний размер реального текста значительно меньше).
При таких размерах мы можем оценить объем новой информации для одного сотрудника в 1 МБ в день и не более 50 МБ в день для всего офиса (с учетом того, что многие элементы GWS адресованы нескольким получателям).
Если объемы выше, то значительная часть задач так и не будет выполнена – их просто физически не успеют обработать – они будут удалены без прочтения или зависнут навсегда (или автоматически закроются/архивируются «просроченными», ", что то же самое).
При таких объемах информации сервер GWS на базе современного ПК может кэшировать задачи в оперативной памяти в течение нескольких месяцев, может «загружать» все задачи одного сотрудника в день менее чем за одну секунду, хранить все задачи всего офиса на протяжении нескольких месяцев.
несколько лет в онлайн-доступе на диске и т. д. Понятно, что в зависимости от форматов баз данных, используемых протоколов, используемого серверного и клиентского ПО эти параметры могут сильно различаться, различаться на порядок, но ясно и то, что мощности обычного ПК для этих задач хватает с огромным запасом.
Это означает, что вы можете попытаться выполнить ту же задачу на менее мощном оборудовании.
Производительность сервера при столь малых объемах и использовании кэширования можно считать неограниченной в случае ПК, а для контроллера цифры такие: Cortex-M3 на частоте 80 МГц копирует память SDRAM со скоростью 16 МБ/с ( используя процессор, без использования DMA), отправляет данные TCP/IP через встроенный Ethernet-контроллер 100 Мбит со скоростью 4-5 МБ/с (также без использования DMA, т.е.
есть резервы оптимизации).
Получается, что в идеале контроллер синхронизирует все календари за считанные минуты, а отдельному пользователю это можно сделать всего за секунду.
Но на практике обычно все очень далеко от идеала, в зависимости от протоколов и сценария работы.
Предположим, что для работы с событиями/задачами пользователи используют клиенты календарей с протоколами WebDAV/CalDAV (Outlook, Evolution, SunBird, Thunderbird+Lightning и т. д. на настольных ПК, iCAL на iPhone/iPad и т. д.), а сервер — соответственно, это любой веб-сервер, поддерживающий эти протоколы.
Но мы будем тестировать не производительность клиентского ПО (понятно, что его достаточно на современных ПК), и не производительность конкретных моделей GWS (понятно, что они тормозят в широких пределах), а соотношение сильные стороны контроллера и ПК в сети работают над задачей такого типа.
При синхронизации календарей клиентское ПО использует несколько команд HTTP/WebDAV — OPTIONS, PROPFIND, GET, PUT — проводя большую часть времени в команде PROPFIND, которая выбирает из списка событий на сервере подмножество, соответствующее заданным критериям.
Принцип примерно тот же, что и при приеме почты — узнает «что нового» и скачивает новое, плюс (в отличие от почты, но аналогично, например, новостям NNTP) узнает, чего нет на сервере и передает это с помощью команды PUT. Для простоты на первом этапе мы будем тестировать только GET с помощью программы ApacheBench. Давайте запустим множество параллельных отдельных коротких соединений с помощью одиночных GET-запросов, имитируя неоптимальные клиенты, получающие по одной задаче за раз.
Давайте запустим длинные соединения с несколькими GET в режиме Keep-Alive, имитируя PROPFIND с multiget внутри.
И в каждом тесте мы будем получать несколько сотен коротких файлов, имитирующих сеансы синхронизации отдельных пользователей, получающих все задания за один или несколько дней.
Железо.
Мы будем сравнивать офисный ПК на экономичном процессоре AMD E350 (по энергопотреблению приближается к первым Пентиумам или современным Атомам, а производительность на два порядка выше, чем у первых Пентиумов и заметно выше, чем у Атомов) с 4 ГБ оперативной памяти и HonixBox размером 6x6 см с ARM Cortex-M3 (TI LM3S9B95) и 8 МБ оперативной памяти внутри.
Они подключены к одному и тому же 100Мбитному свитчу в одном офисе и отделены еще двумя свитчами (гигабитными) от компьютера в том же офисе, на котором работает ab, имитирующий клиентов.
Программное обеспечение На ПК установлена 64-разрядная бета-версия Windows 8 в качестве сервера nginx/1.0.14 (текущая стабильная сборка) для Windows. На HonixBox — самодельный веб-сервер на самодельной ОС, скомпилированный самодельным компилятором (специальной оптимизации под эту задачу нет — сервер написан для выдачи сетевой статистики, основной «профессии» HonixBox; около 500 байт кода написано на ассемблер для всей системы, все остальное написано на Форте без какой-либо оптимизации, так как исходная задача HonixBox была предельно простой, поэтому она была реализована на контроллере).
Мы тестируем.
Сначала я хотел запросить "/" на HonixBox (небольшой скрипт, который отображает страницу с текущими настройками HonixBox и сводной статистикой), и запустить PhpInfo() на nginx, но PHP под Windows в режиме FastCGI не доживает до 500 запросы под управлением nginx — вылетает. Я пока не стал разбираться (первый раз в жизни запускал nginx), перешёл на статические файлы, тем более что календари для WebDAV — это наборы статических файлов.
аб -н 500 -с 100 192.168.0.156/favicon.ico (единственный файл на HonixBox, близкий по размеру к VTODO; а на nginx мы запрашиваем более короткий index.html) — моделируем получение 500 отдельных задач сотнями клиентов одновременно.
Результат nginx: Время, затраченное на тесты: 1,994990 секунды.
Полных запросов: 500 Неудачных запросов: 0 Ошибки записи: 0 Всего передано: 181000 байт. Переданный HTML: 75500 байт Запросов в секунду: 250,63 [#/сек] (среднее) Время на запрос: 398,998 [мс] (среднее) Время на запрос: 3,990 [мс] (в среднем по всем одновременным запросам) Скорость передачи: получено 88,22 [Кбайт/сек] Результат HonixBox: Время, затраченное на тесты: 10,466127 секунды.
Полных запросов: 500 Неудачных запросов: 0 Ошибки записи: 0 Всего передано: 211500 байт. Передано HTML: 159 000 байт. Запросов в секунду: 47,77 [#/сек] (среднее) Время на запрос: 2093,225 [мс] (среднее) Время на запрос: 20,932 [мс] (в среднем по всем одновременным запросам) Скорость передачи: получено 19,68 [Кбайт/сек] Пятикратный Превосходство ПК над контроллером.
Обратите внимание на низкую конечную скорость передачи в обоих случаях — всего 20-90 Кб/с.
Скорее всего, скорость ограничена в основном задержками при установлении/разрыве множества TCP-соединений (стороны ждут подтверждения друг от друга).
А вот количество запросов в секунду вполне соответствует типичной скорости синхронизации календарей или получения электронной почты.
Мы удаляем -с , добавлять -к (Keep-Alive) — Nginx ускоряется до 259 запросов в секунду, HonixBox до 52, т.е.
однопоточный вариант (один клиент получает 500 задач за 2с с Nginx и за 10с с HonixBox).
Добавляем -c 10 (10 клиентов одновременно получают по 50 задач) - Nginx разгоняется до 424 fps, а HonixBox остается на 52, проигрывая на этот раз восемь раз .
Результаты оказались хуже, чем я ожидал — даже закрались подозрения, что с ApacheBench на Windows что-то не так — но итоговое соотношение сил ПК и контроллера, вероятно, не зависит от «ab».
И это показывает, что ограничивающим фактором является не скорость процессора, а сеть (хотя скорость FTP между этими двумя машинами составляет 11 МБ/с — в 100 раз быстрее, чем типичная скорость в приведенных выше тестах) и даже в большей степени схема работы.
— множество мелких объектов, полученных по отдельным HTTP-запросам.
Ну и самое главное, что разница в скорострельности ПК-сервера и серверного контроллера всего в 5-8 раз, а не минимум в 50 раз, как можно было бы ожидать, и при этом программное обеспечение на контроллере еще есть неиспользованное пространство для оптимизации, а на ПК огромный запас неиспользованной мощности — Nginx в этом тесте напрягаться не пришлось, он в основном ждал ввода-вывода.
Но даже в текущей версии оба сервера предоставляют данные ровно с той же скоростью (или даже ниже), которая обычно наблюдается при работе, например, в Lightning с реальным сервером WebDAV. Те.
пользователь вряд ли заметит разницу.
Еще интереснее будет сравнить ПК и контроллер в реальной работе в режиме Groupware. Сделаем это в следующий раз, если кому-то кроме меня это тоже интересно.
Теги: #Nginx #контроллеры #groupware #httpd #cortex-m3
-
Защита Конфиденциальности Через Интернет
19 Oct, 24 -
Эвфемизм
19 Oct, 24 -
3D-Анализ
19 Oct, 24 -
Нигма Расшифрует Аббревиатуры
19 Oct, 24 -
История Упаковки Windows
19 Oct, 24
