Jabber-клиент WIME. Наш open source форк на базе PSI+

Список клиентов, поддерживающих XEP-0313 можно глянуть тут https://www.zash.se/mam.html
Для мобил очень удобен Conversations, а среди популярных мессенджеров для десктопов — пока грустновато всё.

Jabber-клиент WIME. Наш open source форк на базе PSI+

Часть клиентов уже реализовала поддержку загрузки истории с сервера (MAM), у других в процессе — актуальный список можно смотреть тут: https://www.zash.se/mam.html

Отстой ли XMPP?

И ещё вопрос — какие-то опенсоурс-альтернативы XMPP/Jabber, где нормально реализованы групповые чаты, существуют на данный момент?

Отстой ли XMPP?

Интересно, что в XMPP сообществе сейчас обсуждается подобная реализация MUC только используя Pub/Sub, что подтвердил мне один из участников рабочей группы.

А можете скинуть ссылку на это обсуждение? И привнесло ли это обсуждение какие-то результаты спустя год?

Мне нужно сделать мультиюзер-чат на своем Jabber-сервере с оффлайн-сообщениями, но не найду никак нормального решения кроме как использовать самописных ботов ;(

Новая услуга: виртуальное приватное облако

Получилось уйти к другому провайдеру ;) Что-то цены совсем высокие у Selectel по сравнению с остальными.
В общем наиболее простой вариант проверки — команда ioping — показывает как раз то что нужно, пример на другом провайдере:
# ioping /tmp
4.0 KiB from /tmp (ext4 /dev/dm-4): request=2 time=1.6 ms
4.0 KiB from /tmp (ext4 /dev/dm-4): request=3 time=693 us
4.0 KiB from /tmp (ext4 /dev/dm-4): request=4 time=657 us
4.0 KiB from /tmp (ext4 /dev/dm-4): request=5 time=3.1 ms
4.0 KiB from /tmp (ext4 /dev/dm-4): request=6 time=582 us
4.0 KiB from /tmp (ext4 /dev/dm-4): request=7 time=719 us
4.0 KiB from /tmp (ext4 /dev/dm-4): request=8 time=642 us
4.0 KiB from /tmp (ext4 /dev/dm-4): request=9 time=712 us
4.0 KiB from /tmp (ext4 /dev/dm-4): request=10 time=809 us
4.0 KiB from /tmp (ext4 /dev/dm-4): request=11 time=1.4 ms
4.0 KiB from /tmp (ext4 /dev/dm-4): request=12 time=1.5 ms
--- /tmp (ext4 /dev/dm-4) ioping statistics ---
87 requests completed in 1.4 min, 1.1 k iops, 4.4 MiB/s
min/avg/max/mdev = 468 us / 895 us / 4.9 ms / 672 us


Metronome IM и Jappix: многофункциональный Jabber, без сложностей в настройке

Печаль… ну что ж, придется тогда продолжать использовать ботов для организации полноценного мультиюзер-чата… ;( Раньше в компании использовали для этого http://partychapp.appspot.com/ но в последнее время он жестко глючит, поэтому пришлось перейти к собственным ботам на базе https://github.com/punchagan/childrens-park

Metronome IM и Jappix: многофункциональный Jabber, без сложностей в настройке

Да, точно, у Jabber конференции как раз по принципу IRC работает, я знал об этом но забыл написать ;) Так в Jappix получается та же проблема — мультиюзер чаты на базе Jabber-конференций сделаны или что-то другое? По-идее XEP-0194 User Chatting должен решать эту проблему, но его, судя по всему, реализовывать надо на стороне Jabber-клиента, а не на сервере: https://github.com/processone/ejabberd/issues/812

Metronome IM и Jappix: многофункциональный Jabber, без сложностей в настройке

А с помощью описанной связки можно реализовать полноценный многопользовательский чат с оффлайн-сообщениями? Чтобы если кто-то из участников ушел в оффлайн и через пару дней вернулся — ему свалились все пропущенные сообщения как новые сообщения.

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

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

SXB: инкрементальный бэкап MySQL

Предложенный метод инкрементального бекапа mysql очень впечатляет! У вас получилось в итоге доделать финальную версию утилиты, которой можно пользоваться в продакшене?

