Смотря что именно Вы подразумеваете под словами Open source.
Если открытый исходный код, то можно скачать с нашего сайта коробочную версию «Корпоративного портала» (демо). Там PHP, и код открыт.
Если подразумевается в том числе и бесплатность — тогда не думаю, что есть полностью такой же функционал. Частями — да, конечно. И таск-менеджеры, и CRM… Но весь комплекс — вряд ли.
> когда можно просто мастеру в первом дц дать слейв во в ором, а мастеру во втором — слейв в первом.
Правильно ли я понимаю, что подразумеваются разные роли для всех слейвов и мастеров? То есть, 4 сервера, а не 2 (как у нас)?
А зачем тогда? Расходов больше, а надежности не добавляет (в случае падения мастера надо слейв переключать в роль мастера, лишние действия).
Постгрес — не рассматривали. Две главные причины:
1. Делали все на собственной платформе, которая PostgreSQL не поддерживает (практически не востребовано клиентами и партнерами).
2. Делали на том, что сами знаем лучше всего. Может быть, архитектурно постгрес и лучше (просто не знаю всех нюансов), но если администрировать его будут люди без квалификации и опыта работы именно с ним — получится заведомо хуже.
Недостаточно гибкая система (нет полноценного root в базе). Для нас оказалось критично.
Непрозрачно работает.
Как следствие — риск долгого даунтайма (когда молния попала в европейский ДЦ, многие клиентские RDS долго лежали).
На схеме нарисовано по одному серверу, реально же — больше. Несколько в каждом.
Если сервер падает, траффик переключается на другой ДЦ. В самом худшем случае — пользователи будут 1-2 минуты (время переключения) видеть сообщение об ошибке. Дальше — продолжат работу в другом ДЦ.
После восстановления — траффик переключается обратно.
2. Список хостеров — в основном, для небольших и средних проектов. Shared хостинг, VPS… Проекты уровня нашего собственного сайта — это всегда индивидуальное решение.
Коллеги, огромное спасибо за все отзывы и замечания! :)
Несмотря на дух и настрой некоторых комментариев :), очевидно, что тема поста крайне важна. А информация — для многих полезна. Добавление 107 раз в избранное — как раз говорит об этом. :)
Вы совершенно правы. Хостинг надо настраивать. Под любую систему. Неважно, Битрикс это или нет.
И Битрикс, точно так же, как и любая другая система, скорее всего, встанет и будет работать на среднестатистическом хостинге с дефолтными настройками. Только максимума производительности не даст.
Спасибо за интерес!
Если открытый исходный код, то можно скачать с нашего сайта коробочную версию «Корпоративного портала» (демо). Там PHP, и код открыт.
Если подразумевается в том числе и бесплатность — тогда не думаю, что есть полностью такой же функционал. Частями — да, конечно. И таск-менеджеры, и CRM… Но весь комплекс — вряд ли.
* * *
Расскажите, пожалуйста, что именно тормозит? Для нас это очень важно.
Основной сайт www.bitrix24.ru или какой-то уже заведенный проект *.bitrix24.ru? Если второе — то какие-то отдельные страницы или в целом?
Основной сайт www.bitrix24.ru или какой-то уже заведенный проект *.bitrix24.ru? Если второе — то какие-то отдельные страницы или в целом?
Правильно ли я понимаю, что подразумеваются разные роли для всех слейвов и мастеров? То есть, 4 сервера, а не 2 (как у нас)?
А зачем тогда? Расходов больше, а надежности не добавляет (в случае падения мастера надо слейв переключать в роль мастера, лишние действия).
Постгрес — не рассматривали. Две главные причины:
1. Делали все на собственной платформе, которая PostgreSQL не поддерживает (практически не востребовано клиентами и партнерами).
2. Делали на том, что сами знаем лучше всего. Может быть, архитектурно постгрес и лучше (просто не знаю всех нюансов), но если администрировать его будут люди без квалификации и опыта работы именно с ним — получится заведомо хуже.
Одинаковых… Покажите, пожалуйста, примеры?
2. m-m репликация не ложится.
Да, конечно, могут быть какие-то отдельные модули (особенно собственной разработки), в которых те или иные конфликты могут возникать.
Но, как вы сами заметили ниже, если речь идет именно про наш (Битрикса) функционал, все проблемы достаточно оперативно фиксятся.
Обязательно расскажем!
И вот как раз вышла с тем же дизайном, что и в Битрикс24: www.1c-bitrix.ru/about/life/news/430668/
Недостаточно гибкая система (нет полноценного root в базе). Для нас оказалось критично.
Непрозрачно работает.
Как следствие — риск долгого даунтайма (когда молния попала в европейский ДЦ, многие клиентские RDS долго лежали).
Неаккуратненько как-то. Поправим.
Если сервер падает, траффик переключается на другой ДЦ. В самом худшем случае — пользователи будут 1-2 минуты (время переключения) видеть сообщение об ошибке. Дальше — продолжат работу в другом ДЦ.
После восстановления — траффик переключается обратно.
Тут — подробно: dev.1c-bitrix.ru/community/blogs/howto/2450.php
Сейчас — не выдержала Хабраэффекта?
Точно.
1. Веб-кластер у нас используется.
2. Список хостеров — в основном, для небольших и средних проектов. Shared хостинг, VPS… Проекты уровня нашего собственного сайта — это всегда индивидуальное решение.
Какая связь исходного поста и Вашего текста?
Несмотря на дух и настрой некоторых комментариев :), очевидно, что тема поста крайне важна. А информация — для многих полезна. Добавление 107 раз в избранное — как раз говорит об этом. :)
И Битрикс, точно так же, как и любая другая система, скорее всего, встанет и будет работать на среднестатистическом хостинге с дефолтными настройками. Только максимума производительности не даст.
Как и любая другая система.
2. Тех. поддержка по веб-окружению — на форуме разработчиков: dev.1c-bitrix.ru
3. Нужно смотреть монитор производительности, где именно узкие места. Скорее всего — диск. Нужны детали.
Но в целом для приложений, использующих PHP+MySQL, производительность на Windows платформе всегда ниже.