Гаджет «Евровидение 2009», который мы, Sterno.ru, сделали для компании Google, оказался отличным опытом в тестировании App Engine и проверки того, на что способна эта технология. Теперь мы гораздо лучше понимаем, как работает «Движок приложений» при высоких нагрузках. Эта статья описывает сильные и слабые стороны Google App Engine, а также подводные камни, с которыми разработчики могут столкнуться в ходе ее использования.

Всем привет :)
Этот мой первый пост на Хабре — доклад на конференцию «Электронный бизнес и управление Интернет-проектами» , которая проходила в ГУ-ВШЭ 19-20 мая.
Буду рад любым Вашим комментариям и замечаниям.
UPD К сожалению, нет возможности перенести в тематический блог :( Пусть висит здесь :)
UPD2 Спасибо за карму, перенес в этот блог (блога Облачных вычислений не нашел, плохо искал?)
UPD3 Я реально попал на главную, или мне снится? о_О
Острожно: много букоф! :)

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

Введение
История знает множество примеров того, как некий продукт постепенно превращался в определенную общественную услугу. Достаточно вспомнить лишь переход от газовых горелок и газовых баллонов к публичной услуге предоставления газа. Такие примеры предоставляют нам понимание того, как уникальность технологии постепенно получает массовость, превращаясь в сервис.
Еще совсем недавно, буквально 20 лет назад, доля использования информационных технологий в бизнесе составляло меньше 5-10 %. Сейчас – практически 100%. Переход от уникальности к масштабности позволяет воспринимать вычислительные мощности уже не как отдельный компьютер-сервер, стоящий в здании организации, а как услугу, которая предоставляется неким далеким датацентром.

Если вы хотите научиться писать многопоточные приложения на PHP или здорово упростить себе жизнь — статья для вас.

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

Жаль, если ваше изучение концепции исключений закончится чтением соответствующего раздела официальной документации по вашему языку.

Изучив синтаксис конструкции try{...}catch(Exception $e){...}, узнав о возможности создавать собственные классы исключений, наследуя их от класса Exception и поверхностно осознав мощь оказавшегося в ваших руках механизма, дальше вы можете пойти по одному из двух путей:

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

Предыстория

Решив запустить небольшой сервис на подаренном мне хостинге, оказалось, что там нету ни одного xml-парсера: ни SimpleXML, ни DOMXML, а только libxml и xml-rpc. Недолго думая, я решил написать свой. Мне требовался разбор не сложных rss-лент, поэтому хватило достаточно просто класса xml => array.^[1]

Но для интересной статьи этого было явно не достаточно, поэтому сейчас мы напишем свою замену для SimpleXML. А заодно пробежимся по многим интересным возможностям PHP 5.

Постановка задачи

Доступ к элементам у нас будет осуществляться как доступ к свойствам класса, например $xml->element, а доступ к атрибутам элемента, как к массиву, те $xml->element['attr'], также реализуем проверку на существование атрибута при помощи isset() и итерацию по элементам при помощи foreach. И так, начнем.

Вступление

Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом могут ли на одну кнопку в один момент времени нажать одновременно 2000 человек. А зря. Оказывается могут. Как ни странно но большинство движков, написанных такими программистами, очень плохо ведут себя под большими нагрузками. Кто бы подумал, а всего один лишний INSERT, не проставленный index, или кривая рекурсивная функция могут поднять load averages чуть ли не на порядок.

В этой статье я опишу как мы, разработчики проекта, сумели выжать из одного сервера с Pentium 4 HT / 512Mb RAM, максимум, держа одновременно 700+ пользователей на форуме и 120,000 на трекере. Да, проект этот — торрент трекер. Предлагаю сразу оставить в стороне разговоры о копирайтах и правах, мне это не интересно, что действительно интересно — это HighLoad.

В жизни каждого системного администратора рано или поздно наступает момент, когда глаз и рук уже не хватает уследить за всеми серверами, то там, то там возникают какие-то проблемы, а для решения их очень хочется узнать что же было «до этого». И именно здесь на выручку приходят они — вел
икие и ужасные системы мониторинга. Долгое время я пользовался Nagios, и до сих пор, при всём удобстве, иначе как монстрообразным назвать не могу. В итоге реально использовались лишь 10% возможностей этой прекрасной системы. Всё изменилось, когда я наткнулся на Munin — прекрасное решение для мониторинга небольших сетей.

Так сложилось, что у меня дома 100мбитный интернет-канал, безо всяких шейпилок и с неограниченным трафиком. Так как трафика мне не жалко — точка доступа (точнее — старенький ноут :) раздавала его налево и направо без каких-либо ограничений.
Кто-то из соседей им периодически пользовался, а мне было приятно, что кому-то от этого хорошо :)
Но тут появился странный товарищ — сначала пытаться подобрать пароль к ssh, а потом начал круглосуточно качать что-то в большом количестве, просаживая канал. КулХацкер, в общем. Пару раз заблокировал его mac — товарищ его после менял. Потом поставил простой WEP пароль — ну, думаю, поймет человек, верну обратно.
Ан нет — через пару дней он его «сломал» (не будем обсуждать небезопасность WEP) и продолжил качать порево что-то.
Так как заменять человеку домашнего провайдера в мои планы не входило — пришлось сегодня поднять hostapd, и вкрутить WPA2 шифрование.
Товарищ остался не у дел, но и несколько человек еще, кто-то из которых похоже просто сидел в «одноклассниках» и еще чем-то легком остался без халявного интернета.