Коллтрекинг с оплатой за лид, а не за номера

Номера телефонов при переходе от одного сайта к другому «отстаиваются» в течение 7 дней.

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

Вышел Drupal 8 — критический взгляд

А можете поподробнее описать — на какие фреймворки перешли после Drupal? Мне не нравится, что в друпал слишком много лишнего, хотелось бы перейти в некоторых задачах на что-то более легковесное, но с удобным веб-конструктором моделей, сущностей, представлений, чтобы не в коде ковыряться-описывать все, а как в друпал — прямо в админке создал entity, поля, связи, представления страницы. Ну а результаты уже превратяться в код, который я уже причешу под себя.

Или фреймворки это как раз когда все ручками пишешь в коде, без удобного интерфейса админки?

Пишем плагин для CKEditor 4

Да я уж пробовал туда разные теги ставить — в любых вариантах на картинку заменяет ;(
В общем в итоге сделал вот так:

                afterInit: function( editor ) {
                  editor.dataProcessor.dataFilter.addRules(
                  {
                    comment : function( value )
                    {
                      if ( !CKEDITOR.htmlParser.comment.prototype.getAttribute ) {
                        CKEDITOR.htmlParser.comment.prototype.getAttribute = function() {
                          return '';
                        };
                        CKEDITOR.htmlParser.comment.prototype.attributes = {
                          align : ''
                        };
                      }

                      if ( value.match(/mycomment:.*/) ) {
                                                var widgetWrapper = null,
                                                        innerElement = new CKEDITOR.htmlParser.element( 'div', {
                                                                'class': 'visiblecomment'
                                                        } );

                                                // Adds placeholder identifier as innertext.
                                                innerElement.add( new CKEDITOR.htmlParser.text( value ) );
                                                widgetWrapper = editor.widgets.wrapElement( innerElement, 'placeholder' );

                                                // Return outerhtml of widget wrapper so it will be placed
                                                // as replacement.
                                                return widgetWrapper;
                      }

                      return value;
                    }
                  });
                }

Пишем плагин для CKEditor 4

Благодарю за подробное описание! Скажите пожалуйста, а можно с помощью функции createFakeParserElement() или как-то по-другому сделать фейковый элемент не img-картинку заглушкой, а, например, div с произвольной надписью внутри (например с текстом «наименование»)? А то не очень хорошо когда несколько элементов отображаются одинаковой картинкой без подписей и каких-либо отличий.

Cкоростная синхронизация миллиарда файлов

Ну inotify же не забесплатно будет уведомлять, для того чтобы уведомить об изменениях — нужно какому-то процессу (пусть даже в ядре) при каждой файловой операции записи производить сравнение со списком «я же слежу за этими файлами и папками», собственно если этот список будет содержать 10 тыщ записей, то это наверное печально скажется на каждой файловой операции. Ну и если вдруг резко поменялось 5 тыщ файлов, то накопить 5 тыщ событий в лог, и потом разослать эти события всем слушальщикам.

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

Ещё один формат хранения архивов: dar

С 7zip и другими популярными архиваторами как раз основная проблема в том, что они не умеют сохранять владельца, группу, права, симлинки и другую специфику unix-файлов, поэтому приходится использовать прослойку tar перед архивированием.

Новая услуга: виртуальное приватное облако

Благодарю за содействие, создал тикет #316344, надеюсь совместными усилиями получится выявить проблему и придумать решение.

Новая услуга: виртуальное приватное облако

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

Имею на сервере папку с 200 тыс. мелких файлов общим объемом около 4 гб, и стал замечать что команда «du -hs» (объем папки) на облачном сервере выполняется неприлично долго. Сейчас решил заморочиться и произвести тестирование.

Во обоих примерах система Ubuntu 14.04 AMD64, файловая система ext4, опции монтирования: rw,relatime,barrier=0,data=writeback,nobh (с опциями по-умолчанию результат практически тот же), папка полностью одинаковая (специально скопировал сейчас).

Тестирую с помощью команды «time du -hs /var/www» в холодном старте (запуск команды сразу после полной перезагрузки системы и ожидания запуска всех фоновых сервисов, т.е. без локального кеширования).

Фоновые сервисы, которые дают нагрузку, по-максимуму остановлены.

Для исключения случайностей проверял несколько раз, каждый раз при «чистом» эксперименте результаты примерно одинаковые плюсминус несколько секунд. Повторный запуск команды сразу после первой выдает уже неверные результаты (1-10 секунд), т.к. все выдается из локального кеша. Если очистить локальный кеш, то ещё иногда бывает какой-то другой кеш, при котором операция выполняется около 1 минуты.

Чтобы исключить кеширование на стороне инфраструктуры — делал паузу между тестами в несколько часов.

Итоги примерно следующие:

Облачный сервер: 5m42.279s

Обычный десктоп-компьютер (Pentium G2120) и 1 SATA диск (Seagate ST91000640NS): 0m47.148s

— Команда «du -hs» приводится чисто для примера, в реальных задачах тормоза проявляются в команде rsync и подобных командах, которые пробегаются по куче файлов в куче папок.

Чем объясняется такая огромная разница в скорости выполнения данной команды?

Как правильно мерять производительность диска

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

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

Например, сразу в голову приходят 4 теста:

1. Хостинг сайтов: куча мелких файлов объемом 1-500 кб, 98% конкурирующих запросов на чтение всего файла, 2% запросов на запись всего файла.

2. База данных: несколько больших файлов в несколько гб, 70% конкурирующих запросов на чтение куска файла, 30% запросов на запись куска файла.

3. Файловое хранилище: много файлов разного объема от 1 мб до нескольких гигабайт, 80% на чтение полного файла, 20% на запись полного файла.

4. Хранилище бекапов: много файлов разного объема от 1 мб до нескольких гигабайт, 5% на чтение полного файла, 95% на запись полного файла.

И, может быть, спустя 2 года с момента публикации этой статьи у вас появились какие-то дополнительные методы тестирования производительности дисков, чтобы сделать более свежую статью на эту же тему? ;)

