Aerospike

    I would like to tell many thanks to Artem Andreenko, who tell me about Aerospike. Its really amazing solution. In this NoSQL database I found solutions for a lot of problems we faced with when we deploy Redis to production. If you still use Redis - just learn about Aerospike and remove ths shit from your production environment. Some aerospike features:

• Very simple in configuration. Just install from deb packages and thats it.
• Very fast. Even on default settings you will get 100K TPS out fo box
• Rack aware replication. XDR replication in enterprise edition
• Nice monitoring GUI - Aerospike Management Console 

Docker

     I've been playing with Docker for quite long time - since version 0.5 or so. Now Docker became spread a lot, so its hard to find person who don't know about Docker.  Docker used by Yandex and Google, Docker became default container engine for RHEL 7.  And still there are some things I was not aware about,  For example about nsenter util.
    I regret that I have not read that article 6 months ago - https://blog.docker.com/2014/06/why-you-dont-need-to-run-sshd-in-docker/ 
    Another article I find useful for myself - http://blog.dotcloud.com/under-the-hood-linux-kernels-on-dotcloud-part 

Just some thoughts

     1. Persistent connections in php redis just not work. Don't waste your time on it. Its not worth. Today we met another bug related with persistent connections to Redis - so we have to turn it off. No matter how expensive it is. 

       2. Gmail is awesome.  Once amount of emails in your inbox brought limit of several hundreds per day - you have to learn "shortcut kung-fu". Its saves a lot of time. 

       3. Once we start use Redis at production, I realise how fast was memcache. Before this I just know - "yes, memcache is fast".... now I can compare memcache with other in memory storage systems, and yes - memcache is fastest engine I've even seen. Yes, Redis performance can be close to memcache one - just few times slowly then memcache. But Redis consume much more CPU. If you run Redis on the same server with PHP-FPM, you should use CPU affinity and renice(8). It help us stabilise  Redis latency. 

      4. If you use Percona server - you must set innodb_adaptive_hash_index_partitions=64, it greatly improve  our performance.

          5. I've tried new version of cloud.percona.com and I would like to say - its really nice. Of course some features still missed, some amount of bugs exists - but this tool help me a lot during last few weeks. I can recommend you to give it a try.

Снова про Вьетнам: Vung Tau

      Я много писал про известные вьетнамские куррорты: Муйне, Нячанг, Дананг и прочее, но до Vung Tau так руки и не доходили. В связи с появлением личного времени я решил восполнить эту историческую несправедливость. За тот год что я живу в Сайгоне, я побывал в Вунг Тау раза 3.Первый раз - на мотобайках.

В этой поездке мне дорога запомнилась гораздо больше чем сам Вунг Тау. Вроде бы пустяки - каких-то 150 км по дороге и ты на месте. Это реально пустяки - почти в любой стране мира, но не во Вьетнаме и не на мотобайке. В общем 2 часа страха и ты на месте. Можно и за полтора часа доехать - но это будет очень страшно :-) Второй раз мы поехали на метеоре - речное суденышко, на подводных крыльях. Они ходят почти каждый час, стоят 200 000VND(10$). Сразу скажу что суда очень старые, советской еще постройки. И на обратной дороге мы это почувствовали на себе. У нашего судна возникли какие-то неполадки с двигателем и мы вынуждены были вернуться обратно в Вунг Тау, пересесть на другой - не менее старый теплоход и наконец-то добраться до Сайгона. Недавно в газетах писали что на одном из таких суденышек слычился пожар, и народ выпрыгивал прямо в воду. Согласитесь прыгать в эту желтую воду - приятного мало. В третий раз тоже поехали по воде - но на это раз случилось штормовое предупреждение - и все рейсы просто отменили. Пришлось ехать на автобусе, всего за 95 000VND (5$).  Дорога заняла чуть больше времени чем на катере - но все равно, не плохо.

       Что касается самого Вунг Тау - то это очень приятный, небольшой такой городок. Чситенький такой, солнечный. Там еще с советский времен есть русский городок. Но прямо скажем - русских там не много. Ну или не так много как в том же Нячанге или Муйне.  Первый вопрос который про него обычно спрашивают - как там море. Море скажу я вам так себе. Нет, не могу сказать что очень плохое - если отъехать подальше от устья реки - то вполне можно купаться. Чуть хуже чем в Муйне.... но с Нячангом/Данангом конечно не сравнится.

