вторник, 23 марта 2010 г.

Разработка веб-приложений с помощью PNaCl

Проект Google по ускорению разработки веб-приложений Native Client вступил в новую фазу развития. Современные браузеры оснащаются достаточно мощными движками, которые позволяют быстро выполнять программы, написанные на JavaScript, однако перевод этих программ на нативный язык компьютера является трудоемким процессом и значительно замедляет процесс исполнения приложения. Native Client является «мостом» между этими мирами, позволяя коду, полученному из веб выполняться максимально быстро.

Полтора года назад, когда Google анонсировал Native Client, проект мог выполнять только 32-битные программы на процессорах x86. В среду Google анонсировал завершение внедрения новой версии Native Client с поддержкой 64-бит для процессоров x86 и ARM. Эта задача была весьма трудной к техническому исполнению, однако сулит значительный прогресс, так как эти процессоры установлена на большинстве современных компьютеров и смартфонов.

Более того, компания огласила планы по развитию нового, портативного клиента PNaCl (Portable Native Client), который наиболее полно соответствует философии Java, сформулированной Sun Microsystems в выражении «написать раз, исполнять везде». Таким образом, вместо разработки различных модулей Native Client для каждого вида процессора, разработчики могут работать над единственным модулем PNaCl.

TVroid (aka TV-android)

Чем интересна политика Google - так это разноплановостью (хотя и напоминает "хочу таблеток от жадности, да побольше!"). В частности перспективные разработки, куда компания вкладывается - радуют воображение.
Недавно Google заключил партнерство с Intel и Sony с целью создания совместного "продукта", суть которого придать телевидению больше интерактивности. Сама идея интерактивного ТВ очень и очень не нова, а вот способы реализации у всех разные. Google планирует разработать и представлять свою ТВ-платформу по такой же модели как и Android для мобильного рынка – в течение нескольких месяцев он откроет платформу для разработчиков, а первые версии готового продукта поступят в продажу этим летом. Фактически, можно уже ожидать в скором времени появления специальных приложений для TV от сторонних разработчиков.

понедельник, 15 марта 2010 г.

Листья падают...


В эпоху моего детства отрывной календарь являлся неотъемлемым атрибутом практически любого дома. И по его тематике, дизайну, а главное, состоянию - можно было судить о хозяине дома. Рассеянный или нет, аккуратист или пофигист. Элегантную штучку придумали в Дюссельдорфе (Euro RSCG of Duesseldorf, Germany) - календарь, с автоматическим "отстрелом" дней. Причем, дни календаря выполнены в стиле листьев.

Вертикальная архитектура микрочипов


В 1965 году один из основателей компании Intel, Гордон Мур предсказал, что количество транзисторов на кремниевой подложке будет удваиваться каждые два года, что повлечет удвоение производительности и снижение вдвое рыночной стоимости.В настоящий момент мы наблюдаем технологический "стопор" с пределом в 30-20нм.
Компания IBM и Швейцарский Федеральный Институт Технологий предлагают 3х мерную концепцию: не уплотнение кристаллов, а построение вертикальной архитектуры микрочипов.

пятница, 12 марта 2010 г.

6 ядер - это не 2 и даже не 4



Наконец очередной количественный прорыв в компьютерном железе - архитектура от 4х ядер перешла к 6.

Корпорация Intel представила свой первый шестиядерный процессор для ПК. Процессор Intel Core i7 980X Extreme Edition был показан на конференции Game Developers Conference 2010, сообщается в пресс-релизе компании. Новый чип будет, в первую очередь, ориентирован на геймеров.

Процессор стал первым в линейке чипов новой платформы, известной под кодовым названием Gulftown. Он обладает тактовой частотой 3,3 гигагерца и способен одновременно обрабатывать 12 задач благодаря технологии Hyper-Threading, пишет Сomputerworld. Чип Core i7 980X построен с использованием 32-нанометрового техпроцесса. Intel не разгласила стоимость новых процессоров и не сообщила дату начала продаж.


