А теперь, как им пользоваться:

На странице нужно подключить скрипт pusher.js.

А затем подписаться на любое событие:

pushSub(«событие»,function(obj) {});

В коллбэк передается объект от сервера. Я использую такую маркировку: событие: «канал.приложение.объект[.ид_объекта, если нужен]». Сервер передает {«id»:123, «status»: «completed»}

Отписаться от события можно с помощью

pushUnsub(«событие»);

В python/django можно приложениях можно воспользоваться готовым модулем pusher.py:

from pusher import push_intent
push_intent(intent, obj)

В качестве объекта можно передать строку, словарь, список или ничего. Событие всегда строковое. Сервер находит подписчика на именно это событие и отправляет ему оповещение. В будущем можно будет реализовать маску типа «channel.app.*».

Теперь, как это работает на более низком уровне:

При загрузке страницы клиент подключается к ws://сервер:8095/sub (порт пока фиксированный) и отправляет:

{«op»: «sub», «intent»: «channelname.taskname.12345»}

Сервер пока ничего не возвращает. Если сообщение отправилось, значит подписка активна.

Приложение на сервере просто отправляет post/get запрос:

http://сервер:8095/pub?intent=channelname.taskname.12345?obj={«id»:123}

И если push-сервер находит подключенного подписанного клиента, отправляет ему сообщение вида:

{«op»: «intent», «intent»: «channelname.taskname.12345», «obj»: {\»id\»:123}»}

При отключении клиента, все его подписки удаляются. Поэтому нужно будет предусмотреть переподключение и переподписывание в JS-библиотеке.

Итак. по теме:

Я конечно понимал, что проблема медлительности мемкеша в необходимости постоянных соединений. И решил поискать модуль с пулом. Он нашелся довольно быстро — django-memcached-pool. И базируется он на umemcache. Вот так все просто оказалось. Самое удивительное, что на русском языке я информации не нашел. Замена модулей дала ускорение memcached до 0.05-0.2мс на тех же данных, что вполне хорошо. Хотя может все это прирост umemcache, так как все на одном сервере.

Подключается все как обычно:

pip install django-memcached-pool

А в конфигурации джанго-проекта нужно указать:

CACHES = {
'default': {
'BACKEND': 'memcachepool.cache.UMemcacheCache',
'LOCATION': '127.0.0.1:11211',
'OPTIONS': {
'MAX_POOL_SIZE': 100,
'BLACKLIST_TIME': 20,
'SOCKET_TIMEOUT': 5,
'MAX_ITEM_SIZE': 1000*100,
}
}
}

Когда все устаканилось, я посмотрел на графики. Memcache уже не так выигрывал mysql. Разница в основном за счет запросов с JOINами и некешированных у последнего. На pylibmc среднее было 0.7мс. Пик ближе к концу — это Cron-задание, нагружающее процессор на максимум. Да и БД подгружает тоже. В итоге использую memcache для разгрузки БД, так как ее время доступа зависит от большего количества факторов. После кэширования части данных, провалов Apdex (процент запросов, укладывающихся в лимит) стало намного меньше.

Все же основания нагрузка в django на БД и шаблонизатор. Значит, самое основное действие — увеличение количества ядер. Можно конечно заменить шаблонизатор на jinja, но не особо хочется этого делать. И переписать основные запросы без использования ORM. Если будет не лень, проверю прирост.
К слову, пробовал levelDB. Синтетический тест показал почти 100к записей и 350к чтений в секунду. Правда она файловая и не многопоточная. Но для одной задачи, где нужно хранить и обновлять много миллионов записей, а затем получать по ним сводку, вполне подошла. ОЗУ для этой цели не подходит, так как первичное заполнение очень долгое. Пробовал Redis, опять же, почему-то у меня он оказался медленнее mysql. Memcache не подходит в силу того, что это кэш. С тарантулом опять какие-то проблемы с адаптером для питона. Разбираться не стал, отложил до лучших времен. Другие Key-Value пока не пробовал.

