Список клиентов, поддерживающих XEP-0313 можно глянуть тут https://www.zash.se/mam.html
Для мобил очень удобен Conversations, а среди популярных мессенджеров для десктопов — пока грустновато всё.
Часть клиентов уже реализовала поддержку загрузки истории с сервера (MAM), у других в процессе — актуальный список можно смотреть тут: https://www.zash.se/mam.html
Интересно, что в 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
Печаль… ну что ж, придется тогда продолжать использовать ботов для организации полноценного мультиюзер-чата… ;( Раньше в компании использовали для этого http://partychapp.appspot.com/ но в последнее время он жестко глючит, поэтому пришлось перейти к собственным ботам на базе https://github.com/punchagan/childrens-park
Да, точно, у Jabber конференции как раз по принципу IRC работает, я знал об этом но забыл написать ;) Так в Jappix получается та же проблема — мультиюзер чаты на базе Jabber-конференций сделаны или что-то другое? По-идее XEP-0194 User Chatting должен решать эту проблему, но его, судя по всему, реализовывать надо на стороне Jabber-клиента, а не на сервере: https://github.com/processone/ejabberd/issues/812
А с помощью описанной связки можно реализовать полноценный многопользовательский чат с оффлайн-сообщениями? Чтобы если кто-то из участников ушел в оффлайн и через пару дней вернулся — ему свалились все пропущенные сообщения как новые сообщения.
Т.е. чтобы без лишних заходов в конференции или ручного просмотра истории сообщений — прямо вываливалось сразу при входе юзеру на экран, как обычные оффлайн-сообщения.
ЗЫ: Различные виды чатов обычно реализуются на базе функционала jabber-конференций, но, как я понимаю, в самом протоколе не предусмотрена доставка сообщений оффлайн-юзерам и маркировка кому доставлено кому нет, поэтому как ни крути — ничего хорошего не добьешься кроме как костылей нагородить.
Предложенный метод инкрементального бекапа mysql очень впечатляет! У вас получилось в итоге доделать финальную версию утилиты, которой можно пользоваться в продакшене?
Номера телефонов при переходе от одного сайта к другому «отстаиваются» в течение 7 дней.
В дополнение к этому наверное было бы полезно записывать состоявшиеся разговоры в связке «номер телефона звонящего + компания которая приняла звонок на момент первого звонка» чтобы если клиент решит, например, через месяц снова позвонить (довольно часто номер записывают в записную книжку при первом звонке и звонят потом на этот же номер), когда этот номер уже «отстоялся» и ушел к другой компании, соединить его с той же компанией, а не с новой. Что думаете по этому поводу?
А можете поподробнее описать — на какие фреймворки перешли после Drupal? Мне не нравится, что в друпал слишком много лишнего, хотелось бы перейти в некоторых задачах на что-то более легковесное, но с удобным веб-конструктором моделей, сущностей, представлений, чтобы не в коде ковыряться-описывать все, а как в друпал — прямо в админке создал entity, поля, связи, представления страницы. Ну а результаты уже превратяться в код, который я уже причешу под себя.
Или фреймворки это как раз когда все ручками пишешь в коде, без удобного интерфейса админки?
Благодарю за подробное описание! Скажите пожалуйста, а можно с помощью функции
createFakeParserElement()
или как-то по-другому сделать фейковый элемент не img-картинку заглушкой, а, например, div с произвольной надписью внутри (например с текстом «наименование»)? А то не очень хорошо когда несколько элементов отображаются одинаковой картинкой без подписей и каких-либо отличий.
Ну inotify же не забесплатно будет уведомлять, для того чтобы уведомить об изменениях — нужно какому-то процессу (пусть даже в ядре) при каждой файловой операции записи производить сравнение со списком «я же слежу за этими файлами и папками», собственно если этот список будет содержать 10 тыщ записей, то это наверное печально скажется на каждой файловой операции. Ну и если вдруг резко поменялось 5 тыщ файлов, то накопить 5 тыщ событий в лог, и потом разослать эти события всем слушальщикам.
Собственно поэтому я и боюсь на серверах всяких там программ, которые следят за изменениями в папках через inotify или ещё как, т.к. многие не думают о том что каждая прослушка добавляет тормозов и вешают inotify на все подряд на всякий случай, чтобы было. А потом получаем «что-то диск стал медленно работать, странно, наверное посыпался».
С 7zip и другими популярными архиваторами как раз основная проблема в том, что они не умеют сохранять владельца, группу, права, симлинки и другую специфику unix-файлов, поэтому приходится использовать прослойку tar перед архивированием.
Основная проблема, с которой я начал «копать» данную тему — в очень медленных операциях с большим количеством файлов на облачном сервере, в сравнении с 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 года с момента публикации этой статьи у вас появились какие-то дополнительные методы тестирования производительности дисков, чтобы сделать более свежую статью на эту же тему? ;)
Понятно, что это можно распарсить и вывести в более наглядном виде, но в целом пока устраивает текущий вывод. Т.е. в обычном выводе зафиксировать величины для вывода цифр нельзя никак?
И по поводу github.com/amarao/fio_minimal_csv_header — можете поподробнее расписать как им пользоваться? Насколько я понял, ему на вход нужно скормить вывод «fio --minimal», а на выходе он их должен оформить в каком-то более-менее приглядном виде?
После наблюдения очередной проблемы с медленной скоростью работы облачного сервера (слишком медленно читаются файлы при последовательном чтении) на рабочем проекте все же пришлось более подробно поразбираться в проблеме. Основная проблема, насколько я понимаю, в том, что диски доступны по сети из общего хранилища, отзывчивость которого никаким образом не гарантируется. В результате мы имеем быструю скорость работы с некоторыми файлами, которые читаем постоянно (локальный кеш + кеш на стороне инфраструктуры), и очень медленную скорость работы с файлами, которые читаются не так часто. Поэтому все файловые операции (например rsync папки с кучей файлов) выполняются в 10-20 раз дольше, чем то же самое на каком-то хиленьком VDS с локальным диском или даже локальном компьютере.
В поисках методов измерения отзывчивости дисков я нашел статью habrahabr.ru/post/154235 и решил произвести измерения по этому методу — запускал гибридный тест на 30 секунд и получал результаты, которую публикую сюда:
Я не претендую на то, что этот тест оптимальный и показывает реальную производительность дисков, но он позволяет увидеть источник проблемы — несмотря на высокий IOPS облачные диски имеют крайне низкую отзывчивость (latency, в данном случае clat).
И привожу итоги в более наглядном виде, в одинаковых единицах измерения (вместо usec и msec):
По итогам видно, что у виртуального приватного облака даже «быстрый» диск получился значительно менее отзывчивым, чем у облачного сервера. Но по услуге «облачный сервер» больше нет возможности создать новый сервер, техподдержка предлагает переезжать на виртуальное частное облако, которое по результатам получается заметно медленнее со стороны работы с диском.
Если вы считаете данный тест не совсем оптимальным, то предложите ваш вариант тестирования. Результатом тестов хотелось бы видеть реальную разницу в скорости случайного последовательного чтения/записи множества мелких файлов в различных видах серверов на вашей инфраструктуре (VPC, VDS, VCS и т.п.).
Аналогичные тесты хотелось бы увидеть и для других важных параметров серверов (CPU, RAM, Network).
Опубликовав эти данные публично, у потенциальных клиентов будет больше доверия к вашим услугам, и им будет проще понять что они приобретут и потеряют при переезде от конкурентов к вам.
В итоге, если результаты тестов ваших решений будут лучше чем у конкурентов, то это приведет к вам больше новых клиентов. Сейчас, к сожалению, приходится выбирать оптимальные решения под задачи «в слепую», клонируя свои сервера на десятки разных решений от разных конкурентов, на что уходит очень много времени.
Для мобил очень удобен Conversations, а среди популярных мессенджеров для десктопов — пока грустновато всё.
А можете скинуть ссылку на это обсуждение? И привнесло ли это обсуждение какие-то результаты спустя год?
Мне нужно сделать мультиюзер-чат на своем Jabber-сервере с оффлайн-сообщениями, но не найду никак нормального решения кроме как использовать самописных ботов ;(
В общем наиболее простой вариант проверки — команда 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
Т.е. чтобы без лишних заходов в конференции или ручного просмотра истории сообщений — прямо вываливалось сразу при входе юзеру на экран, как обычные оффлайн-сообщения.
ЗЫ: Различные виды чатов обычно реализуются на базе функционала jabber-конференций, но, как я понимаю, в самом протоколе не предусмотрена доставка сообщений оффлайн-юзерам и маркировка кому доставлено кому нет, поэтому как ни крути — ничего хорошего не добьешься кроме как костылей нагородить.
В дополнение к этому наверное было бы полезно записывать состоявшиеся разговоры в связке «номер телефона звонящего + компания которая приняла звонок на момент первого звонка» чтобы если клиент решит, например, через месяц снова позвонить (довольно часто номер записывают в записную книжку при первом звонке и звонят потом на этот же номер), когда этот номер уже «отстоялся» и ушел к другой компании, соединить его с той же компанией, а не с новой. Что думаете по этому поводу?
Или фреймворки это как раз когда все ручками пишешь в коде, без удобного интерфейса админки?
В общем в итоге сделал вот так:
createFakeParserElement()
или как-то по-другому сделать фейковый элемент не img-картинку заглушкой, а, например, div с произвольной надписью внутри (например с текстом «наименование»)? А то не очень хорошо когда несколько элементов отображаются одинаковой картинкой без подписей и каких-либо отличий.Собственно поэтому я и боюсь на серверах всяких там программ, которые следят за изменениями в папках через inotify или ещё как, т.к. многие не думают о том что каждая прослушка добавляет тормозов и вешают inotify на все подряд на всякий случай, чтобы было. А потом получаем «что-то диск стал медленно работать, странно, наверное посыпался».
Имею на сервере папку с 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 и подобных командах, которые пробегаются по куче файлов в куче папок.
Чем объясняется такая огромная разница в скорости выполнения данной команды?
Поэтому в дополнение к статье было бы очень здорово увидеть несколько готовых конфигов к fio по разным видам нагрузке для быстрого определения производительности текущей конфигурации и сравнения с альтернативными решениями. Ну и, обязательно, с краткой инструкцией «куда смотреть» чтобы было понятно какие параметры являются ключевыми.
Например, сразу в голову приходят 4 теста:
1. Хостинг сайтов: куча мелких файлов объемом 1-500 кб, 98% конкурирующих запросов на чтение всего файла, 2% запросов на запись всего файла.
2. База данных: несколько больших файлов в несколько гб, 70% конкурирующих запросов на чтение куска файла, 30% запросов на запись куска файла.
3. Файловое хранилище: много файлов разного объема от 1 мб до нескольких гигабайт, 80% на чтение полного файла, 20% на запись полного файла.
4. Хранилище бекапов: много файлов разного объема от 1 мб до нескольких гигабайт, 5% на чтение полного файла, 95% на запись полного файла.
И, может быть, спустя 2 года с момента публикации этой статьи у вас появились какие-то дополнительные методы тестирования производительности дисков, чтобы сделать более свежую статью на эту же тему? ;)
Понятно, что это можно распарсить и вывести в более наглядном виде, но в целом пока устраивает текущий вывод. Т.е. в обычном выводе зафиксировать величины для вывода цифр нельзя никак?
И по поводу github.com/amarao/fio_minimal_csv_header — можете поподробнее расписать как им пользоваться? Насколько я понял, ему на вход нужно скормить вывод «fio --minimal», а на выходе он их должен оформить в каком-то более-менее приглядном виде?
В поисках методов измерения отзывчивости дисков я нашел статью habrahabr.ru/post/154235 и решил произвести измерения по этому методу — запускал гибридный тест на 30 секунд и получал результаты, которую публикую сюда:
Я не претендую на то, что этот тест оптимальный и показывает реальную производительность дисков, но он позволяет увидеть источник проблемы — несмотря на высокий IOPS облачные диски имеют крайне низкую отзывчивость (latency, в данном случае clat).
И привожу итоги в более наглядном виде, в одинаковых единицах измерения (вместо usec и msec):
По итогам видно, что у виртуального приватного облака даже «быстрый» диск получился значительно менее отзывчивым, чем у облачного сервера. Но по услуге «облачный сервер» больше нет возможности создать новый сервер, техподдержка предлагает переезжать на виртуальное частное облако, которое по результатам получается заметно медленнее со стороны работы с диском.
Если вы считаете данный тест не совсем оптимальным, то предложите ваш вариант тестирования. Результатом тестов хотелось бы видеть реальную разницу в скорости случайного последовательного чтения/записи множества мелких файлов в различных видах серверов на вашей инфраструктуре (VPC, VDS, VCS и т.п.).
Аналогичные тесты хотелось бы увидеть и для других важных параметров серверов (CPU, RAM, Network).
Опубликовав эти данные публично, у потенциальных клиентов будет больше доверия к вашим услугам, и им будет проще понять что они приобретут и потеряют при переезде от конкурентов к вам.
В итоге, если результаты тестов ваших решений будут лучше чем у конкурентов, то это приведет к вам больше новых клиентов. Сейчас, к сожалению, приходится выбирать оптимальные решения под задачи «в слепую», клонируя свои сервера на десятки разных решений от разных конкурентов, на что уходит очень много времени.