Добавив видеокарту двумя чипами Fermi - новое поколение платформы CUDA (планируемый выпуск NVidia опять затягивается) - и получим вполне достойный игровой "монстр" :) Цены первые месяцы будут естественно запредельными.

суббота, 6 марта 2010 г.

Xen Summit North America 2010

Сообщество XEN Community проводит встречу 28-29 апреля 2010 в калифорнии. На повестке дня новости проекта, релиз ПО, опыт внедрения виртуаплизации в ИТ и архитектура.
На данный момент самым интересным является проект Xen Cloud Platform, предоставляющий решения для провайдеров и крупных компаний: сочетание собственных разработок Xen Hypervisor и недавно опубликованного открытого стандарта Citrix XAPI (Citrix Project Kensho).
Текущий релиз платформы Xen Cloud включает:
* Latest Xen 3.4.1
* Linux 2.6.27 Kernel
* Windows PV Drivers, Microsoft Certified
* XAPI Enterprise-class Management Tool Stack
o VM Lifecycle: Live snapshots, checkpoint, migration
o Resource Pools: Safe live relocation, auto configuration, DR
o Host Configuration: Flexible storage management, networking, power management
o Event Tracking: Progress, notification
o Secure Communication using SSL
o Upgrade and Patching Capabilities
o Real-time Performance Monitoring and Alerting
* Basic SR-IOV Support
* CDROM and Network Host Installer
* Full Featured "xe" CLI and web services API

среда, 3 марта 2010 г.

Виртуализация на базе кластера (xen)

На Хабре обнаружил интересный пост – просьбу о помощи какую платформу для виртуализации выбрать. Проблема на самом деле для многих очень актуальна – виртуализация облегчает жизнь во многих сферах бизнеса как ИТ службам и разработчикам, так и конечным пользователям. В бытность своей работы над стартап-проектом по разработке ПО эта проблема возникала не один раз – ЧТО выбрать и КАК реализовать.


Одним из очень изящных решений - создание кластера высокой доступности на платформе XEN с возможностью миграции и использованием VLAN, DRBD, Heartbeat (статья Андрея Зентавр на OpenNet).


Cсылки по теме:


1. XEN Cluster HowTo


2. MySQL + DRBD/Heartbeat

GoGrid – гибридный хостинг

Хостинг-провайдер GoGrid предлагает для бизнеса любопытнейшие решения – гибридный хостинг: сочетает в себе масштабируемость/доступность облаков и удобство выделенных серверов.


Гибридный хостинг

Гибридный хостинг


Идея состоит в создании защищенной частной сети – связь (от 100Мбс) выделенных серверов и вычислительного облака. При этом сохраняется масштабируемость, присущая облаку и мощь/доступность выделенных серверов.


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


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

nginx (engine x) – отказоустойчивый HTTP сервер

nginx (engine x) — веб-сервер и почтовый прокси-сервер, работающий на Unix-подобных операционных системах (тестировалась сборка и работа на FreeBSD, OpenBSD, Linux, Solaris, Mac OS X).


http://sysoev.ru/nginx/


http://ru.wikipedia.org/wiki/Nginx


Основная функциональность HTTP-сервера:



Популярность


По данным Netcraft за декабрь 2009 года, число сайтов, обслуживаемых nginx, превышает 15,5 миллионов [2], что делает его третьим по популярности веб-сервером в мире.


Как и lighttpd nginx часто используют для отдачи статического содержимого, генерируемого «тяжёлым» веб-приложением, работающим под управлением другого веб-сервера.


Следующие проекты используют nginx:



Почему Apache — плохо?