Еще учась в вузе, в качестве курсового проекта надо было написать базу знаний. Я набросал на C#, так как мне он был тогда интересен, базу, которая задавая вопросы пользователю о его бизнесе, выдает, какая из конфигураций семейства 1С Предприятия 8 ему нужна. Структура базы была построена на том, что четкой линии вопрос-ответ нет. В зависимости от ответов, задаются новые вопросы. Таким образом результат можно было получить даже через 3 вопроса, если точно знаешь, что тебе нужно. Тему нового проекта писать пока не буду. С запуском еще может много чего поменяться, но объяснить концепт можно в нескольких словах. Это уже вроде бы важно.

Писать решил на Python. Пока это самый удобный язык для меня. А вот фреймворк решил взять полегче — Flask. Изучаю. Пока не особо проникся после django. Все в нескольких файлах — пиши где что хочешь. В результате постоянно приходится думать где чего написать. В остальном пока все нормально. Админка хорошая. Это наверно самая используемая пока мною часть. Так как большая часть функционала в базе знаний внутри — расчеты и сопоставления. А ввод и вывод достаточно просты. Тут думаю пригодятся NoSql-системы. Попробую снова внедрить Tarantool. Вроде там уже исправили проблемы описанные мною ранее. Но в том проекте пока хватает MySql. Здесь же задачи другие и вероятно придется заниматься оптимизацией хранения нужных данных в памяти и доступа к ним. Но  прототип пока на MySql в силу удобства администрирования.

Проект по Соционике иногда допиливаю. Задач там много, трафика для мотивации тоже нормально. Хотя до лидера в рунете в несколько раз не дотягивает. Но народу сайт очень нравится, как и приложение ВК. Самый главный минус этой тематики — очень плохая монетизация — аудитория развлекательная по сути и рекламодателей нет. Хотя парочка идей есть, но они требуют активных и достаточно объемных действий, до которых руки никак не доходят.

Сайт расписаний полуживет, и конкурентов с каждым годом появляется все больше. Проблемы у них по сути те же, что и у моего. Хотя некоторые не поленились договориться с вузами и вполне вероятно у них есть будущее. Естественно, самый важный пункт сейчас — это приложения под смартфоны. И народ это понимает и делает их просто пачками.

Уже 3 месяца катаюсь по Азии, точнее больше сижу на месте, чем катаюсь. На 2 месяца завис в Камбодже (Сиануквиль). Вроде бы и заняться здесь нечем, но и сказать, что ничего не происходит нельзя. Постоянно какие-то мелочи и не мелочи приключаются. Но последние недели две вошел более менее в рабочее состояние.

• Вовлекаемость — пользователь должен хотеть поделиться информацией и желательно свести это скорее к отказу от поделиться, чем к позыву. Отмену нажать не сложно, а вот до нужной кнопки пользователь может и не добраться. Но делать надо это уже тогда, когда лояльность пользователя проверена. Примеры в приложениях на смартфонах — поставить оценку некоторые приложения просят слишком рано, а если вообще не просят, то ставят только те, кого приложение реально эмоционально задело в какую-то сторону.
• Дизайн и цепляемость публичных материалов — должна быть цитируемость картинок и фраз. Иногда отличный продукт, даже если им делятся, все равно запускают единицы. На примере соционики могу сказать, что наднейеще надо работать и работать. Сейчас людям нужна сильная затравка, чтобы перейти по ссылке. Ссылок слишком много.
• Игровой момент — пользователь должен сделать действие раньше друга, иногда он может даже пожалеть, что опоздал. В многих играх сейчас есть особенность — если не зашел вовремя, потерял ресурсы. А когда теряешь потому что друг забрал, интереснее.
• Максимальное соотношение результата к действиям на этапе первого знакомства — Например пользователю     достаточно нажать всего одну кнопку, чтобы получить надпись «Ты молодец!», а чтобы получить «Ты Молодец!!!», нужно нажать кнопку уже 3 раза. При этом у пользователя не должно возникать откровенного ощущения однообразия. В играх эта проблема решается красивой разнообразной анимацией. Например Temple Run 2. Тамвсего 3 действия, а однообразия не возникает, так как в погоне за скоростью, не видишь, что делаешь одно и то же. А вот игрушка про зомби, не помню уже как называется, все время создавала впечатление однообразия. Так как постоянно двигаешься между черных теней и никаких лабиринтов. но при этом она тоже набрала большое количество установок. Правда думаю что мало народу играло в нее больше пары часов.

