Следующий пост про Twisted будет, обещаю! )

block+threads сложнее программировать в общем случае из-за необходимости явной синхронизации

Почитайте исходники Deferred, там всего полторы страницы кода ;) Может, будет интересно. На C++ его реализация далеко не так тривиальна, но это специфика языка, а на Python/JavaScript это точно занимает полторы страницы. Как и интерфейс Deferred.

Я не знаю, что такое 'APC' в данном контексте, но потоков на уровне приложения в Twisted для ввода-вывода нет.

На многих ядрах запускается много процессов, потому что всё равно одним сервером это не ограничивается (приложение масштабируется по мере роста нагрузки). 250 Мбит/с — это уже конечный RTMP трафик, не самый удобный для этого дела протокол на самом деле )

ИМХО, это что-то похожее, но… простите меня… Deferred — это красиво и элегантно, а там какой-то тихий ужас ;)

Реактор — сердце событийной системы, он вызывает select/poll/epoll/kqueue, которые обеспечивают возможность сетевого ввода-вывода. Как таковые Deferred на него не завязаны, но без реальных асинхронных событий (ввод-вывод) они большого смысла не имеют, поэтому на практике во всех Twisted-приложениях реактор работает от начала и до конца. Реакторы умеют интегрироваться со всякими GUIшными event loop'ами, поэтому большой проблемы в этом нет.

Асинхронный ввод-вывод очень эффективен как подход, причем дополнительных потоков нет. Пример таких программ был в статье, приведу пару высокопроизводительных еще раз: nginx, HAProxy.

Что касается непосредственно Deferred, их реализация достаточно компактная, ничего сложного, больших накладных расходов они не приносят.

Как факт: наш сервер вещаний (RTMP) на одном ядре процессора обрабатывает 70-150 Мбит/с (порядка 1000 одновременных соединений), в пике до 250 Мбит/с. Он написан на Python/Twisted.

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

Я долго думал, где его поставить, остановился на текущем варианте, вроде бы и много получилось, но с другой стороны до хабраката осталась вся вводная часть.

Если речь о PHP, то он менее читабелен и выразителен для моих целей в данной статье. Хотелось бы, чтобы примеры были понятны как можно более широкому кругу разработчиков, в том числе и незнакомым с Python.

memcached — это не кэш-сервер. Вместе с MemcacheDB (в начале статьи причины почему они рассматриваются вместе) они являются частью поколения БД с интерфейсом ключ-значение. Семантика, масштабируемость, скорость работы и т.п. могут быть различными, но они хранят всегда огромный «хэш».

Отличие memcached от MemcacheDB — только в способе хранения значений, не более. А на практике у меня экземпляры memcached живут по полгода и больше — это превышает на порядок срок хранения структур данных в нем. А для всего остального есть MemcacheDB.

Например, так, или мониторинг занятости места в memcached, распределения slabов и т.п. Согласен ;)

Нет, совсем нет. Современная реляционная СУБД не умеет масштабироваться нормально (с точки зрения нагруженного web-приложения и т.п. задач). Она обладает огромным количеством накладных расходов (от парсинга SQL до ACID-совместимости).

Вариант с memcached будет на порядки быстрее, если он применим. Да и используется он очень-очень часто.

Если кто-нибудь создаст и наполнит контентом, был бы рад помочь! Есть волонтеры?

Какие есть предложения? Если такая статья не лучшее место?

Это зависит от ситуации, для каких-то данных это допустимо, для других — нет. Есть возможность хранения с избыточностью в memcached, и другие решения. Есть MemcacheDB, он данные не потеряет.

В Python есть несколько расширений, которые обеспечивают интерфейс memcached, но пост совсем не об этом, здесь Python используется скорее как псевдокод, это может быть любой другой язык программирования и любая библиотека доступа к memcached, например, с асинхронной семантикой.

Привет Хабру ;) По поводу форматирования текста здесь — отдельная песня. Это vim -> html. Вот здесь: www.smira.ru/2009/01/21/data-structures-in-memcached-memcachedb/ цвета более зачетные.

Управлять удалением по сути нет прямой возможности, т.е. сказать что данный ключ «важен». Есть MemcacheDB, который гарантирует сохранность данных. Можно брать несколько пулов серверов, если память не будет заканчиваться в «важном» пуле, то и удаления ключей не будет.

Под какую ОС? Так их много очень ;)