Если хочется пожить в ресорте - то километров 20 от Вунг Тау есть Long Hai - там полно их. И кто-то даже здиет туда. Вообще складывается впечатление что раньше Вунг Тау был прям первоклассным куррортом. Ну лет так 20 назад :-) В то время наверное река Сайгон не была такой грязной, как  сейчас. 

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

Еще в этом парке есть страусы - такие же потрепанние как и сам парк

               Еще в городе есть несколько очень вкусных ресторанов. Можно попробовать лобстеров за 450 000VND(23$), или поесть вкусной действительно итальянской еды (ресторан David). Есть очень вкусные пекарни - мы всегда там вечером отмечались :-) Для неженатых есть целая улица баров с интригующими названиями - Cucumber, Hot lips и так далее.  Очень красивая набережная. В общем после Сайгонского смога и грязи - душа прям расцветает там. Могу порекомендовать небольшой уютный отельчик в центре - Sakura.

За 20$ в день вы получаете чистую, светлую комнату с удобными кроватями и всем необходимым. Единственное что - не в коем случае не берите комнаты без окон - они немного дешевле, но в них душно.  Еще там есть кайт сёрф станции - для любителей этого дела. Я был честно говоря удивлен, узнав об этом. Я думал все кайт сёрферы давно в муйню переехали.
           Местная достопримечательность - статуя Богородицы и статуя Иисуса. Почти как в Бразилии :-) Только чуть чуть по меньше и совсем не знаменитая :-)          

Percona Cloud Tools

    Today I've spend some time in Percona Cloud Tools. New version of this tool looks much better. But many things still not working as I expect. For example their killing features like Query Analytics and MySQL server related metrics. I've reported few bugs - so we will see how fast they will reply on it.
Also one note for myself:
    In order to turn on slow query log, alter settings changing we must run "FLUSH LOGS".
Today I spend few hours while checking all settings, related to slow log feature.
BTW: new version of Percona Cloud Tool written in Go

Gocraft gorelic

        Таки да, я снова родил middleware для своего детища - gorelic. Что называется, продвигаю как могу :-)
      https://github.com/yvasiyarov/gocraft_gorelic

