Pull to refresh

Comments 23

Во время тестирования мы оптимизировали некоторые настройки типового решения


Думаю, были бы интересны подробности тюнинга. Ну и опущен момент что там с сетью между СБ и СУБД? 10G или меньше?
Сеть между серверами в тесте была 1 GB
Оптимизации типового решения
  • увеличили время кеширования компонентов (дни рождения, важное) на главной странице портала;
  • отключили типовой компонент «кто на сайте» и компонент статистики;
  • изменили настройки ряда констант в dbconn.php;
  • выполнение всех агентов перенесли на Cron (https://dev.1c-bitrix.ru/community/webdev/user/8078/blog/2755/);
  • в главном модуле включили быструю отдачу файлов через nginx;
  • в модуле push&pull включили использование последней версии сервера мгновенных сообщений.
А, пардон, проскроллил этот блок в статье) Дурная привычка читать по диагонали. Круто, спасибо.
UFO just landed and posted this here
В сценарии было предусмотрено создание новых сцщностей

  • 936 новостей;
  • 110 736 сообщений в живой ленте;
  • 112 440 комментариев;
  • 10 560 чатов;
  • 81 264 мгновенных сообщений;
  • 55 128 заданий бизнес-процессов;
  • 21 888 задач;
  • 8 808 документов;
  • 2 208 рабочих групп и проектов;
  • 6 984 встреч в календарях;
  • 57 240 уведомлений.

UFO just landed and posted this here
чтобы кластер был высокопроизводительным, устойчивым к сбоям

И где же здесь устойчивость к сбоям?
Возможность продолжить работу, при падение одной из нод, к тому же запас мощности позволяет работать более стабильно.
Я к тому, что балансировщик и Мастер БД в BitrxEnv являются незарезервированными точками отказа. То есть с падением конкретной ноды ещё должно повезти. «Устойчивой к сбоям» я бы такую систему не называл.
В тесте балансировщик и мастер БД находились в разных пулах и физически на разных машинах. Что исключало их взаимное влияние.
  • балансировщик достаточно простая роль, которую легко вынести отдельно. Проблем с ним обычно нету. В данном тесте не было задачи построит максимально устойчивую к сбоям систему.
  • мастер-мастер БД BitrixEnv из коробки (в скриптах администрирования) не поддерживает, но настроить можно
  • конфигурация мастер — слайв дает возможность продолжить работу на слайве с минимальным простоем.
В тесте использовали максимально стандартный вариант установки на базе BitrixEnv. В нем же apache используется в основно из за htaccess. Без него администрирование становится немного сложнее и приходится следить за возможными изменениями в продукте.

Для других же проектов активно используем php-fpm, и в целом поддерживаем его применение.
У меня тогда провокационный вопрос, может Вы в курсе. Почему битрикс до сих пор хранит все файлы в document root? Можно же даже с обратной совместимостью сделать папку public и в ней один файл index.php с нормальным роутингом как у всех, а все остальное оставить выше. Тогда бы не было проблем с кучей htaccess и конфиг ngnix был бы неизменным. Это надо было сделать еще лет 10 назад, но может есть подвижки в эту сторону?
И еще вопрос: почему не используете решения сообщества, обкатанные всем миром, а пишете велосипеды. Т.е. место того, чтобы взять популярную ORM и на базе нее построить свое решение, сделали какую-то неюзабельную штуку на массивах. Как я понимаю, в битриксе вообще ни одного пакета, установленного через composer нет…
В общем ждем битрикс2.0 на симфони, иначе я не очень понимаю, как вы дальше будете развивать свой продукт.
Модное — не всегда разумное.

Хранение файлов в document root — для простоты, лучшего понимания людьми и удобства использования.
не используете решения сообщества, обкатанные всем миром, а пишете велосипеды
— посмотрите, какой срок поддержки решений в опенсорсе. Что потом? Правильно — серьезно переписывать.
Как я понимаю, в битриксе вообще ни одного пакета, установленного через composer нет…
— а зачем это делать, зачем начинать зависеть от стороннего пакета, если нет прямой необходимости? А если пакет перестанут поддерживать, внезапно?
В общем ждем битрикс2.0 на симфони, иначе я не очень понимаю, как вы дальше будете развивать свой продукт.
— развивать так же успешно, как и предыдущие 20 лет. Но открытые фреймворки хороши для простых задач, не спорю.
Если даже популярное решение забросят, что маловероятно (Doctrine ORM?) его всегда можно форкнуть и развивать самостоятельно.
Насчет композера: кроме удобства управления пакетами у него есть очень важная штука — автолоадинг. Т.е. при обслуживании запроса приложение не заставляет интерпретатор все классы приложения интерпретировать и держать в памяти, а только те, что используются. Я конечно видел у вас штуку типа loadModule, но это все равно грубо, при запросе я так понимаю большая часть ядра грузиться в память.
Просто мне кажется, отворачиваться от сообщества не самая лучшая идея. Использование композера это не модно, это реально удобно и правильно. Вы можете в композер засовывать свои пакеты и ни от кого не зависеть. А популярные пакеты хорошо документированы и у многих есть опыт с ними.
Как успешный пример посмотрите на эту ПИМ+ЦМС систему pimcore.com/en
Она сейчас сильно набирает популярность, просто пока на западе. Посмотрите на их документацию, инструменты для деплоя из коробки.
Для использования autoload не обязательно использовать composer.
После подключения модуля весь модуль не подключаются, классы модуля при необходимости подгружаются через тот же autoload.
Продукт развивается постоянно и целенаправленно
Хорошо, можете с ходу сказать, как мне через вашу orm создать запрос с функцией JSON_CONTAINS?
В опенсорс решениях это давно все либо есть из коробки, либо можно удобно писать sqlRaw и выглядело бы это примерно так:
->andWhere(new Expression('JSON_CONTAINS(categories, 2'));

с вашей орм я чуть с ума не сошел, код показывать не буду. Либо документация неполная, либо действительно момент с rawSql не продуман.
Да на данный момент подобный запрос не очень удобно делать в ORM.
На данный момент подготовили исправление и в одном из ближайших обновлений выйдет возможность делать подобные запросы через

$q->whereExpr('JSON_CONTAINS(%s, 2)', ['categories']);
Вот об этом и речь :) Когда я смотрел исходники вашей orm, почему-то казалось, что вашим разработчикам отключили доступ в интернет. Окей, допустим есть какие-то причины не брать готовые решения, но ведь можно изучить готовые и сделать как минимум не хуже. Ведь все опенсорс решения прошли определенный путь, решили кучу проблем и обошли грабли. Писать с нуля orm без большого опыта с другими решениями — опрометчиво.

Я люблю велосипеды, но прежде чем писать свой — изучаю исходники других более-менее популярных решений и много нового для себя узнаю. В противном случае я бы это узнал уже в процессе эксплуатации своего велосипеда. В вашем же случае вообще нельзя допускать архитектурных ошибок, т.к. это юзерспейс, это будут использовать разработчики, все должно быть продумано на берегу.
С серверной стороной понятно. А клиентскую производительность тестировали? В конечном итоге клиентская часть может вносить больше тормозов, чем серверная для пользователя.
В рамках данного теста клиентская часть не тестировалась.
Но ее внимание на скорость в целом понимаем и следим за ней.
А сколько на эту работу было потрачено времени и человеко-часов, не измеряли?
Sign up to leave a comment.