Мне кажется, таким товарищем движет желание нае обмануть окружающих, мол если человек не знает что надо включать щифрование — то он «лох» и его можно «обуть».
В общем — поддерживаете ли вы идею раздавать свой интернет страждущим? :)
Я вот вижу только воркэраунд — сильно шейпить трафик с «незнакомых» адресов.

UPDATE
Забавно, если сначала все поддерживали идею, то сейчас, видимо почитав «хвост» топика, крутят пальцем у виска и говорят, мол «хочешь проблем — раздавай, и ващетыдурак».

JS Charts является бесплатным JavaScript-генератором графиков и схем, который требует минимум знаний программирования. С JS Charts рисование диаграмм становится простой и легкой задачей. Он не требует никаких дополнительных плагинов и серверных модулей. Просто подключите скрипты, подготовьте данные для схемы в XML или массиве JavaScript и ваша таблица готова.

Хочется раз и навсегда решить проблему определения языка пользовательского ввода на сайте. Представьте, что я делаю многоязычный Habrahabr :-) и не хочу спрашивать у пользователя, на каком языке он пишет. Думаю, компьютер должен справится с такой проблемой.

Work on Stuff that Matters: First Principles

опубликовано 11 января 2009 года

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

Но прежде всего я хочу прояснить, что «работа, которая имеет значение» не подразумевает только некоммерческие проекты, благотворительность или иную форму «добрых дел». Некоммерческие проекты часто означают хорошее дело, и люди с техническими способностями могут внести важный вклад, но очень важно выбраться за пределы этих рамок. Я абсолютно убеждён в социальной ценности бизнеса, который ведётся правильно. Нам нужно создать экономическую систему, в которой общественно значимые проекты автоматически и гарантированно получают вознаграждение, а не основанную на благотворительных организациях, финансируемых по доброте сердечной.

Чтобы получить содержимое веб-страницы все с удовольствием используют file_get_contents(), например file_get_contents('http://www.habrahabr.ru/'). Но я уже давно наблюдаю, что, как дело доходит до того, чтобы отправить POST, разработчики используют либо CURL, либо открывают сокеты. Я не считаю, что это плохо или что не надо так делать, просто для решения простых задач можно использовать простые решения.

Я и сам так раньше делал, пока на наткнулся на понятие контекстов потоковых операций в PHP. Контекст позволяет передать дополнительные параметры потоковому обработчику. Для http например, можно сконфигурировать POST-запрос или передать дополнительные заголовки.

file_get_contents() принимает 3 параметром «контекст», который собственно и конфигурирует сам запрос.
Ниже пример такого запроса или RTFM

Примечание: ниже перевод заметки «Image Optimization, Part 4: Progressive JPEG…Hot or Not?» из блога YUI. В ней уже известный по прошлым статьям Stoyan Stefanov рассматривает использование последовательных (progressive) JPEG с точки зрения клиентской оптимизации. Мои комментарии далее курсивом.

В своей предыдущей статье «Оптимизация изображений, часть 3: 4 шага для уменьшения размера файлов» последовательные JPEG-файлы были вскользь упомянуты как одна из возможностей для оптимизации JPEG. Эта статья рассматривает данный вопрос более глубоко, включая результаты проведенного эксперимента над 10000 изображений.

Базовые (baseline) и последовательные JPEG

Базовые JPEG являются «обычными»: файлы этого типа поддерживаются всеми программами для редактирования изображений. Браузеры загружают их последовательно, сверху вниз, по мере поступления информации из сети.



Загрузка базового JPEG-файла в браузере. По нажатию откроется полная версия.

Последовательные JPEG являются другой разновидностью данного формата: они загружаются (как можно понять из названия) последовательно. Сначала вы увидите картинку низкого качества. Затем, по мере поступления графической информации, качество изображения будет постепенно улучшаться.



Загрузка последовательных JPEG. По нажатию откроется полная версия.

Читать дальше на webo.in →

22 сентября 2008 года мы запустили в сеть проект darudar.org — сайт, с помощью которого люди дарят свои вещи, свои возможности и свое время, безвозмездно, бесплатно, не требуя чего-либо взамен. А спустя ровно 10 дней мы стали невольными свидетелями спонтанного и неожиданного эксперимента, развернувшегося прямо на нашем сайте и рассказавшего нам кое-что о передовых сообществах рунета и их обитателях.

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

30 сентября — на lepra.ru, 1 октября — на habr.ru, и 2 октября — на dirty.ru. Текст сообщений примерно одинаков: краткое описание ресурса и предложение отдать свои инвайты всем заинтересовавшимся. Пользователи трех вышеупомянутых сообществ оказались в абсолютно одинаковой ситуации: информации о Дару~даре практически никакой, посмотреть на сайт, не зарегистрировавшись, никак нельзя.

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