Session storage benchmark

           Уже очень давно я бьюсь над проблемой: а как настроить Redis "чтобы оно работало". Казалось бы - хранить сессии в Redis - что может быть проще ? Это ведь как раз то что доктор прописал.  Хер там был.  Чем больше я еб#### с этим редисон, тем больше я начинаю ненавидеть все что начинается на NoSQL.  Для меня скоро NoSQL будет синонимом - "не работает".  Взять к примеру Couchbase/CouchDB. На бумаге все прекрасно. Казалось-бы, вот оно счатье - настало. Все само реплицируется, партиционируется и масштабируется. Хер там был. Оно просто не работает. Если при более-менее высокой нагрузке  начнется решардинг - наступает пиз###. Производительность всего кластера настолько деградирует что это равносильно даунтайму.  И это не говоря о случайных спадов в производительности - когда у нг внутри какой-то буффер переполняется и время ответа ни с того ни с сего увеличивается в 10 раз. А через минуту все снова охеренно. Но за минуту ты легко можешь отхватить и 10 и 100 тысяч запросов.  Какая-то часть из них умрет по таймауту и покажет 50x ошибку пользователю. В погоне за успехом в кратковременных бенчмарках, которые любят размещать в блогах  - NoSQL писатели такую херню делают, что диву даешься.  Неужели они не понимают что гарантированная производительность(пусть немного медленне) - это гораздо лучше чем 100000 запросов в секунду в пике,  с временными спадами до 10 запросов в минуту.  

             Итак вернемся к нашему редису.  На первый взгляд идеальное решение для хранения сессий. Но есть маленькое но.... Он однопоточный.... То есть если вы запустили какую-нибуть тормозную команду - например KEYS, то до тех пор пока команда не выполнится - ни один коннект не будет обработан. Просто такой маленький stop the world.  Представьте что у вас 10GB база и кто-то запустил KEYS по ошибке... сколько у вас коннектов отвалится по таймауту ?? Они еще зачем-то прикручивают туда Lua интерпретатор... Если у вас однопоточный сервер  с c event-loop, то все что сложнее чем GET/SET вам просто противопоказано!  Иначе забыть можно про сколько нибуть предсказуемое время ответа. 

                Вторая проблема - RDB checkpointing.  Документация нам говорит что раз в какое-то время Redis форкает процесс, который его сохраняет на диск. Вроде все охеренно... сохранение происходит в отдельном процессе... никто никому не мешает...  Но как то честно говорит документация - на время создания снапшота все блокируется...  То есть раз в какое-то время ваш Redis будет подвисать... Причем чем больше ваша база - тем больше подвисание. Вот подвисли мы на 30 секунд - а кто запросы то обрабатывать будет ?? Хуй в пальто ? Что тут еще скажешь ... Прелестно блять, просто прелестно.  Писали писали приложение, только оно начало работать... база выросла - и на тебе жопу. И что хочешь тут то и делай. Broken by design.

               В общем вы поняли что Redis идеален если у вас маленькая база и нет нагрузки. Во всех остальных конфигурациях - ебитесь как хотите. Но спрашивается - если у вас 10 сессий в час, и 3 хромых пользователя онлайн - нахера вам Redis ??? Храните сессии в файлах и не выпендривайтесь. 

              Итак, слюни в сторону - что дальше то делать? Если Redis то работает, то не работает - нужно поставить рядом два редиса и переключатся между ними... Выглядит все просто... но чтобы поддерживать оба редиса синхронизированными - нужно настроить репликацию между ними... Если вдруг один Redis задумался - нужно переключится... И при этом не забыть развернуть репликацию... мы же не можем в slave писать... Причем переключить нужно оба сервера... а если первый сервер в серьез "задумался" ?? Он и на пинги -то не отвечает, а ты хочешь чтобы он на более сложные команды ответил... В общем мы рискуем получить рассинхронизацию - когда оба сервера будет считать себя master, а ты потом разбирайся - что и куда у тебя записалось... В общем классический split brain.  Легкая на первый взгляд задача оказалась тем еще гемороем.  Для того чтобы решить эту проблему Redis предлагает Sentinel. Охеренно, подумал читатель. Но не тут-то было:

Sentinel is currently developed in the unstable branch of the Redis source code at Github. 

         Документация честно говорит - что Redis Sentinel - он ... ну как сказать... не так уж прям чтобы очень стабильный был. Но то и понятно, задача которую он решает - не из простых. Поставили мы два редиса, два Sentinel... но тут мы понимаем что для того чтобы избежать split brain нам нужно минимум 3 инстанса .... окей, это тоже решаемо... подогнали еще сервак, воткнули туда редис с сентинелем и ждем. Чего ждем непонятно. Ну переключит Sentinel мастера на другую ноду, но нашему приложению-то кто об этом скажет ? Либо нужно писать "умных клиент", который сам будет из 3-х предложенных инстансев выбирать мастера.... либо ставить load balancer....  с недавних пор (версии 1.5.x dev) HA proxy умеет выбирать мастера из N-бэкендов. Вообще пользуюсь случаем хочу сказать - HA proxy охеренен. Просто ты работаешь и чувствуешь как там все продумано, все до мелочей. Начиная от конфигурации и заканчивая логгированием. Сразу видно что HA proxy писался для решения реальных задач в production системах, а не как очередная гиковская игрушка. Dev версии HA proxy более стабильны чем большинство релизных версий современного софта.  Сразу видно чо писал его человек старой закалки с огромным опытом. Кстати для тех кто не знает - на сайте HA proxy есть коллекция довольно занимательных статей.   В общем при правильной настройке HA proxy - то единственный компонент получившейся системы, за который я могу быть спокоен. 

             Итак, вернемся к нашим котятам. Теперь получившееся нечто надо протестировать. По возможности реальной нагрузкой... Для этих целей и был написан session_storage_bench. Этот скрипт пытается в точности эмитировать поведение php-fpm процесса: заблокировал сессию, прочитал, подождал 200ms (время обработки запроса), записал обратно, снял блокировку. Он умеет разговаривать с memcache(и другими memcache-like системами, такими как Couchbase) и с Redis. Думаю не составит большого труда написать адаптер для любого другого хранилища сессий. Также он умеет имитировать persistent коннекшены.  В общем - пользуйтесь :-)