Меня всегда интересовало, почему при разработке сайтов, так редко в системе навигации используется Ajax? Ведь преимущества по-моему очевидны! Сайт на аякс работает в разы быстрее любого обыкновенного сайта, и даже если учитывать кэш браузера, это заметно.

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.

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

Приветствую.

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

После некоторого, опыта решил написать небольшую статью-шпаргалку о загрузке файлов с использованием возможностей HTML5, а именно File API.

Читайте далее:

1. Поддержка браузерами.
2. Загрузка через Form Data.
3. Загрузка через File Reader.

Буквально вчера столкнулся с ситуацией, что не смог найти рабочих классов/модулей по сжатию/распаковке строк алгоритмом LZW. Точнее сказать: jsCompress-jsDecompress — работает. PhpCompress-PhpDecompress — работает. А вот jsCompress-PhpDecompress либо возвращает вообще что-то неведомое, либо пустую строку. Честно сказать не знаю, может такой проблемы с ANSI и нет, но вот с utf-8 она очень явно проявляется. Потратив несколько часов на решение проблемы я решил опубликовать готовые к работе функции на хабре.

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

Поскольку тема очень обширная, разделю ее на разделы:

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

Рады сообщить, что платформа Jelastic становится «полиглотом» — в четвертом квартале 2012 года планируется запуск PHP облака. Уникальная фишка сервиса Jelastic PHP — это вертикальное масштабирование: больше не нужно переплачивать за большие сервера или страдать от нехватки ресурсов. Благодаря данной фиче с увеличением нагрузки, приложение автоматически получает необходимые ресурсы, с уменьшением соответственно — наоборот. Это действительно новый подход к облачному хостингу: платформа очень проста и удобна в использовании, так что даже новички смогут легко развернуть свои приложения, вместе с тем поддерживаемый функционал очень широк, так что платформа придётся по вкусу даже самым продвинутым PHP разработчикам.

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

UPD. Оригинальная статья достаточно старая — 2010 года. Сейчас ситуация выглядит по-другому.

В декабре 2010 у Reddit-а было 829М просмотров и 119 серверов.
В конце 2011 года — 2,07B просмотров и 240 серверов.

Спасибо potomushto за актуализацию.

UPD 2. Поправил схему для людей с проблемами цветовосприятия. Спасибо second_pilot и spiritedflow

---

Стив Хаффман, один из создателей Reddit, рассказал на презентации, чему они научились, пока строили и развивали Reddit до 7,5 млн пользователей в месяц, 270 миллионов просмотров страниц в месяц и более 20 серверов баз данных.


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


Каждый из 7 уроков будет рассмотрен в соответствующей секции.

• Падайте часто
• Разделение сервисов
• Открытая схема данных
• Избегайте хранения состояний
• Memcache
• Сохраняйте избыточные данные
• Выполняйте максимум работы в фоновом режиме

Если вы разработчик, и у вас есть проект на PHP, и ему наконец-то понадобилось реализовать собственное API — эта статья определенно для вас ;).

JSON-RPC v1.0 появился в 2005 году, спустя 5 лет появилась и вторая версия. В век javascript'а и мобильных приложений многие разработчики до сих пор используют свои собственные велосипеды вместо готового простого стандарта.

Современные системы мониторинга “из коробки” позволяют отслеживать практически все показатели отдельного узла системы, но обладают рядом существенных недостатков

• зная все об одном узле, о работе системы в целом они не имеют никакого представления — попробуйте из коробки выдать руководству “в данный момент у нас 1200RPS на фронте, 90% страниц отдается за 300мс, 95% за 650мc, системных ошибок и таймаутов происходит меньше 10 в секунду” (см картинку под катом)
• выход за рамки одного из системных показателей одного из узлов системы еще не значит, что стоит бить тревогу — возможно узел попал под повышенную нагрузку, или разработчики сменили алгоритм
• в рамках мониторинга отдельных узлов практически невозможно уследить постепенную деградацию сервиса — как правило он срабатывает только когда уже “ничего не работает”
• деградация производительности внешних сервисов не отслеживается в принципе (вас никогда не банил CDN?)