Как правильно мерять производительность диска

Да, с «minimal» стало намного нагляднее ;))

# fio --minimal ./test.ini 
readtest;0;0;329940;11259;30006;3;89;5.515827;1.196062;282;221438;11633.393635;33859.575791;6586;14152;102.853479%;11308.740000;2122.336812;0;0;0;0;0;0.000000;0.000000;0;0;0.000000;0.000000;0;0;0.000000%;0.000000;0.000000;0.359940%;2.266289%;82454;0;54;0.1%;0.1%;0.1%;0.1%;0.1%;100.0%;0.0%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.94%;2.62%;2.29%;9.28%;18.62%;54.01%;9.13%;0.04%;0.01%;3.06%;0.00%;0.00%;0.00%;0.00%;0.00%

writetest;0;0;0;0;0;0;0;0.000000;0.000000;0;0;0.000000;0.000000;0;0;0.000000%;0.000000;0.000000;270364;9222;30019;4;79;6.516948;1.286312;310;257231;14203.332204;37032.724029;5929;12208;102.718885%;9250.862745;1745.055266;0.199880%;2.238657%;67554;0;22;0.1%;0.1%;0.1%;0.1%;0.1%;100.0%;0.0%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.32%;2.25%;1.84%;7.67%;14.94%;44.06%;24.89%;0.29%;0.01%;3.73%;0.01%;0.00%;0.00%;0.00%;0.00%

Понятно, что это можно распарсить и вывести в более наглядном виде, но в целом пока устраивает текущий вывод. Т.е. в обычном выводе зафиксировать величины для вывода цифр нельзя никак?

И по поводу github.com/amarao/fio_minimal_csv_header — можете поподробнее расписать как им пользоваться? Насколько я понял, ему на вход нужно скормить вывод «fio --minimal», а на выходе он их должен оформить в каком-то более-менее приглядном виде?

Новая услуга: виртуальное приватное облако