Вот какие домены можно зарегистрировать абсолютно бесплатно:
Украина
.net.ua, .od.ua, .org.ua, и множество вида регион.ua
Россия
.com.ru, .net.ru, org.ru, pp.ru, .msk.ru, spb.ru и множество остальных типа регион.ru

Ниже инструкция типа «домен бесплатно для чайников»

Не так уж много кто знает о том, что некоторые задачи в PHP можно заставить выполняться параллельно — и для не этого не нужно прибегать к форкам. В PHP5 есть stream-functions, и среди них — stream_select().

Прочитав статью Cameron Laird (http://www.ibm.com/developerworks/opensource/library/os-php-multitask/index.html?S_TACT=105AGX44&S_CMP=EDU), каждый, кто еще этого не сделал, сможет научиться этой технике, я же в этом топике предлагаю вашему вниманию простой небольшой класс Parastreams, который собсно займется распараллеливанием — а уж что делать с полученными из потоков данными — вы решите сами, указав обработчики данных.

В этой статье я открою секреты того, как работает adme.ru, а именно я расскажу о том как устроено хранение статей и тэгов, как работает полнотекстовый поиск, поиск по тэгам и всё такое…

В статье приведён пример структуры таблиц, рабочий конфиг Sphinx и немного php кода с примерами выборок.

Модуль для nginx, с помощью которого достаточно просто мониторить прогресс загрузки файлов на сервер. Ранее были подобные решения, через модули к php, ruby, через стороние скрипты, flash объекты итп. Автор предлагает универсальное решение на уровне web сервера. Подробную информацию и инструкции вы можете найти на wiki.codemongers.com (кстати, один из лучших проектов, посвященных nginx`у). Тут я хотел обратить внимание на другое.
Использовал модуль совместно с nginx upload module, работает на ура. Однако файлы, что я заливаю, достаточно большие (поддерживаю файлообменник), пытался запихнуть в директиву upload_progress размер обрабатываемых файлов — 1g, при релоаде nginx`а получил варнинг, мол непонятный размер вы поставили. Странно, т.к. в client_max_body_size у меня стоит 1g и нормально себя чувствует. Глянул исходники nginx`а и модуля, выяснелось, что модуль обрабатывает директиву upload_progress функцией ngx_parse_size, тогда как сам nginx обрабатывает ту же client_max_body_size соседней функцией ngx_parse_offset, функции абсолютно идентичны (на мой взгляд), разве что первая не понимает размерность «g», а вторая понимает =) Для того, чтобы модуль нормально обрабатывал размерность в директиве upload_progress, надо в исходнике модуля (ngx_http_uploadprogress_module.c) в строчке 1151 исправить ngx_parse_size на ngx_parse_offset.
В общем это не критично, т.к. директива нормально обрабатывает значение 1024m, но как-то нелепо выглядит подобная запись =)))
А вообще модуль очень понравился, очень удобное решение, не зависящее от бэк-енда.

update: Внимание, совершил глупую ошибку. Стыдно. Деректива upload_progress задает не максимальный размер загружаемых файлов для указанной зоны, как я думал, а размер оперативной памяти, выделяемой для обсчета одной загрузки в эту зону. Значение для этой дерективы — 1,2m, максимум 10-20m. Задавая 1g вы будете тратить гигабайт оперативки на каждую загрузку. Стыдно, ошибку не повторяйте.
p.s. тем не менее баг найден, автору сообщил, он обещал исправить.

Ни для кого не секрет, что работа с базой данных занимает большую часть работы практически любого сайта. И именно работа с БД чаще всего является узким местом веб-приложений.
В этой статье хотелось бы дать практические советы использования MySQL.
Сразу оговорюсь:

• данная статья написана про MySQL, хотя общие вещи скорее всего справедливы для любой СУБД.
• все написанное в статье является моей личной точкой зрения, и не является истиной в последней инстанции.
• советы не претендуют на новизну и являются результатом обобщения прочтенной литературы и личного опыта.
  
• в рамках данной статьи я не буду касаться вопросов конфигурирования MySQL.

Проблемы при использовании MySQL можно разделить на следующие три группы(в порядке значимости):

1. Неиспользование или неправильное использование индексов.
2. Неправильная структура БД.
3. Неправильные \ неоптимальные SQL запросы.

Остановимся на каждой из этих групп подробнее.

Пообещал вчера написать статью о реальных случаях оптимизации БД MySQL.
Пришлось сегодня вставать утром пораньше чтобы воплотить обещанное в жизнь.
Централизованное управление мыслями поддерживать еще сложно, поэтому не судите строго за казусы и ляпсусы в моей статье.

В последнее время приходится достаточно часто заниматься оптимизацией производительности сайтов. И как правило «бутылочным горлышком» в производительности работы этих сайтов является именно БД, ошибки как в архитектуре так и в выполнении запросов. Начиная от неправильной расстановки индексов, либо совершенным их отсутствием, неправильным (неэкономным) выбором типов данных под определенное поле, заканчивая абсолютно нелогичной архитектурой БД и такими же нелогичными запросами.

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