Платформа Django. Крутится все в данный момент вокруг ВКонтакте. Также имеется приложение для ВК. Самая нагруженная часть, работа с друзьями. Нужно учитывать, что они периодически добавляются и меняют тип. Это надо хранить и отображать по хронологии.

Сначала сделал все на MySql: Создал таблицу пар друзей с необходимой информацией. Пока нормализованную. Но проблема в том, что в эту таблицу самая большая нагрузка на запись и от нее нужно избавляться.

Хотел сделать красиво и решил использовать NoSql для этой части. Так как данные должны храниться, решил попробовать Tarantool. Redis не рассматривал, так как по сути они близки, но тарантул типа круче ) Установил все. Нашел адаптер для Python (был только один). Но он оказался слишком простым. Фактически не поддерживались индексы NUM64 и составные первичные ключи (не работает update и delete).

Для проверки сделал полноценную модель друзей на Tarantool с указанными выше ограничениями. Хотел было дописать адаптер, но посчитал, во сколько памяти обойдется хранение 1000 пользователей с друзьями. И почему я сразу не посчитал? В общем затея держать списки друзей с именами и типами в памяти провалилась. Одна из причин — пути к фотографиям из Вконтакте. Из-за них средний кортеж занимал до 300 байт. Если у пользователя в среднем 30 друзей в ВК с приложением, то 30*300= 10кб * 1000 = 10Мб. Вроде немного. Но я рассчитываю хотя бы на 100к аудиторию. Это уже 1Гб.

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

Решил пойти простым путем. Писать json-ответы ВК с друзьями в отдельную таблицу MySql и при загрузке делать запрос из социальных пользователей по ключам друзей (из MySql). Это конечно медленнее, чем брать все из памяти, но поддается кэшированию.

Правда такой подход не позволяет сортировать друзей по дате добавления и изменения типа. А дата добавления у каждой пары своя. Собственно для этих данных Tarantool и может подойти. Но пока решил оставить все на MySql и держать последовательность последних изменений в таблице вместе с json-списками UID друзей. Позже эту таблицу можно будет переложить в память и сделать очередь в Tarantool. Но пока и так все справляется. Основная цель — хранить необходимые данные с небольшим количеством операций записи, выполнена.

Есть еще вариант использовать MongoDB в качестве NoSql для работы с друзьями. Но так как основные данные хранятся в MySql, не хотелось его мешать. С ростом данных и нагрузки, будет виднее.

Выводы:

• Tarantool хорош, но хранить все данные в памяти часто не оправдано. Было бы хорошо иметь возможность иметь своп (например, месячная аудитория часто меньше 10%). Как вариант, можно реализовать его самому.
• Хранить небольшие объемы данных, такие как таблицы соответствия, проще в РСУБД и кэшировать с денормализацией мемкэшем. В основном из-за легкости внедрения. В тарантуле конечно возможностей оперирования данными больше, но и внедрять его сложнее.
• Адаптер для Python пока не доделан, что создает сложности при внедрении.

Еще попробовал облачный сервер от Селектел. Все круто, но по стоимости у меня выходит раза в 2 меньше, чем нынешний VDS, который еще можно во много раз нагрузить. А платить все-таки лучше абонементом, а не считать потраченные мегабайты RAM (которая обходится по сути дороже всего). Прямо вижу, как копейки капают, и жадность просыпается )

Возвращаюсь к серверам БД. В двух словах разница:

• Основные улучшения у обеих — патчи быстродействия, в том числе XtraDB (доработанная InnoDB, но совместимая с ней);
• Percona имеет расширенные средства анализа и администрирования. Часть из них входят в Percona Tools и можно подключить даже к MySql. Но некоторые (количество строк обходов), есть только в самом сервере;
• MariaDB ушла в сторону оптимизации запросов и добавления новых форматов таблиц и типов данных;
• MariaDB идет от старых версий с переработкой фундаментальных алгоритмов. Но разрабатывается создателем MySql. Используется пока мало где;
• Percona используется в многих высоконагруженных проектах.

А вот и видео с разборам всего по пунктам:

Для себя пока остановился на Percona. Хоть у нее и нет порта под Windows, но для разработки мне хватит и MySql.