После наблюдения очередной проблемы с медленной скоростью работы облачного сервера (слишком медленно читаются файлы при последовательном чтении) на рабочем проекте все же пришлось более подробно поразбираться в проблеме. Основная проблема, насколько я понимаю, в том, что диски доступны по сети из общего хранилища, отзывчивость которого никаким образом не гарантируется. В результате мы имеем быструю скорость работы с некоторыми файлами, которые читаем постоянно (локальный кеш + кеш на стороне инфраструктуры), и очень медленную скорость работы с файлами, которые читаются не так часто. Поэтому все файловые операции (например rsync папки с кучей файлов) выполняются в 10-20 раз дольше, чем то же самое на каком-то хиленьком VDS с локальным диском или даже локальном компьютере.

В поисках методов измерения отзывчивости дисков я нашел статью habrahabr.ru/post/154235 и решил произвести измерения по этому методу — запускал гибридный тест на 30 секунд и получал результаты, которую публикую сюда:

Облачный сервер:
  read : io=276744KB, bw=9211.1KB/s, iops=2302, runt= 30042msec
    clat (usec): min=313, max=231689, avg=13875.86, stdev=15443.12

  write: io=184556KB, bw=6149.3KB/s, iops=1537, runt= 30013msec
    clat (usec): min=833, max=216877, avg=20795.36, stdev=18780.87

Виртуальное приватное облако - быстрый диск:
  read : io=99796KB, bw=3209.2KB/s, iops=802, runt= 31097msec
    clat (usec): min=244, max=140717, avg=39278.48, stdev=7872.94

  write: io=49996KB, bw=1604.4KB/s, iops=401, runt= 31162msec
    clat (usec): min=427, max=155474, avg=79289.17, stdev=9029.01

Виртуальное приватное облако - медленный диск:
  read : io=14696KB, bw=482701B/s, iops=117, runt= 31176msec
    clat (msec): min=15, max=534, avg=267.07, stdev=38.65

  write: io=15016KB, bw=493196B/s, iops=120, runt= 31177msec
    clat (msec): min=7, max=516, avg=264.20, stdev=33.61


Сервер Intel Xeon X3430 с SSD-диском  SSD2SC480GE4DA16
  read : io=449MB, bw=15,334KB/s, iops=3,833, runt= 30011msec
    clat (usec): min=195, max=314K, avg=8340.08, stdev=29320.30

  write: io=431MB, bw=14,706KB/s, iops=3,676, runt= 30018msec
    clat (usec): min=167, max=310K, avg=8695.76, stdev=29247.78


Обычный десктоп-компьютер (Pentium G2120) и 1 SATA диск (Seagate ST91000640NS)
  read : io=22872KB, bw=827097B/s, iops=201, runt= 28317msec
    clat (msec): min=6, max=1608, avg=158.40, stdev=95.58

  write: io=16140KB, bw=585453B/s, iops=142, runt= 28230msec
    clat (msec): min=6, max=1453, avg=223.82, stdev=164.04

Я не претендую на то, что этот тест оптимальный и показывает реальную производительность дисков, но он позволяет увидеть источник проблемы — несмотря на высокий IOPS облачные диски имеют крайне низкую отзывчивость (latency, в данном случае clat).

И привожу итоги в более наглядном виде, в одинаковых единицах измерения (вместо usec и msec):

Облачный сервер
- read:  iops = 2302   latency =  13.87
- write: iops = 1537   latency =  20.79

Виртуальное приватное облако - быстрый диск:
- read:  iops =  802   latency =  39.27
- write: iops =  401   latency =  79.28

Виртуальное приватное облако - медленный диск:
- read:  iops =  117   latency = 267.07
- write: iops =  120   latency = 264.20

Сервер Intel Xeon X3430 с SSD-диском  SSD2SC480GE4DA16
- read:  iops = 3833   latency =   8.34
- write: iops = 3676   latency =   8.69

Обычный десктоп-компьютер (Pentium G2120) и 1 SATA диск (Seagate ST91000640NS)
- read : iops =  201   latency = 158.40
- write: iops =  142   latency = 223.82

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

Если вы считаете данный тест не совсем оптимальным, то предложите ваш вариант тестирования. Результатом тестов хотелось бы видеть реальную разницу в скорости случайного последовательного чтения/записи множества мелких файлов в различных видах серверов на вашей инфраструктуре (VPC, VDS, VCS и т.п.).

Аналогичные тесты хотелось бы увидеть и для других важных параметров серверов (CPU, RAM, Network).

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

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