Высокая производительность *

Год назад Ян Кларк, известный как создатель распределённой сети Freenet, выступил с ещё одной революционной инициативой. Он предложил создать новый язык программирования для распределённых вычислений, логика которого будет идти «не от данных, а от вычислений», чтобы любые написанные на таком языке программы можно было естественном образом распараллеливать по неограниченному количеству процессоров и серверов. Это очень важная задача, если учитывать повсеместный переход на распределённые вычисления. И до сих пор нет нормального фреймворка для создания распределённых программ.

Як Кларк сделал на базе Scala 2.8 первый прототип языка Swarm. Вот исходные коды и инструкция по установке.

Здравствуй, уважаемое хабра-сообщество.

Многие, наверное, слышали или читали на хабре об OpenCL – новом стандарте для разработки приложений для гетерогенных систем. Именно так, это не стандарт для разработки приложений для GPU, как многие считают, OpenCL изначально задумывался как нечто большее: единый стандарт для написания приложений, которые должны исполняться в системе, где установлены различные по архитектуре процессоры, ускорители и платы расширения.

Давление на Pirate Bay и другие торрент-трекеры приносит мало пользы в святом деле борьбы с пиратским ПО. Антипиратская компания V.I. Labs провела исследование и выявила, что результатом борьбы с торрентами стала лишь миграция вареза на анонимные файлохостинги. Для проверки эксперты составили список софта от 43 производителей, и 100% позиций этого списка нашлось на RapidShare.

Безусловное лидерство по количеству вареза принадлежит гиганту RapidShare, который уже вышел на 17 место среди крупнейших сайтов интернета. Официальный представитель RapidShare в недавнем интервью NY Times призналась, что их хранилище уже разрослось до 10 петабайт. И это несмотря на то, что по просьбам правообладателей они удаляют 1-2% всех файлов, загружаемых ежедневно (кстати, некоторым правообладателям RapidShare даёт прямой доступ к своей базе, и те могут мониторить загрузки в реальном режиме времени и удалять всё что хотят).

В пиковые моменты «Рапидшара» держит до 3 млн одновременных подключений (скачиваний и загрузок). По оценке аналитической компании Ipoque, один этот сайт генерирует примерно 5% всего трафика в интернете.

Dklab_multiplexor — это инструмент, который позволяет держать одновременно сотни тысяч долгоживущих открытых HTTP-соединений с сервером. Например, если на вашем сайте находится одновременно несколько сот тысяч посетителей, каждый из них может быть связан с сервером постоянным соединением, установленным из JavaScript. Это например, полезно при организации онлайн-чатов или мгновенных уведомлений.

Dklab_multiplexor не претендует на полную универсальность или исключительность (кстати, если знаете аналоги, близкие по простоте к multiplexor-у, пишите в комментариях). Это лишь простейший инструмент, который наконец-то дошли руки опубликовать.

Зачем это нужно?

Предположим, посетители вашего сайта могут посылать друг другу сообщения. Если получатель в момент отправки находится на сайте (просматривает какую-либо страницу), ему немедленно выдается уведомление (всплывающее окошко на JavaScript).

Данную задачу можно решить двумя способами.

1. Неправильный способ. Раз в 10 секунд делать из JavaScript запрос на сервер для проверки, не появилось ли новых сообщений. Этот метод не работает, если на сайте одновременно находится очень большое количество пользователей, т.к. нагрузка на сервер растет слишком быстро. Кроме того, потребление трафика пользователем также оказывается крайне высоким.
2. Правильный способ. Устанавливать постоянное и длительное соединение с сервером, ожидая поступления данных через него. Если сообщений нет, соединение просто держится открытым на протяжение нескольких минут. Если соединение по каким-либо причинам закрылось, оно вновь открывается. В итоге и трафика потребляется мало, и нагрузка на сервер оказывается невелика. Так работает GMail, Мой Круг и т. д., и именно на этом принципе построен dklab_multiplexor.