На исходной у нашей площадки более 1.000.000 уников, ~100.000.000 http запросов на фронтенд в сутки и развесистый, в плане сопровождения, зоопарк проектов. Набор ключевых слов — nginx, apache, php (двух вариаций), oracle. С заядлой периодичностью возникают ситуации “у нас все работает” по отдельно взятым зонам ответственности либо, что тоже не редкость, “у вас ничего не работает”. На границах ответственности идет сплошная передача тикетов.
Мы не стали изобретать велосипед и решили сделать мониторинг по времени и корректности отклика пользователю с отслеживанием отклика бекендов, а также какие из них были задействованы при обработке конкретного запроса. Ну и плюс наши объемы — не сильно большие, но несколько граблей по ходу изложения можно продемонстрировать.

Amazon Glacier

Вкратце — Amazon Glacier — это сервис с очень привлекательной ценой сторейджа, созданный для хранения архивов/бэкапов. Но процесс восстановления архивов довольно сложный и/или дорогой. Впрочем, сервис вполне пригоден для secondary backup.
Подробнее про Glacier уже писали на хабре.

О чём пост

Хочу поделиться Open Source клиентом на Perl для синхронизации локальной директории с сервисом Glacier, также расказать о некоторых ньюансах работы с glacier и описать workflow его работы.

Ища на просторах сети музыкальный плеер для сайта, я наткнулся на интересный плеер под названием Speakker, написанный на jQuery.

У многих администраторов voip-сетей, сталкивающихся с sip-серверами слова ser, openser, kamailio, opensips вызывают по меньшей мере головокружение. Почему их так много? Почему так похожи? Какие активно развиваются, а какие уже нет? Какой в конце-концов выбрать?

Хочу познакомить Вас с проектом, который позволит по-новому взглянуть на процесс разработки приложений с web-интерфейсом.
Это не очередная cms или framework, это платформа разработки высокопроизводительных приложений, система управления данными.
При создании были использованы нестандартные интересные подходы. Ничего сверх революционного, реализованы очевидные вещи, которых сильно не хватает во фреймворках и cms.

Добрый день, Хабр!

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

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

За решением на MySQL

(Окончание перевода статьи Эдди Османи о сравнении и выборе библиотеки для проекта со значительной ролью JS на клиенте.)
Содержание первой части:

■ Что такое MVC или, лучше сказать, MV*?
■ Когда нам нужен MV*-фреймворк JS?
■ Где же мы будем нуждаться в MV*, а где нет?
■ Проблема выбора: слишком много вариантов?
■ TodoMVC: общее приложение для обучения и сравнения
■ Предложенные нами критерии выбора фреймворка
■ Dojo и усложнение фреймворков на JavaScript
■ Коллекция TodoMVC (фреймворки, на которых сделаны реализации тестового приложения Todo)

Не так давно на Хабре была статья про навороченный стартап, заточенный на сбор ошибок JavaScript. Далеко не всегда нужно столько возможностей, но оказалось, что многие просто не знают про старый бородатый способ с Google Analytics. Про него я и попытаюсь кратенько рассказать.

Еще давно я хотел иметь свой автоответчик или бота для скайпа, называйте как вам угодно. В гугле я ничего найти не мог, да еще из-за того, что я пользуюсь Ubuntu, задача становилась сложнее в несколько раз. А если учесть, что я знаю только PHP, и то, не очень хорошо, моя мечта становилась нереальной.

Но недавно, просматривая официальную документацию по API скайпа, я обратил внимание на «D-BUS messaging», не знаю, почему я раньше не обращал на него внимание. Разобравшись со всем, я наконец сделал то, что давно хотел! Я получил доступ к Skype API на PHP. Об этом я и хочу рассказать в своей статье.

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).