(http://greenmice.info/ru/node/115,  http://greenmice.info/ru/node/116)


Для начала нужно объяснить, как вообще работают сетевые серверы. Те, кто знаком с сетевым программированием, знают, что по сути существуют три модели работы сервера:



  1. Последовательная. Сервер открывает слушающий сокет и ждет, когда появится соединение (во время ожидания он находится в заблокированном состоянии). Когда приходит соединение, сервер обрабатывает его в том же контексте, закрывает соединение и снова ждет соединения. Очевидно, это далеко не самый лучший способ, особенно когда работа с клиентом ведется достаточно долго и подключений много. Кроме того, у последовательной модели есть еще много недостатков (например, невозможность использования нескольких процессоров), и в реальных условиях она практически не используется.

  2. Многопроцессная (многопоточная). Сервер открывает слушающий сокет. Когда приходит соединение, он принимает его, после чего создает (или берет из пула заранее созданных) новый процесс или поток, который может сколь угодно долго работать с соединением, а по окончании работы завершиться или вернуться в пул. Главный поток тем временем готов принять новое соединение. Это наиболее популярная модель, потому что она относительно просто реализуется, позволяет выполнять сложные и долгие вычисления для каждого клиента и использовать все доступные процессоры. Пример ее использования — Web-сервер Apache. Однако у этого подхода есть и недостатки: при большом количестве одновременных подключений создается очень много потоков (или, что еще хуже, процессов), и операционная система тратит много ресурсов на переключения контекста. Особенно плохо, когда клиенты очень медленно принимают контент. Получаются сотни потоков или процессов, занятых только отправкой данных медленным клиентам, что создает дополнительную нагрузку на планировщик ОС, увеличивает число прерываний и потребляет достаточно много памяти.

  3. Неблокируемые сокеты/конечный автомат. Сервер работает в рамках одного потока, но использует неблокируемые сокеты и механизм поллинга. Т.е. сервер на каждой итерации бесконечного цикла выбирает из всех сокетов тот, что готов для приема/отправки данных с помощью вызова select(). После того, как сокет выбран, сервер отправляет на него данные или читает их, но не ждет подтверждения, а переходит в начальное состояние и ждет события на другом сокете или же обрабатывает следующий, в котором событие произошло во время обработки предыдущего. Данная модель очень эффективно использует процессор и память, но достаточно сложна в реализации. Кроме того, в рамках этой модели обработка события на сокете должна происходить очень быстро — иначе в очереди будет скапливаться много событий, и в конце концов она переполнится. Именно по такой модели работает nginx. Кроме того, он позволяет запускать несколько рабочих процессов (так называемых workers), т.е. может использовать несколько процессоров.


Итак, представим следующую ситуацию: на HTTP-сервер с каналом в 1 Гбит/с подключается 200 клиентов с каналом по 256 Кбит/с:


Что происходит в случае Apache? Создается 200 потоков/процессов, которые относительно быстро генерируют контент (это могут быть как динамические страницы, так и статические файлы, читаемые с диска), но медленно отдают его клиентам. Операционная система вынуждена справляться с кучей потоков и блокировок ввода/вывода.

Nginx в такой ситуации затрачивает на каждый коннект на порядок меньше ресурсов ОС и памяти. Однако тут выявляется ограничение сетевой модели nginx: он не может генерировать динамический контент внутри себя, т.к. это приведет к блокировкам внутри nginx. Естественно, решение есть: nginx умеет проксировать такие запросы (на генерирование контента) на любой другой веб-сервер (например, все тот же Apache) или на FastCGI-сервер.


Рассмотрим механизм работы связки nginx в качестве «главного» сервера и Apache в качестве сервера для генерации динамического контента:


Nginx принимает соединение от клиента и читает от него весь запрос. Тут следует отметить, что пока nginx не прочитал весь запрос, он не отдает его на «обработку». Из-за этого обычно «ломаются» практически все индикаторы прогресса закачки файлов — впрочем, существует возможность починить их с помощью стороннего модуля upload_progress (это потребует модификации приложения).

После того, как nginx прочитал весь ответ, он открывает соединение к Apache. Последний выполняет свою работу (генерирует динамический контент), после чего отдает свой ответ nginx, который его буферизует в памяти или временном файле. Тем временем, Apache освобождает ресурсы.

Далее nginx медленно отдает контент клиенту, тратя при этом на порядки меньше ресурсов, чем Apache.


Такая схема называется фронтэнд + бэкенд (frontend + backend) и применяется очень часто.