+-------------------+                    ------------------ 
| Сервер обработки  |                   |                  |   <===WAIT=== Клиент A
| и базы данных     |  ======IN=======> |   Мультиплексор  |   <===WAIT=== Клиент B
| (e.g Apache + PHP |                   |                  |   <===WAIT=== Клиент C
+-------------------+                    ------------------ 
(указаны направления установления TCP-соединений).

Сегодня мы продолжим исследования различных новых и не очень технологий, необычного их применения или просто оригинальных вещей. Возможно, вы вспомните, я когда-то писал о проекте распределённого кеша EHcache для платформы Java. Сегодня настало время продолжить эту тему, однако в другом ракурсе — в виде отдельного RESTful сервера.

Инженер из компании Google весьма критически отозвался о технологиях Microsoft в области распределённой вычислительной инфраструктуры для веб-приложений.

Маленький скандальчик случился на конференции Structure 09, которая посвящена облачным вычислениям. Всё началось с выступления Наджама Ахмада (Najam Ahmad), главного менеджера по глобальным сетевым сервисам Microsoft. Он подробно рассказал, как Microsoft пытается увеличить производительность множества своих сервисов. Мол, проблема в огромном их количестве, так что невозможно подобрать настройки так, чтобы все эти сервисы одинаково эффективно работали на одной платформе. Приходится фрагментировать инфраструктуру, ставить разные серверы с разными настройками для отдельных приложений, таких как Messenger или Virtual Earth, и оптимизировать их по отдельности. Он подробно рассказал, как тщательно они сейчас оптимизируют Virtual Earth.

Сразу после этого слово взял Виджай Гилл (Vijay Gill), старший инженер по архитектуре из Google, и, как говорится, пропесочил конкурента по полной программе.

Привет. Сейчас я расскажу вам о механизме IO Completion Ports в Windows. Разработчики описывают порт завершения как «средство, повышающее производительность приложений, часто использующих операции ввода/вывода». В общем-то, они и не врут, поэтому IOCP часто используют при написании масштабируемых серверных приложений. Однако же считается, что порт завершения — тема мудреная и тяжелая для понимания.

Данный обзор написан специально для SEO Digest — популярного онлайн-журнала среди вебмастеров и поисковых оптимизаторов. Публикуемые в нем материалы рассчитаны на широкую аудиторию пользователей: от профессионалов Рунета до любителей и начинающих. Журнал доступен в PDF и онлайн версии.

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

Основные положения

Ускорение работы любой системы возможно в основном за счет кэширования некоторых (тут стоит подчеркнуть, что именно некоторых, а не всех подряд) часто используемых операций. Все кэширующие мероприятия, в том числе и для Wordpress, можно разбить на несколько основных частей:

• База данных
• Компиляция серверных скриптов (PHP)
• Статические страницы
• Клиентская составляющая

Cегодня одна из самых популярных и активных тем какая? Cloud Computing вообще, а один из лучших, оригинальных и ярких его представителей — Google App Engine в частности. Хорошая новость про добавление в платформу возможности работы приложения на Java — может и я попробую, хотя его, в какой то мере конкурент, Stax, о котором я, с прискорбием, никак не напишу, мне намного больше близок и нравиться. Но если вы все же остаетесь приверженцем Python и хотите нечто подобное, но полностью свое — для вас есть хорошая новость. Открытый проект AppScale позволяет развернуть собственную систему облачных вычислений предоставить возможность развертывать и запускать там приложения на Python-е, в принципе, без изменения кода, что для GoogleAppEngine, что написанные специально под систему.

Dklab_SoapClient — это расширенная версия стандартного PHP-класса SoapClient, предназначенная для параллельного (асинхронного) удаленного вызова процедур в высоконагруженных проектах.

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

По сравнению со встроенным в PHP SoapClient, поддерживаются дополнительные возможности:

• Одновременное, параллельное выполнение запросов к нескольким удаленным процедурам — ключевая особенность библиотеки. Если страница на вашем сайте собирается из 5 удаленных блоков, каждый из которых генерируется по 100ms, их можно запустить параллельно и получить всю страницу целиком не за 500ms, а за те же самые 100ms.
• Реконнект при невозможности установления связи. К сожалению, мир несовершенен, и из-за случайной потери пакетов первая попытка соединения с SOAP-сервером может закончиться тайм-аутом. Это особенно часто происходит, когда проект располагается в нескольких датацентрах. Dklab_SoapClient позволяет задать тайм-аут на время открытия соединения (например, 1 секунду) и, в случае неудачи, повторить попытку указанное число раз. На практике это снижает вероятность итогового сбоя в тысячи раз, т.к. реконнект почти всегда помогает при утере пакета.
• Поддержка тайм-аута на получение данных. Если страница собирается из удаленных блоков, то в случае «подвисания» одного из них «зависает» и вся страница. В то же время, отсутствие одного из блоков при наличии остальных — не такая большая беда. Вы можете указать, сколько времени Dklab_SoapClient должен ждать ответа от удаленной процедуры; если время превышено, возникает исключение PHP, которое вы можете обработать по своему усмотрению, не прерывая загрузку остальных блоков.

Вот вы часто создаете проекты? И, наверное, везде применяете базу данных, в частности, MySQL (а кто-то и PostgreSQL). Но вот что интересно, по опыту да и просто после чтения описания различных архитектур видно, что далеко не везде в проекте нужны ключевые особенности баз данных, во многих случаях базу используют просто как некоторое хранилище обычных данных. Например, в системах кеширования базы обычно не применяются, более того, кеширование как раз используют для того, чтобы избежать лишних запросов. А что используют для кеширования наиболее часто? Memcached. А что это такое? Это распределенная система хранения данных на основе хеш-таблицы. В общих чертах, это просто хранилище пар ключ-значение, над которыми можно производить только основные операции — запись, чтение, удаление и проверку на присутствие. Да-да, нет никаких фильтров, выборок, сортировки, самый максимум — система тегов для выборки одним запросом всех связанных записей. И во многих случаях такого функционала вполне достаточно.

Недавно появился миниатюрный Linux-сервер — «Linux сервер в виде блока питания», изготовленный на system-on-chip (SoC) Marvell Sheeva CPU 1.2GHz с ARM-архитектурой.
Этот сервер вроде бы предназначен не для конечных (домашних) пользователей, и тогда возникает вопрос: зачем было этот сервер делать в виде блока питания под обычную домашнюю розетку?
Неужто нельзя было бы сделать его в виде маленького «Лезвия» — «Blade-сервера» для серверной стойки!
Вы только представьте как вы у своего хостера, разместите в стойку маленький Marvell`овский сервер, стоимостью всего 50$. Или же сам Хостер предложит вам новый сервис — размещения вашего сайта на таком маленьком и дешевеньком, но полноценном и независимым от всех соседей, сервере!
Для не очень больших сайтов (наверно до 10 — 20 одновременных сессий, а это ~ до 10 тысяч посетителей в день) его мощности должно вполне хватать (ну может только Flash-диск хотелось бы расширить, хотя бы до 2 — 4 Gb).
А для больших сайтов, надо объединять 100-ни и 1000-чи такие маленьких Blade`ов в единый кластер (чем например Google, обычно у себя занимается).
И каждый ваш сайт тогда от ныне будет иметь «не виртуальный», а свой полноценный — сервер!!!

Стив Возняк, сооснователь компании Apple, не может игнорировать «зов материнской платы» и решил снова с головой окунуться в бизнес. Он говорит, что хорошо отдохнул и ему нравилось спокойно наблюдать за развитием технологий. Теперь, после двух лет отпуска, Стив опять возвращается к работе. Очередным проектом Возняка стал стартап Fusion-io, который занимается конструированием систем хранения данных на базе чипов флэш-памяти. Они делают компактные модули SSD-памяти (размером с колоду карт), которые можно вставлять прямо в слоты серверов. Один такой модуль стоимостью $10 000 ничем не уступает отдельной системе хранения данных за $100 000.

Во времена основания Apple Стив Возняк считался одним из самых креативных инженеров в Кремниевой долине. Именно он придумал элегантный дизайн новых персональных компьютеров, в котором внешняя красота сочеталась с эффективным расположением компонентов. Собственно, в компании Fusion-io он будет заниматься примерно такими же инженерными делами, но только с серверами и системами хранения данных, а не с ПК.

В отличие от прошлых проектов, Возняк не является основателем компании Fusion-io, а пришёл в этот трёхлетний стартап на должность ведущего инженера (chief scientist). Он уже входит там в совет директоров и, очевидно, является совладельцем.

via NY Times

Введение

Поставили передо мной как-то задачу… говорят один сервер это хорошо… но учитываю рост посетителей, неплохо бы было повысить производительность отдачи и для этой цели будет приобретен еще 1 сервер…
еще один сервер это хорошо, подумал я… только что с ним делать ??
Поговорив с програмистом и примерно поняв чего он хочет…

А именно одновременную отдачу контента, и что-то типа nfs или шары…
но тогда был бы оверхед ибо данные гонялись по сети и нагружен был бы диск одного сервера, посему надо было чтобы данные одновременно хранились на обоих серверах и реплицировались друг на друга…
поискав в гугле что-то на эту тему нашел информацию по кластерным фс, и для меня подходили gfs2 и позднее обнаруженная ocfs2, но была проблема в том что обычно использовалось выделенное файловое хранилище и его уже монтировали ноды… что было неприемлимо для меня, и тогда позадавав вопросы народу в конференции (gentoo@conference.gentoo.ru благо там были люди работающие с кластерами и прочими веселыми вещами) я вышел на drbd

Мы продолжаем исследовать тему такого класса ПО как очереди сообщений применительно к РНР веб-системам. В прошлой статье мы рассмотрели некоторое ПО, в частности представителей как самой верхней области (Apache Active MQ, возможности которого находятся на уровне уже корпоративного ПО), так и достаточно простые варианты, например, MQS. Но не рассмотренными остались еще несколько достаточно интересных проектов, так что наше исследование продолжается.

Параллельно к основной работе, я в «фоне» обдумываю и прикидываю реализации архитектуры для игровых проектов (напомню, что основная область моих интересов и работ — создание онлайновых браузерных игр). Последнее время я все чаще и чаще возвращаюсь к мысли, что интересно было бы реализовать основной игровой сервер на основе очередей сообщений (MQ или Messages queue). То есть, движок такой игры будет представлять собой набор компонентов, которые будут общаться между собой посредством асинхронных сообщений, а каждый компонент может быть как генератором сообщений, так и подписчиком, то есть исполнять другие сообщения.

Такой подход, насколько я понимаю, широко применяется в мире Java, там для этого есть стандарт Java Message Service (JMS) и применяются брокеры сообщений и на этом базируется архитектура Enterprise service bus (ESB), например, Apache ServiceMix. Но для нас это пока высокая сфера крупных проектов, а в специфике веба и веб-ориентированных приложений я бы хотел рассмотреть, можно ли что-то сделать подобное, но с меньшими затратами и обеспечить приложению отказоустойчивость, распределение нагрузки и асинхронную обработку. И конечно, очень желательно, чтобы это было реализовано на РНР как основном языке реализации всех компонентов сервера.

Современные тенденции в развитии web-приложений и экспоненциальный рост информации, ими обрабатываемых, привел к потребности в появлении файловых систем ориентированных на обеспечение высокой производительности, масштабируемости, надежности и доступности. В стороне от данной проблемы не могли остаться такие гиганты поисковой индустрии, как Google и Yahoo.

Специфика приложений и вычислительной инфраструктуры Google, построенной на огромном количестве недорогих серверов, с присущими им постоянными отказами, привело к разработке собственной закрытой распределенной файловой системы Google File System (GFS). Данная система нацелена на автоматическое восстановление после сбоев, высокую отказоустойчивость, высокую пропускную способность при доступе к данным в потоковом режиме. Система предназначена для работы с большими объемами данных, подразумевающих большие размеры хранимых файлов, поэтому GFS оптимизирована для соответствующих операций. В частности, в целях упрощения реализации и повышения эффективности GFS не реализует стандартный POSIX-интерфейс.

Ответом GFS стал open source проект Hadoop, с его Hadoop Distributed File System.

Популярность распределённого хостинга Amazon S3 выросла до рекордного уровня и продолжает увеличиваться очень быстрыми темпами. По последней статистике, на серверах S3 размещается уже 29 млрд объектов, хотя три месяца назад было всего 22 млрд. Как образно сравнил один из программистов Amazon S3, на каждого жителя Земли у них приходится по четыре объекта.

Текущая нагрузка на серверы тоже превышает все пределы. Так, пиковая нагрузка была зарегистрирована 1 октября, когда количество запросов на запись, считывание или удаление объектов превысило 70 000 в секунду.

В связи с увеличением масштабов хранилища компания Amazon приняла решение ещё больше снизить тарифы на хостинг. С 1 ноября 2008 года хранение данных будет стоить от 12 центов за гигабайт в месяц, в зависимости от общего объёма и месторасположения заказчика (для американцев чуть дешевле).

Cегодня мы поговорим о компонентах для высокопроизводительной и масштабируемой архитектуре на основе сервера memcached, а именно — распределённой базе для хранения данных MemcacheDB и системы очередей сообщений MemcacheQ.



Сначала рассмотрим, а что у нас есть в распоряжении для создания распределённой инфраструктуры хранения данных для веб-приложения. Ну, первое, что приходит в голову — кластеризация базы данных, это теперь поддерживается во всех распространённых системах, а также различные технологии репликации. Например, самая популярная СУБД для веб-проектов, MySQL поддерживает как репликации так и кластеризацию. Ещё можно обратится к традиционным файловым система и хранить данные в файловой системе, к примеру, Apache Hadoop. Но часто это слишком высокоуровневое решение, обычно же требуется гораздо проще варианты — когда нужно хранить и оперировать просто парами ключ-значение. Если серьёзно посмотреть, такая функциональность позволит покрыть потребности 90% веб-приложений. А если мы прибавим к этому возможность очень и очень быстро оперировать данными, хранить их в виде распределённой многосерверной системе и возможность постоянного хранения, устойчивого к сбоям — получим очень привлекательную платформу.

На сайте в разделе «для участников» написано следующее: "Стоимость участия зависит от даты оплаты — до конца августа действует цена в 7000 рублей".

В письме, которое пришло с profyclub.org с темой «Профиклаб: предложения для членов клуба» — "… Прежде всего, клубные карты обеспечивают значительные скидки на участие в наших мероприятиях. Так, стоимость «РИТ: Высокие нагрузки» для владельцев обычных карт — 10 000 рублей; привилегированных — 6 000 рублей...".

Ну и наконец в разделе оплаты по webmoney на сайте www.highload.ru — "Вы можете оплатить участие в конференции прямо сейчас. В стоимость, которая сейчас составляет 4500 рублей, входит участие в двух полных днях конференции, питание и раздаточные материалы".

Так сколько всё-таки стоит участие в конференции для владельца синей карты?

P.S. Вопрос снят — не знал что Highload и «РИТ: Высокие нагрузки» это уже не одно и то же.