Внимание, под катом много текста и скриншотов!
Фото:
|
Разработчикам |
Последние сообщения блогов
Новое отраслевое решение для медицины: "1С-Битрикс: Портал органа управления здравоохранением"
31.08.201111:5731.08.2011 11:57:43
Компания 1С-Битрикс представляет еще одно решение для сферы здравоохранения.
Внимание, под катом много текста и скриншотов!
Внимание, под катом много текста и скриншотов!
Большое обновление решения "Сайт медицинской организации"
19.08.201113:2619.08.2011 13:26:25
Всем привет!
Новости с полей от команды разработки медицинских решений 1С-Битрикс.
В апреле 2011 года наша компания на рынок специализированное решение для создания готового сайта медицинской организации (государственной или коммерческой). Решение оказалось востребованным и летом мы провели большую работу по улучшению его возможностей и сегодня готовы предложить потребителю обновленную версию.
Внимание, под катом очень много скриншотов!
Новости с полей от команды разработки медицинских решений 1С-Битрикс.
В апреле 2011 года наша компания на рынок специализированное решение для создания готового сайта медицинской организации (государственной или коммерческой). Решение оказалось востребованным и летом мы провели большую работу по улучшению его возможностей и сегодня готовы предложить потребителю обновленную версию.
Внимание, под катом очень много скриншотов!
Фото:
Новые события, кастомизированные обработчики экспорта/импорта
09.08.201112:4109.08.2011 12:41:22
освещал функционал с точки зрения пользователя. Теперь то, что касается разработчиков.
02.08.2011: Обновление
03.08.201110:5403.08.2011 10:54:23
Рассмотрим описание обновления модуля Информационные блоки 10.0.9. Кстати, это обновление вышло в связке с обновлением модуля Торговый каталог 10.0.5. Подробности 10.0.5 торгового каталога опубликованы автором .
Фото:
Профили экспорта/импорта, Яндекс-агент
29.07.201119:1229.07.2011 19:12:40
В ближайшее время выходит небольшое обновление модуля Торгового каталога. В нем исправлен ряд ошибок и улучшена работа с профилями экспорта и импорта торгового каталога. Но обо всем по порядку.
Фото:
Обсуждаем чеклист контроля качества внедрения
27.07.201116:5227.07.2011 16:52:44
Уважаемые коллеги!
Давайте вместе обсудим чеклист контроля качества внедрения, которые мы планируем выпустить в ближайшем релизе продукта. Пункты чеклиста разбиты на группы: «Интеграция дизайна и разработка», «Размещение на хостинге», «Производительность», «Безопасность», «Сдача проекта». Серые пункты - необязательные, черные – обязательные для заполнения. Проверка по ряду пунктов будет автоматизирована (постараемся постепенно автоматизировать большинство пунктов). Многие пункты будут содержать ссылки на методические материалы на наших сайтах. Также, можно будет добавлять собственные обязательные пункты, путем редактирования конфигурационного файла проекта.
Пожалуйста, высказывайте ваши замечания и предложения, основанные на опыте внедрений. Все предложения будут тщательно рассмотрены и прокомментированы. Кто стесняется - пишите плз. «в личку» или на serbul@1c-bitrix.ru.
Для углубленного обсуждения чеклиста !
Вот также - тут вы найдете причины и идеи чеклиста, и (доклады первого дня, "Контроль качества внедрения - ключевое изменение версии 10.5").
Прототипы интерфейсов:
Список тестов чеклиста контроля качества внедрения:
Интеграция дизайна и разработка/Интеграция дизайна
(QD0010) Сайт проекта добавлен и корректно настроен: выбран тип многосайтовой конфигурации, настроены доменные имена, кодировка сайта, формат даты и времени, язык.
Подробнее:
(QD0020) Созданы и настроены шаблоны сайта (выделен header/footer, через вызовы API устанавливаются заголовок страницы, метаданные, кодировка, стили страницы, административная панель, демаркированы включаемые и рекламные области).
Подробнее:
(QD0030) Настроены все типы меню.
Подробнее:
Рекомендуется использование стандартных компонентов (с кэшированием) – «bitrix:menu».
(QD0040) Поддерживается возможность редактирования объектов шаблона сайта в публичной части с помощью технологий "Эрмитаж" (не заходя в административный раздел).
Подробнее:
(QD0050) Настроена цепочка навигации (строится автоматически).
Подробнее:
Рекомендуется использование стандартных компонентов – «bitrix:breadcrumb».
(QD0060) Настроено формирование карты сайта (строится автоматически).
Подробнее:
Рекомендуется использование стандартных компонентов – «bitrix:main.map».
(QD0070) Свойства страниц и разделов, редактируемые администратором, позволяют управлять характеристиками веб-страниц проекта - названием, описанием, мета-тэгами и т.п.
Подробнее:
(QD0080) Настроены шаблоны типовых страниц и включаемых областей (для быстрого создания по шаблону) для удобства работы контент-редактора.
(QD0090) Заданы имена стилям, которые появляются в визуальном редакторе для удобства работы контент-редактора.
Подробнее:
(QD0100) В визуальном редакторе настроены сниппеты - необходимые для эффективного создания контента.
Подробнее:
(QD0110) Создана группа редакторов контента, которые имеют возможность создавать страницы и разделы, добавлять/изменять меню, изменять включаемые области, метаданные страницы, размещать на странице и редактировать настройки компонентов.
Подробнее:
(QD0120) Управление специфичными для проекта свойствами страниц и разделов, включаемыми областями, расширенными свойствами меню - описаны в техдокументации к проекту.
Интеграция дизайна и разработка/Интеграция структур данных
(QM0010) Созданы и настроены необходимые для проекта типы информационных блоков. Созданы и настроены необходимые для проекта информационные блоки. Путем анализа ожидаемого объема данных и нагрузки выбран подходящий тип инфоблоков (1.0 или 2.0), настроены свойства и другие параметры инфоблоков.
Подробнее:
(QM0020) Настроены адаптированные под задачи проекта формы редактирования элементов инфоблоков и их списков в административном разделе, установленные по умолчанию для всех пользователей проекта.
Подробнее:
Интеграция дизайна и разработка/Интеграция стандартных компонентов и модулей
(QS0010) Настроены стандартные модули, требуемые для выполнения задач проекта.
Подробнее:
(QS0020) На страницах проекта размещены и настроены стандартные компоненты (рекомендуются компоненты 2.0). Установлено кэширование в режим "Авто+Управляемое" или "Авто".
Подробнее:
(QS0030) Обеспечена работа интерфейсов "Эрмитаж" с компонентами в публичной части для редактора контента:
- добавление/редактирование объектов «над сайтом»
- редактирование параметров компонентов
Подробнее:
(QS0040) Для изменения внешнего вида стандартных компонентов используется копирование шаблонов компонентов в шаблоны проекта и их модификация.
Подробнее:
Интеграция дизайна и разработка/Интеграция собственных компонентов и модулей
(QC0010) (MVC) Разработаны собственные компоненты 2.0 проекта, размещенные в отдельном пространстве имен.
Подробнее:
(QC0020) (FRONT CONTROLLER) Для создания сложного функционала или многостраничных представлений используются комплексные компоненты.
Подробнее:
(QC0030) (INTERFACE) Из компонентов вынесены в их настройки наиболее часто изменяемые параметры - для обеспечения повторного использования компонента в этом и других проектах без модификации кода компонента и его шаблона. Параметры компонентов и их допустимые значения – описаны либо в интерфейсе настройки компонента в публичной части сайта, либо в техдокументации к проекту.
Подробнее:
(QC0040) (CACHE) В собственных компонентах используется управляемое кэширование в режиме "Авто+Управляемое" с установкой длительного периода кэширования (1-12 месяцев) или "Авто" кэширование.
Подробнее:
(QC0050) (CACHE) В режиме кэширования компоненты не выполняют запросы к базе данных или выполняют только те запросы, кэширование которых является нерациональным.
Подробнее:
(QC0060) (CACHE) Компонент не сохраняет избыточные данные в кэш. При неверном ключе кэша – данные не кэшируются и не используются повторно (для предотвращения переполнения кэша злоумышленником). Объем файла кэша компонента не превышает 1МБ.
Подробнее:
(QC0070) (CONTROLLER) PHP-код компонента оптимизирован по расходу оперативной памяти и процессоров. На PHP не выполняются большие сортировки или обработки больших массивов. Компонент профилировался встроенным отладчиком платформы.
Подробнее:
(QC0080) (MODEL) Число и сложность запросов к базе данных в компоненте адекватны решаемой задаче (параметр замеряется при отключенном кэшировании компонента). Выполняемые компонентом запросы профилированы встроенным SQL-отладчиком.
Подробнее:
(QC0090) (MODEL) В компонентах и их шаблонах не используются прямые запросы к базе данных. Работа с базой данных выполняется через API функции платформы Битрикс. Запросы к специфичным для проекта таблицам в базе данных выполняются через класс CDatabase (это необходимо для работы подсистемы отладки, мониторинга и кластеризации).
Подробнее:
(QC0100) (VIEW) Шаблон компонента максимально облегчен и содержит преимущественно логику для формирования верстки (представления).
Подробнее:
(QC0110) При разработке собственных компонентов 2.0 использовались рекомендации по написанию кода от Битрикс.
Подробнее:
(QC0120) При выполнении страниц и вспомогательных скриптов проекта отсутствуют предупреждения (E_WARNING) PHP.
Подробнее:
(QC0130) Созданный для проекта программный код средней и высокой сложности оформлен в виде отдельного подключаемого модуля платформы Битрикс.
Подробнее:
(QC0140) Используются обработчики событий для расширения функционала платформы без модификации ядра. Обработчики описаны в техдокументации к проекту, либо тщательно документированы в файлах настройки проекта.
Подробнее:
(QC0150) На контентных страницах проекта и во включаемых областях, доступных для редактирования визуальным редактором, отсутствует прямое включение PHP кода. Код должен находиться только внутри компонентов.
Подробнее:
(QC0160) Разметка, возвращаемая компонентом и включаемой областью, должна возвращать целостный html-блок с закрытыми тэгами. Например, компонент должен возвращать таблицу целиком (неправильно, когда до вызова компонента вставляется заголовок таблицы, компонент возвращает строки и ячейки таблицы, а после вызова компонента вставлен закрывающий тэг таблицы).
Интеграция дизайна и разработка/Дополнительно
(QE0010) Специфичные для проекта периодические операции (агенты) настроены, а рекомендации по интервалам их запуска описаны в техдокументации проекта.
Подробнее:
(QE0020) Для комплексной настройки функционала проекта используется технология мастеров.
Подробнее:
(QE0030) Для управления нестандартными разделами и объектами проекта используется технология собственных административных разделов.
Подробнее:
(QE0040) Используются SEO URL в кастомных и стандартных компонентах.
Подробнее:
Размещение на хостинге
(QH0010) Введена информация о хостинге, тарифном плане и аппаратной конфигурации проекта.
Подробнее:
(QH0020) Для правильной настройки программного обеспечения хостинга использован пакет «1С-Битрикс: Веб-окружение» (для Windows и Linux), либо «1С-Битрикс: Виртуальная машина», либо выбран тарифный план для Битрикс, предоставляемый одним из хостинг-партнеров.
Подробнее:
(QH0030) Отсутствуют замечания в разделе "Инструменты/Проверка сайта" на вкладках: "Обязательные параметры", "Проверка доступа (полная проверка)", "Тестирование конфигурации".
Подробнее:
(QH0040) При использовании двухуровневой конфигурации (напр. nginx+apache или балансировщика на веб-кластере) в модуль «Веб-аналитика» передается корректный IP-адрес клиента.
(QH0050) Проверено, что настроено и выполняется систематическое резервное копирование файлов и базы данных проекта.
(QH0060) Настроена почтовая подсистема хостинга. Успешно отправлено тестовое письмо через API платформы Битрикс.
Производительность
(QP0010) Для обеспечения максимальной производительностии использован пакет «1С-Битрикс: Веб-окружение» (для Windows и Linux), либо «1С-Битрикс: Виртуальная машина», либо выбран тарифный план для Битрикс, предоставляемый одним из рекомендуемых хостинг-партнеров. Используется двух-уровневая конфигурация фронтэнд-бэкэнд.
Подробнее:
(QP0020) PHP сконфигурирован оптимально. В административном разделе: "Настройки/Производительность/Панель производительности/Конфигурация" в строке «Конфигурация PHP» в колонке «Оценка» должно появиться значение - «оптимально». Обязательно использование прекомпилятора PHP с адекватным объемом памяти – eaccelerator, xcache, apc, ZendOptimizer+ (часто используемые исполняемые файлы проекта должны помещаться в opcode-кэш прекомпилятора).
Подробнее:
(QP0030) Включено «Автокэширование» в разделе «Настройки/Настройки продукта/Автокэширование/Кэширование компонентов».
(QP0040) Инфраструктура платформы сконфигурирована для максимальной производительности. В административном разделе: "Настройки/Производительность/Панель производительности/Битрикс" в колонке «Рекомендации» должны быть выполнены все рекомендации по улучшению производительности платформы. Название вкладки станет - «Битрикс (оптимально)».
(QP0050) Производительность конфигурации адекватна требованиям проекта и составляет #N# (#расшифровка#)* - «Настройки/Производительность/Панель производительности/Конфигурация»:
- Нажимаем «Тестировать конфигурацию»
- Результат после проведения замеров появляется в колонке «Оценка» строки «Конфигурация»
* «Низкая» – (<=15), «Удовлетворительная» - >15 и <30, «Высокая» - >=30.
Подробнее:
(QP0060) Выполнен нагрузочный тест максимальной производительности проекта - "Настройки/Производительность/Панель производительности/Масштабируемость" с исходными данными:
- Начальное количество одновременных соединений = 1
- Конечное количество одновременных соединений = 5
- Шаг увеличения одновременных соединений = 1
- Максимальная продолжительность теста = 5 минут
- Страница = главная проекта (например - /index.php)
Время генерации страницы не должно превышать 0.5 секунды и не должно деградировать при увеличении количества одновременных соединений во время теста. Число ошибок должно быть равно нулю. Минимальное число страниц в секунду должно соответствовать ожидаемой пиковой посещаемости проекта в сутки (хитов в сутки), деленной на 86400. Минимальное время получения страницы не должно превышать 1 секунды.
(QP0070) Выполнен аудит производительности основных страниц проекта:
- На административной странице «Настройки/Производительность/Панель производительности» нажимаем «Тестировать производительность» в течение 10 минут
- Кликаем по основным страницам публичной части. Рекомендуется привлечь к тестированию как можно больше сотрудников или использовать инструменты нагрузки типа JMeter.
- После завершения теста анализируем результаты на вкладке «Разработка»: результаты в колонке «Среднее время (сек)» не должны превышать 0.5 сек, в колонке «Ошибки разработки» не должно быть сообщений об ошибках.
(QP0080) Расставлены индивидуальные индексы в инфоблоках 2.0 для увеличения скорости выборки данных.
Подробнее:
(QP0090) HTML кэширование включено для небольших, редко изменяемых проектов в разделе «Настройки/Настройки продукта/Автокэширование/HTML кэш».
Подробнее:
(QP0100) Настроен и сконфигурирован веб-кластер в соответствии с руководством (для высоконагруженных проектов или систем, которым требуется высокая надежность).
Подробнее:
Безопасность
(QSEC0010) Система соответствует уровню безопасности – «Стандартный» (включен проактивный фильтр, контроль активности, повышенный уровень безопасности администраторов и т.п.) или выше.
Подробнее:
«Настройки/Проактивная защита/Панель безопасности»
(QSEC0020) Административные учетные записи имеют повышенный уровень безопасности. По возможности, для них используется технология двухфакторной авторизации (OTP).
Подробнее:
-
(QSEC0030) Настроены права групп пользователей системы и протестированы их возможности в административном разделе системы после авторизации ("/bitrix/admin" . Все «лишнее» должно быть недоступно.
Подробнее:
(QSEC0040) Удалены тестовые учетные записи разработчиков. Удалены тестовые данные и страницы.
(QSEC0045) Файлы данных и страницы веб-проекта, содержащие конфиденциальную информацию (в т.ч. персональные данные Клиентов), закрыты от неавторизованного доступа и от индексации поисковыми роботами. Для дополнительной защиты персональных данных Клиентов при их передаче по сети, в случае необходимости, используется SSL.
(QSEC0050) Для соединения с базой данных на хостинге используется сильный пароль, настроены необходимые проекту привилегии для работы с базой данных (работа не под root).
(QSEC0060) Отключен вывод ошибок и предупреждений посетителям проекта.
Подробнее:
$DBDebug - отключен (dev.1c-bitrix.ru/api_help/main/general/magic_vars.php)
"Настройки/Настройки продукта/Настройки модулей/Главный модуль: Режим вывода ошибок" -> "Не выводить"
(QSEC0070) Настроен журнал системных событий.
Подробнее:
«Настройки/Инструменты/Журнал событий»
- закладка «Журнал событий»
(QSEC0080) Компьютер администраторов системы защищен:
- установлено актуальное антивирусное ПО, регулярно проводится полная антивирусная проверка
- пароли от системы (ftp, ssh, БД, админка битрикс и т.п.) не сохраняются в клиентских программах: браузере, ФТП клиенте и т.п.
- каждый администратор должен иметь свой уникальный логин-пароль
Сдача проекта
(QJ0010) Лицензионный ключ активирован, загружены исходные тексты ядра.
Подробнее:
(QJ0020) Ядро проекта не модифицировалось. В любое время можно обновить платформу через систему обновлений, не нарушив работоспособность проекта.
Подробнее:
(QJ0030) Введена информация о партнере (произвольное текстовое поле и логотип) или компании, которая провела интеграцию и внедрение решения на платформе Битрикс.
(QJ0040) Введена информация о техподдержке проекта (произвольное текстовое поле и логотип).
Давайте вместе обсудим чеклист контроля качества внедрения, которые мы планируем выпустить в ближайшем релизе продукта. Пункты чеклиста разбиты на группы: «Интеграция дизайна и разработка», «Размещение на хостинге», «Производительность», «Безопасность», «Сдача проекта». Серые пункты - необязательные, черные – обязательные для заполнения. Проверка по ряду пунктов будет автоматизирована (постараемся постепенно автоматизировать большинство пунктов). Многие пункты будут содержать ссылки на методические материалы на наших сайтах. Также, можно будет добавлять собственные обязательные пункты, путем редактирования конфигурационного файла проекта.
Пожалуйста, высказывайте ваши замечания и предложения, основанные на опыте внедрений. Все предложения будут тщательно рассмотрены и прокомментированы. Кто стесняется - пишите плз. «в личку» или на serbul@1c-bitrix.ru.
Для углубленного обсуждения чеклиста !
Вот также - тут вы найдете причины и идеи чеклиста, и (доклады первого дня, "Контроль качества внедрения - ключевое изменение версии 10.5").
Прототипы интерфейсов:
Список тестов чеклиста контроля качества внедрения:
Интеграция дизайна и разработка/Интеграция дизайна
(QD0010) Сайт проекта добавлен и корректно настроен: выбран тип многосайтовой конфигурации, настроены доменные имена, кодировка сайта, формат даты и времени, язык.
Подробнее:
(QD0020) Созданы и настроены шаблоны сайта (выделен header/footer, через вызовы API устанавливаются заголовок страницы, метаданные, кодировка, стили страницы, административная панель, демаркированы включаемые и рекламные области).
Подробнее:
(QD0030) Настроены все типы меню.
Подробнее:
Рекомендуется использование стандартных компонентов (с кэшированием) – «bitrix:menu».
(QD0040) Поддерживается возможность редактирования объектов шаблона сайта в публичной части с помощью технологий "Эрмитаж" (не заходя в административный раздел).
Подробнее:
(QD0050) Настроена цепочка навигации (строится автоматически).
Подробнее:
Рекомендуется использование стандартных компонентов – «bitrix:breadcrumb».
(QD0060) Настроено формирование карты сайта (строится автоматически).
Подробнее:
Рекомендуется использование стандартных компонентов – «bitrix:main.map».
(QD0070) Свойства страниц и разделов, редактируемые администратором, позволяют управлять характеристиками веб-страниц проекта - названием, описанием, мета-тэгами и т.п.
Подробнее:
(QD0080) Настроены шаблоны типовых страниц и включаемых областей (для быстрого создания по шаблону) для удобства работы контент-редактора.
(QD0090) Заданы имена стилям, которые появляются в визуальном редакторе для удобства работы контент-редактора.
Подробнее:
(QD0100) В визуальном редакторе настроены сниппеты - необходимые для эффективного создания контента.
Подробнее:
(QD0110) Создана группа редакторов контента, которые имеют возможность создавать страницы и разделы, добавлять/изменять меню, изменять включаемые области, метаданные страницы, размещать на странице и редактировать настройки компонентов.
Подробнее:
(QD0120) Управление специфичными для проекта свойствами страниц и разделов, включаемыми областями, расширенными свойствами меню - описаны в техдокументации к проекту.
Интеграция дизайна и разработка/Интеграция структур данных
(QM0010) Созданы и настроены необходимые для проекта типы информационных блоков. Созданы и настроены необходимые для проекта информационные блоки. Путем анализа ожидаемого объема данных и нагрузки выбран подходящий тип инфоблоков (1.0 или 2.0), настроены свойства и другие параметры инфоблоков.
Подробнее:
(QM0020) Настроены адаптированные под задачи проекта формы редактирования элементов инфоблоков и их списков в административном разделе, установленные по умолчанию для всех пользователей проекта.
Подробнее:
Интеграция дизайна и разработка/Интеграция стандартных компонентов и модулей
(QS0010) Настроены стандартные модули, требуемые для выполнения задач проекта.
Подробнее:
(QS0020) На страницах проекта размещены и настроены стандартные компоненты (рекомендуются компоненты 2.0). Установлено кэширование в режим "Авто+Управляемое" или "Авто".
Подробнее:
(QS0030) Обеспечена работа интерфейсов "Эрмитаж" с компонентами в публичной части для редактора контента:
- добавление/редактирование объектов «над сайтом»
- редактирование параметров компонентов
Подробнее:
(QS0040) Для изменения внешнего вида стандартных компонентов используется копирование шаблонов компонентов в шаблоны проекта и их модификация.
Подробнее:
Интеграция дизайна и разработка/Интеграция собственных компонентов и модулей
(QC0010) (MVC) Разработаны собственные компоненты 2.0 проекта, размещенные в отдельном пространстве имен.
Подробнее:
(QC0020) (FRONT CONTROLLER) Для создания сложного функционала или многостраничных представлений используются комплексные компоненты.
Подробнее:
(QC0030) (INTERFACE) Из компонентов вынесены в их настройки наиболее часто изменяемые параметры - для обеспечения повторного использования компонента в этом и других проектах без модификации кода компонента и его шаблона. Параметры компонентов и их допустимые значения – описаны либо в интерфейсе настройки компонента в публичной части сайта, либо в техдокументации к проекту.
Подробнее:
(QC0040) (CACHE) В собственных компонентах используется управляемое кэширование в режиме "Авто+Управляемое" с установкой длительного периода кэширования (1-12 месяцев) или "Авто" кэширование.
Подробнее:
(QC0050) (CACHE) В режиме кэширования компоненты не выполняют запросы к базе данных или выполняют только те запросы, кэширование которых является нерациональным.
Подробнее:
(QC0060) (CACHE) Компонент не сохраняет избыточные данные в кэш. При неверном ключе кэша – данные не кэшируются и не используются повторно (для предотвращения переполнения кэша злоумышленником). Объем файла кэша компонента не превышает 1МБ.
Подробнее:
(QC0070) (CONTROLLER) PHP-код компонента оптимизирован по расходу оперативной памяти и процессоров. На PHP не выполняются большие сортировки или обработки больших массивов. Компонент профилировался встроенным отладчиком платформы.
Подробнее:
(QC0080) (MODEL) Число и сложность запросов к базе данных в компоненте адекватны решаемой задаче (параметр замеряется при отключенном кэшировании компонента). Выполняемые компонентом запросы профилированы встроенным SQL-отладчиком.
Подробнее:
(QC0090) (MODEL) В компонентах и их шаблонах не используются прямые запросы к базе данных. Работа с базой данных выполняется через API функции платформы Битрикс. Запросы к специфичным для проекта таблицам в базе данных выполняются через класс CDatabase (это необходимо для работы подсистемы отладки, мониторинга и кластеризации).
Подробнее:
(QC0100) (VIEW) Шаблон компонента максимально облегчен и содержит преимущественно логику для формирования верстки (представления).
Подробнее:
(QC0110) При разработке собственных компонентов 2.0 использовались рекомендации по написанию кода от Битрикс.
Подробнее:
(QC0120) При выполнении страниц и вспомогательных скриптов проекта отсутствуют предупреждения (E_WARNING) PHP.
Подробнее:
(QC0130) Созданный для проекта программный код средней и высокой сложности оформлен в виде отдельного подключаемого модуля платформы Битрикс.
Подробнее:
(QC0140) Используются обработчики событий для расширения функционала платформы без модификации ядра. Обработчики описаны в техдокументации к проекту, либо тщательно документированы в файлах настройки проекта.
Подробнее:
(QC0150) На контентных страницах проекта и во включаемых областях, доступных для редактирования визуальным редактором, отсутствует прямое включение PHP кода. Код должен находиться только внутри компонентов.
Подробнее:
(QC0160) Разметка, возвращаемая компонентом и включаемой областью, должна возвращать целостный html-блок с закрытыми тэгами. Например, компонент должен возвращать таблицу целиком (неправильно, когда до вызова компонента вставляется заголовок таблицы, компонент возвращает строки и ячейки таблицы, а после вызова компонента вставлен закрывающий тэг таблицы).
Интеграция дизайна и разработка/Дополнительно
(QE0010) Специфичные для проекта периодические операции (агенты) настроены, а рекомендации по интервалам их запуска описаны в техдокументации проекта.
Подробнее:
(QE0020) Для комплексной настройки функционала проекта используется технология мастеров.
Подробнее:
(QE0030) Для управления нестандартными разделами и объектами проекта используется технология собственных административных разделов.
Подробнее:
(QE0040) Используются SEO URL в кастомных и стандартных компонентах.
Подробнее:
Размещение на хостинге
(QH0010) Введена информация о хостинге, тарифном плане и аппаратной конфигурации проекта.
Подробнее:
(QH0020) Для правильной настройки программного обеспечения хостинга использован пакет «1С-Битрикс: Веб-окружение» (для Windows и Linux), либо «1С-Битрикс: Виртуальная машина», либо выбран тарифный план для Битрикс, предоставляемый одним из хостинг-партнеров.
Подробнее:
(QH0030) Отсутствуют замечания в разделе "Инструменты/Проверка сайта" на вкладках: "Обязательные параметры", "Проверка доступа (полная проверка)", "Тестирование конфигурации".
Подробнее:
(QH0040) При использовании двухуровневой конфигурации (напр. nginx+apache или балансировщика на веб-кластере) в модуль «Веб-аналитика» передается корректный IP-адрес клиента.
(QH0050) Проверено, что настроено и выполняется систематическое резервное копирование файлов и базы данных проекта.
(QH0060) Настроена почтовая подсистема хостинга. Успешно отправлено тестовое письмо через API платформы Битрикс.
Производительность
(QP0010) Для обеспечения максимальной производительностии использован пакет «1С-Битрикс: Веб-окружение» (для Windows и Linux), либо «1С-Битрикс: Виртуальная машина», либо выбран тарифный план для Битрикс, предоставляемый одним из рекомендуемых хостинг-партнеров. Используется двух-уровневая конфигурация фронтэнд-бэкэнд.
Подробнее:
(QP0020) PHP сконфигурирован оптимально. В административном разделе: "Настройки/Производительность/Панель производительности/Конфигурация" в строке «Конфигурация PHP» в колонке «Оценка» должно появиться значение - «оптимально». Обязательно использование прекомпилятора PHP с адекватным объемом памяти – eaccelerator, xcache, apc, ZendOptimizer+ (часто используемые исполняемые файлы проекта должны помещаться в opcode-кэш прекомпилятора).
Подробнее:
(QP0030) Включено «Автокэширование» в разделе «Настройки/Настройки продукта/Автокэширование/Кэширование компонентов».
(QP0040) Инфраструктура платформы сконфигурирована для максимальной производительности. В административном разделе: "Настройки/Производительность/Панель производительности/Битрикс" в колонке «Рекомендации» должны быть выполнены все рекомендации по улучшению производительности платформы. Название вкладки станет - «Битрикс (оптимально)».
(QP0050) Производительность конфигурации адекватна требованиям проекта и составляет #N# (#расшифровка#)* - «Настройки/Производительность/Панель производительности/Конфигурация»:
- Нажимаем «Тестировать конфигурацию»
- Результат после проведения замеров появляется в колонке «Оценка» строки «Конфигурация»
* «Низкая» – (<=15), «Удовлетворительная» - >15 и <30, «Высокая» - >=30.
Подробнее:
(QP0060) Выполнен нагрузочный тест максимальной производительности проекта - "Настройки/Производительность/Панель производительности/Масштабируемость" с исходными данными:
- Начальное количество одновременных соединений = 1
- Конечное количество одновременных соединений = 5
- Шаг увеличения одновременных соединений = 1
- Максимальная продолжительность теста = 5 минут
- Страница = главная проекта (например - /index.php)
Время генерации страницы не должно превышать 0.5 секунды и не должно деградировать при увеличении количества одновременных соединений во время теста. Число ошибок должно быть равно нулю. Минимальное число страниц в секунду должно соответствовать ожидаемой пиковой посещаемости проекта в сутки (хитов в сутки), деленной на 86400. Минимальное время получения страницы не должно превышать 1 секунды.
(QP0070) Выполнен аудит производительности основных страниц проекта:
- На административной странице «Настройки/Производительность/Панель производительности» нажимаем «Тестировать производительность» в течение 10 минут
- Кликаем по основным страницам публичной части. Рекомендуется привлечь к тестированию как можно больше сотрудников или использовать инструменты нагрузки типа JMeter.
- После завершения теста анализируем результаты на вкладке «Разработка»: результаты в колонке «Среднее время (сек)» не должны превышать 0.5 сек, в колонке «Ошибки разработки» не должно быть сообщений об ошибках.
(QP0080) Расставлены индивидуальные индексы в инфоблоках 2.0 для увеличения скорости выборки данных.
Подробнее:
(QP0090) HTML кэширование включено для небольших, редко изменяемых проектов в разделе «Настройки/Настройки продукта/Автокэширование/HTML кэш».
Подробнее:
(QP0100) Настроен и сконфигурирован веб-кластер в соответствии с руководством (для высоконагруженных проектов или систем, которым требуется высокая надежность).
Подробнее:
Безопасность
(QSEC0010) Система соответствует уровню безопасности – «Стандартный» (включен проактивный фильтр, контроль активности, повышенный уровень безопасности администраторов и т.п.) или выше.
Подробнее:
«Настройки/Проактивная защита/Панель безопасности»
(QSEC0020) Административные учетные записи имеют повышенный уровень безопасности. По возможности, для них используется технология двухфакторной авторизации (OTP).
Подробнее:
-
(QSEC0030) Настроены права групп пользователей системы и протестированы их возможности в административном разделе системы после авторизации ("/bitrix/admin" . Все «лишнее» должно быть недоступно.
Подробнее:
(QSEC0040) Удалены тестовые учетные записи разработчиков. Удалены тестовые данные и страницы.
(QSEC0045) Файлы данных и страницы веб-проекта, содержащие конфиденциальную информацию (в т.ч. персональные данные Клиентов), закрыты от неавторизованного доступа и от индексации поисковыми роботами. Для дополнительной защиты персональных данных Клиентов при их передаче по сети, в случае необходимости, используется SSL.
(QSEC0050) Для соединения с базой данных на хостинге используется сильный пароль, настроены необходимые проекту привилегии для работы с базой данных (работа не под root).
(QSEC0060) Отключен вывод ошибок и предупреждений посетителям проекта.
Подробнее:
$DBDebug - отключен (dev.1c-bitrix.ru/api_help/main/general/magic_vars.php)
"Настройки/Настройки продукта/Настройки модулей/Главный модуль: Режим вывода ошибок" -> "Не выводить"
(QSEC0070) Настроен журнал системных событий.
Подробнее:
«Настройки/Инструменты/Журнал событий»
- закладка «Журнал событий»
(QSEC0080) Компьютер администраторов системы защищен:
- установлено актуальное антивирусное ПО, регулярно проводится полная антивирусная проверка
- пароли от системы (ftp, ssh, БД, админка битрикс и т.п.) не сохраняются в клиентских программах: браузере, ФТП клиенте и т.п.
- каждый администратор должен иметь свой уникальный логин-пароль
Сдача проекта
(QJ0010) Лицензионный ключ активирован, загружены исходные тексты ядра.
Подробнее:
(QJ0020) Ядро проекта не модифицировалось. В любое время можно обновить платформу через систему обновлений, не нарушив работоспособность проекта.
Подробнее:
(QJ0030) Введена информация о партнере (произвольное текстовое поле и логотип) или компании, которая провела интеграцию и внедрение решения на платформе Битрикс.
(QJ0040) Введена информация о техподдержке проекта (произвольное текстовое поле и логотип).
13.07.2011: Обновление
20.07.201115:1820.07.2011 15:18:58
Всем привет. Лучше поздно, чем никогда, правда?
Так вот. Наконец мы решились, и в этом блоге я буду освещать вышедшие обновления модулей и новый функционал. Блоги разработчиков Битрикс по-прежнему будут существовать и пополняться, а здесь я постараюсь описывать подробнее для вас короткие и такие порой загодочные предложения, которые встречаются в письмах с описанием обновлений.
Начнем с обновления, вышедшего в прошлую среду (13.07).
Так вот. Наконец мы решились, и в этом блоге я буду освещать вышедшие обновления модулей и новый функционал. Блоги разработчиков Битрикс по-прежнему будут существовать и пополняться, а здесь я постараюсь описывать подробнее для вас короткие и такие порой загодочные предложения, которые встречаются в письмах с описанием обновлений.
Начнем с обновления, вышедшего в прошлую среду (13.07).
Фото:
Поиск хостинга под Битрикс - это не проблема
08.07.201114:5108.07.2011 14:51:55
Месяц назад , который мы открыли для наших клиентов и партнеров.
***
С тех пор произошло несколько изменений, которые, надеюсь, сделают этот каталог еще более удобным и полезным инструментом для выбора отличного хостинга - как для проектов, разработанных на платформе "1С-Битрикс", так и для любых других сайтов.
Об этих нововведениях и хочу вам рассказать.
***
С тех пор произошло несколько изменений, которые, надеюсь, сделают этот каталог еще более удобным и полезным инструментом для выбора отличного хостинга - как для проектов, разработанных на платформе "1С-Битрикс", так и для любых других сайтов.
Об этих нововведениях и хочу вам рассказать.
Интерфейс настройки вывода административной панели
24.06.201116:2524.06.2011 16:25:26
Доброго времени суток.
Частенько со стороны пользователей возникает недопонимание почему тем или иным группам пользователей не выводится административная панель в публичной части. И даже удивляются тому, что панель "пропадает" после перехода пользователя из административной части сайта в публичную.
Причиной этому является логика, согласно которой панель не выводится для пользователей, которым не хватает прав ни на одну операцию, задаваемую кнопками административной панели.
Частенько со стороны пользователей возникает недопонимание почему тем или иным группам пользователей не выводится административная панель в публичной части. И даже удивляются тому, что панель "пропадает" после перехода пользователя из административной части сайта в публичную.
Причиной этому является логика, согласно которой панель не выводится для пользователей, которым не хватает прав ни на одну операцию, задаваемую кнопками административной панели.
Фото:
Технологии и бизнес-стратегии на партнерской конференции
23.06.201112:3523.06.2011 12:35:43
Два раза в год, весной и осенью, мы выпускаем новые версии наших продуктов.
И два раза в год, летом и зимой мы рассказываем о наших планах
Летом и зимой мы занимаемся стратегическим планированием и выбором курса. И именно партнерская конференция является для нас местом обсуждения концепций и точкой принятия решения, что войдет в поставку продуктов этой осенью. Как всегда идей же больше, чем можно сделать, а важно сделать именно то, что наиболее востребовано.
В этом году мы подготовили интересную программу на два дня.
30 июня - Первый день – Технологии веб-разработки.
1 июля - Второй день - Бизнес-стратегии - ориентирован на директоров компаний и посвящен развитию.
Подробности и программу вы можете посмотреть у нас на .
Я обращу ваше внимание на самое интересное и общий формат. Итак...
И два раза в год, летом и зимой мы рассказываем о наших планах
Летом и зимой мы занимаемся стратегическим планированием и выбором курса. И именно партнерская конференция является для нас местом обсуждения концепций и точкой принятия решения, что войдет в поставку продуктов этой осенью. Как всегда идей же больше, чем можно сделать, а важно сделать именно то, что наиболее востребовано.
В этом году мы подготовили интересную программу на два дня.
30 июня - Первый день – Технологии веб-разработки.
1 июля - Второй день - Бизнес-стратегии - ориентирован на директоров компаний и посвящен развитию.
Подробности и программу вы можете посмотреть у нас на .
Я обращу ваше внимание на самое интересное и общий формат. Итак...
Фото:
Энергетическая модель компании
23.06.201102:0323.06.2011 02:03:04
Давно собирался написать на эту тему, но никак не хватало времени, духа и энергии.
Но последняя презентация в нашей компании, на которой я рассказал своим коллегам про энергетическую модель, вдохновили меня, что все же нужно оформить это в статью, читатели найдутся.
Зачастую в жизни случаются события, которые сложно объяснить логически. Уверен, вы видели компании, которые были хорошо профинансированы, набраны умные и хорошие люди, но дело не клеилось. Вроде бы все должно работать, но процесс не идет.
Каждому из нас приходится выбирать, и порой для принятия решения у нас недостаточно информации или опыта. Особенно часто это касается приема или увольнения людей, или необходимости изменений в жизни или компании.
Как поступать в таких ситуациях? На что опираться в рассуждениях?
Пока я писал эту статью и просил ее почитать своих друзей, мне неоднократно сказали, что в этом месте нужно бы вставить конкретных примеров И у меня есть что рассказать. Но я не могу. Потому, что это может случайно нанести кому-то травму или обидит. Вынужден обойтись только теорией, терпите много скучных букв.
Я построил для себя энергетическую модель компании, которую использую в работе и в жизни. И это очень простая модель.
Но последняя презентация в нашей компании, на которой я рассказал своим коллегам про энергетическую модель, вдохновили меня, что все же нужно оформить это в статью, читатели найдутся.
Зачастую в жизни случаются события, которые сложно объяснить логически. Уверен, вы видели компании, которые были хорошо профинансированы, набраны умные и хорошие люди, но дело не клеилось. Вроде бы все должно работать, но процесс не идет.
Каждому из нас приходится выбирать, и порой для принятия решения у нас недостаточно информации или опыта. Особенно часто это касается приема или увольнения людей, или необходимости изменений в жизни или компании.
Как поступать в таких ситуациях? На что опираться в рассуждениях?
Пока я писал эту статью и просил ее почитать своих друзей, мне неоднократно сказали, что в этом месте нужно бы вставить конкретных примеров
И у меня есть что рассказать. Но я не могу. Потому, что это может случайно нанести кому-то травму или обидит. Вынужден обойтись только теорией, терпите много скучных букв. Я построил для себя энергетическую модель компании, которую использую в работе и в жизни. И это очень простая модель.
Фото:
Веб-кластер в "облаке" Scalaxy за 1 час
20.06.201112:0120.06.2011 12:01:00
В 10-ой версии платформы "1С-Битрикс: Управление сайтом" появился . Он позволяет развернуть любой (новый или уже работающий) проект, реализованный на CMS "1С-Битрикс" на нескольких взаимозаменяемых физических или виртуальных серверах. Тем самым решаются две очень важные для любого онлайн-бизнеса задачи:
- При росте нагрузки на сайт его можно практически неограниченно масштабировать, обеспечивая нужную производительность.
- Сайт максимально доступен для посетителей. В случае выхода из строя одного или нескольких серверов веб-кластера система продолжает беспрерывно обслуживать клиентов на остальных работающих машинах.
Фото:
Технологии кластеризации 1С-Битрикс - распределение файлов веб-проекта и балансировка
14.06.201115:3314.06.2011 15:33:00
Добрый день, коллеги!
Сегодня поговорим о том, как наиболее эффективно распределить файлы веб-проекта между нодами веб-кластера. Постараемся определить оптимальную стратегию использования балансировщика. Разложим по полочкам популярные инструменты синхронизации контента, в частности .
Из чего состоит веб-проект на платформе 1С-Битрикс?
Прежде всего, вспомним, из чего состоят наши веб-проекты? Из информации в базе данных, эффективную работу с которой в контексте кластеризации мы , и информации в файлах.
В файлах хранится информация следующих типов:
1) "Узлы и агрегаты платформы 1С-Битрикс"
Библиотеки, скрипты, вспомогательные файлы: меню, права доступа, свойства разделов и страниц, шаблоны сайтов, файлы конфигурации. Часть файлов находится условно "под капотом", менять их нельзя, они обновляются по технологии SiteUpdate - благодаря чему ядро системы постоянно улучшается, в нем появляется новый функционал.
Некоторые вспомогательные файлы редактируются через административный интерфейс, как, например, файлы меню, свойства страниц и разделов и др.
2) Загружаемый контент
Загружаемые в объекты модулей системы (например, "Медиабиблиотеку" ) файлы, документы и изображения хранятся в подпапках системной папки "/upload". Почему файлы и документы хранятся в файловой системе, а не в базе данных? Это общепринятая архитектурная практика, доказавшая свою эффективность: в базе данных хранится справочная мета-информация, которая оптимально проиндексирована для поиска, а сами большие объекты хранятся отдельно (в файловой системе или "облачном" хранилище) и отдаются клиентам напрямую специализированными инструментами, например через .
3) Страницы веб-сайта
Страницы веб-сайта редактируются через административный интерфейс и хранятся в виде файлов. Разделы это папки, страницы - файлы. Размещенные на страницах изображения также можно хранить в виде файлов, например в папке "/images".
Повышение эффективности работы с файлами - на одной ноде кластера
Чтобы максимально разгрузить сервер приложений (его роль часто выполняет , популярность набирает технология ), выполняющий код нашего веб-проекта, работу со статическими файлами переводят на , например .
Обратный прокси очень эффективно напрямую работает со статическими файлами, в том числе из системной папки "/upload" - изображениями, документами, архивами и т.п., позволяя серверу приложений сосредоточиться на выполнении кода.
Чтобы снизить нагрузку на дисковую подсистему сервера, на linux, например, стараются освободить как можно больше оперативной памяти. В этом случае файлы закэшируются в оперативной памяти и будут отдаваться оттуда значительно быстрее. Особенно это эффективно при интенсивном скачивании клиентами файлов веб-проекта (документы, видео). Поэтому, если известно, что контента ожидается на 10G - устанавливайте соответственно большее количество оперативной памяти.
На графике видим, что на сервере 7.5GB памяти, при этом приложения используют 300МB (nginx+apache), а для кэша и буфферов файловой системы задействовано более 5GB. Этот объем будет отдаваться клиентам значительно быстрее, чем если бы он отдавался напрямую с диска.
Сервер "статики"
Если веб-проекту требуется отдавать значительно большие объемы контента, то можно делегировать задачу отдачи контента серверу "статики". При этом тяжелая "статика" будет отдаваться с отдельного домена/сервера, например images.mysite.ru - что позволит браузерам загружать веб-страницы в параллельном режиме (обходя браузера на число подключений к одному серверу). Также, на данном домене для "статики" можно сократить до минимума число cookies - сократив трафик и нагрузку на канал.
Для сервера "статики" обычно формируют быструю дисковую подсистему - например рейд10 (или рейд0 - если данные можно перезалить).
Чтобы сохранять "тяжелые" файлы для скачивания на сервере статики, можно организовать для этого отдельный бизнес-процесс: контенщик по ftp сохраняет там файл и вставляет ссылку на него в контент страницы. Можно вместо ftp подмонтировать папку с файлами с сервера "статики" к ноде кластера и тогда нужно будет просто класть файлы в эту папку - главное сформировать правильную ссылку.
Кэширование на обратном прокси-сервере
Популярный nginx поддерживает статических файлов (или их ). В этом случае можно не загружать на сервер "статики" файлы по ftp/cifs/nfs - а сделать закачку "автоматической".
Когда нужен
Если ваша задача раздавать тяжелое видео и ожидается большое число одновременных скачиваний - наверно лучшим решением будет , в том числе .
Промежуточный итог - "тяжелые" скачиваемые файлы желательно хранить отдельно и отдавать оттуда же
На летней партнерской конференции 2011 мы расскажем, какие новейшие технологии в данной области мы включим в платформу 1С-Битрикс. , не пожалеете!
Итак, с организацией эффективной раздачи файлов все понятно и просто. Теперь подумаем, как синхронизировать оставшиеся файлы веб-проекта между нодами веб-кластера?
NFS/CIFS
Казалось бы все просто. Экспортируем папку с файлами проекта на другие ноды веб-кластера по NFS/CIFS. Проблема один - производительность. К сожалению, при высоких нагрузках веб-проект будет работать значительно медленнее на нодах, подсоединяющихся к реальному диску "через сеть". Проблема два - при выходе из строя ноды1, остальные ноды ... потеряют данные и не смогут работать.
OCFS2(GFS2)
Эти и другие кластерные системы предназначены для работы с разделяемыми дисками. Например диск C должен быть примонтирован как на ноду1, так и ноду2. Это конечно эффективно, но требуются дополнительные затраты на оборудование. Передовые облачные хостинги, такие как или , пока не предоставляют такую услугу.
OCFS2(GFS2) over DRBD
Этот трюк работает и без дополнительного оборудования. Но чтобы конструкция не только заработала, а стабильно работала
- нужно серьезно потрудится и использовать дополнительный кластерный софт. Об этом поговорим подробнее в будущих постах.
В случае, когда файлов на вашем веб-кластере не миллионы, данная утилита работает отлично. Пройдем по ее основным режимам работы, т.к. в официальной документации они описаны не очень понятно.
Конфигурация
В системе может быть сколько угодно файлов конфигурации csync2. В этом случае создается такое-же количество баз данных SQLite, используемых для хранения информации о файлах. Это пригодится, когда файлов много и хранение их в одной базе отрицательно сказывается на производительности.
Сервер утилиты при этом работает на одном порту и разбирает с какими конфигами работать в зависимости от режима работы клиента.
Начальный импорт данных
Если вы не можете остановить основной сервер с файлами при настройке синхронизации файлов на вторую ноду веб-кластера, то
можно поступить так:
1) Выполнить индексацию файлов на ноде1: csync2 -cIr /
2) Запустить архивацию файлов на ноде1. Да, мы понимаем, что архив может оказаться нецелостным, но мы сделали "снимок" в п.1
3) Распаковать архив на ноде2.
4) Выполнить индексацию файлов на ноде2: csync2 -cIr /
5) Выполнить первоначальную синхронизацию в обе стороны. На ноде1, затем на ноде2: csync2 -cr /, csync2 -u
Логика работы
Важно понять, что существует 2 главных режима работы утилиты - сбор изменений и их отправка на ноды веб-кластера.
Собираем изменения: csync2 -cr /
Проверяем, что локально что-то поменялось: csync2 -M - выводятся данные, которые будут возможно переданы на другие ноды веб-кластера.
Отправляем изменения на другие ноды веб-кластера: csync2 -u. Предварительно можно добавить ключик "холостого" запуска - d.
Проверяем, что изменения ушли из списка модификаций: csync2 -M - он должен быть пустым.
Режим отладки
Если утилита сообщает об ошибке, подробности процесса можно посмотреть, добавив ключики -v или -vv. Как правило причина ошибки становится понятной.
Производительность
На относительно небольшом количестве файлов (до 100к) утилита стабильно работает с частотой синхронизации 1 раз в минуту.
Для большего количества файлов можно ее запускать реже, если это позволяет бизнес-процесс.
Балансировщик
В nginx, например, можно настроить балансировку используя модуль как в режиме round-robin, так и путем ip-адреса клиента.
Для "быстрого" достижения эффекта он-лайн синхронизации файлов между нодами веб-кластера поможет использование режима - каждый клиент будет ходить на "свой" сервер и сразу видеть загруженные им файлы. Правда это уже будет не балансировка, а скорее дистрибуция, но конфигурация будет устойчивой - при выходе из строя одной из нод, запросы автоматически будут обслуживаться другой нодой веб-кластера.
Для высоконагруженных конфигураций можно использовать балансировщик, предоставляемый провайдером, в т.ч. облачным.
Тут можно выбрать один из режимов сессии клиента к серверу (ноде).
Однако, если для вас критично, чтобы любые изменения на одной из нод веб-кластера "мгновенно" появлялись на всех других нодах, смотрите на кластерные файловые системы типа OCFS2/GFS2.
SSL-termination
Если вы защищаете доступ к веб-кластеру с помощью SSL - с точки зрения производительности и простоты администрирования рекомендуется установить сертификаты на балансировщике.
Передача IP-адреса через балансировщик на ноды кластера
При использовании балансировщика не забывайте передавать реальный адрес клиента в ноды веб-кластера. Это можно сделать различными способами, которые хорошо известны и описаны - например путем установки заголовка на nginx.
ИТОГИ
Мы предметно поговорили о стратегиях организации работы с файлами, научились выбирать балансировщик и режимы его работы для использования в кластере, изучили типы размещения "больших" файлов, CDN, кэширование.
Сегодня поговорим о том, как наиболее эффективно распределить файлы веб-проекта между нодами веб-кластера. Постараемся определить оптимальную стратегию использования балансировщика. Разложим по полочкам популярные инструменты синхронизации контента, в частности .
Из чего состоит веб-проект на платформе 1С-Битрикс?
Прежде всего, вспомним, из чего состоят наши веб-проекты? Из информации в базе данных, эффективную работу с которой в контексте кластеризации мы , и информации в файлах.
В файлах хранится информация следующих типов:
1) "Узлы и агрегаты платформы 1С-Битрикс"
Библиотеки, скрипты, вспомогательные файлы: меню, права доступа, свойства разделов и страниц, шаблоны сайтов, файлы конфигурации. Часть файлов находится условно "под капотом", менять их нельзя, они обновляются по технологии SiteUpdate - благодаря чему ядро системы постоянно улучшается, в нем появляется новый функционал.
Некоторые вспомогательные файлы редактируются через административный интерфейс, как, например, файлы меню, свойства страниц и разделов и др.
2) Загружаемый контент
Загружаемые в объекты модулей системы (например, "Медиабиблиотеку" ) файлы, документы и изображения хранятся в подпапках системной папки "/upload". Почему файлы и документы хранятся в файловой системе, а не в базе данных? Это общепринятая архитектурная практика, доказавшая свою эффективность: в базе данных хранится справочная мета-информация, которая оптимально проиндексирована для поиска, а сами большие объекты хранятся отдельно (в файловой системе или "облачном" хранилище) и отдаются клиентам напрямую специализированными инструментами, например через .
3) Страницы веб-сайта
Страницы веб-сайта редактируются через административный интерфейс и хранятся в виде файлов. Разделы это папки, страницы - файлы. Размещенные на страницах изображения также можно хранить в виде файлов, например в папке "/images".
| Нередко в командах разработчиков возникает вопрос - а почему бы не хранить вспомогательные файлы ядра или страницы веб-сайта в базе данных. Все дело в производительности! Использование простой логики работы с файловой системой часто более предпочтительно, чем двухуровневая конструкция: БД + кэширование. Поэтому информация о меню/права доступа/свойства страниц и разделов - это служебные ... файлы. Также нередко спрашивают, а почему бы не использовать для файлов конфигурации популярные форматы , , а для файлов шаблонов компонентов вместо PHP скриптов использовать (якобы это позволяет эффективно разделить работу верстальщика от работы программиста). Ответ все тот же - профилирование платформы на высоких нагрузках показало, что наиболее предпочтительный формат данных файлов - скрипт php. Разумеется, при необходимости вы всегда использовать любой модный формат файлов в вашем веб-проекте. |
Повышение эффективности работы с файлами - на одной ноде кластера
Чтобы максимально разгрузить сервер приложений (его роль часто выполняет , популярность набирает технология ), выполняющий код нашего веб-проекта, работу со статическими файлами переводят на , например .
Обратный прокси очень эффективно напрямую работает со статическими файлами, в том числе из системной папки "/upload" - изображениями, документами, архивами и т.п., позволяя серверу приложений сосредоточиться на выполнении кода.
Чтобы снизить нагрузку на дисковую подсистему сервера, на linux, например, стараются освободить как можно больше оперативной памяти. В этом случае файлы закэшируются в оперативной памяти и будут отдаваться оттуда значительно быстрее. Особенно это эффективно при интенсивном скачивании клиентами файлов веб-проекта (документы, видео). Поэтому, если известно, что контента ожидается на 10G - устанавливайте соответственно большее количество оперативной памяти.
На графике видим, что на сервере 7.5GB памяти, при этом приложения используют 300МB (nginx+apache), а для кэша и буфферов файловой системы задействовано более 5GB. Этот объем будет отдаваться клиентам значительно быстрее, чем если бы он отдавался напрямую с диска.
Сервер "статики"
Если веб-проекту требуется отдавать значительно большие объемы контента, то можно делегировать задачу отдачи контента серверу "статики". При этом тяжелая "статика" будет отдаваться с отдельного домена/сервера, например images.mysite.ru - что позволит браузерам загружать веб-страницы в параллельном режиме (обходя браузера на число подключений к одному серверу). Также, на данном домене для "статики" можно сократить до минимума число cookies - сократив трафик и нагрузку на канал.
Для сервера "статики" обычно формируют быструю дисковую подсистему - например рейд10 (или рейд0 - если данные можно перезалить).
Чтобы сохранять "тяжелые" файлы для скачивания на сервере статики, можно организовать для этого отдельный бизнес-процесс: контенщик по ftp сохраняет там файл и вставляет ссылку на него в контент страницы. Можно вместо ftp подмонтировать папку с файлами с сервера "статики" к ноде кластера и тогда нужно будет просто класть файлы в эту папку - главное сформировать правильную ссылку.
Кэширование на обратном прокси-сервере
Популярный nginx поддерживает статических файлов (или их ). В этом случае можно не загружать на сервер "статики" файлы по ftp/cifs/nfs - а сделать закачку "автоматической".
Когда нужен
Если ваша задача раздавать тяжелое видео и ожидается большое число одновременных скачиваний - наверно лучшим решением будет , в том числе .
Промежуточный итог - "тяжелые" скачиваемые файлы желательно хранить отдельно и отдавать оттуда же
На летней партнерской конференции 2011 мы расскажем, какие новейшие технологии в данной области мы включим в платформу 1С-Битрикс. , не пожалеете!
Итак, с организацией эффективной раздачи файлов все понятно и просто. Теперь подумаем, как синхронизировать оставшиеся файлы веб-проекта между нодами веб-кластера?
NFS/CIFS
Казалось бы все просто. Экспортируем папку с файлами проекта на другие ноды веб-кластера по NFS/CIFS. Проблема один - производительность. К сожалению, при высоких нагрузках веб-проект будет работать значительно медленнее на нодах, подсоединяющихся к реальному диску "через сеть". Проблема два - при выходе из строя ноды1, остальные ноды ... потеряют данные и не смогут работать.
OCFS2(GFS2)
Эти и другие кластерные системы предназначены для работы с разделяемыми дисками. Например диск C должен быть примонтирован как на ноду1, так и ноду2. Это конечно эффективно, но требуются дополнительные затраты на оборудование. Передовые облачные хостинги, такие как или , пока не предоставляют такую услугу.
OCFS2(GFS2) over DRBD
Этот трюк работает и без дополнительного оборудования. Но чтобы конструкция не только заработала, а стабильно работала
- нужно серьезно потрудится и использовать дополнительный кластерный софт. Об этом поговорим подробнее в будущих постах.В случае, когда файлов на вашем веб-кластере не миллионы, данная утилита работает отлично. Пройдем по ее основным режимам работы, т.к. в официальной документации они описаны не очень понятно.
Конфигурация
В системе может быть сколько угодно файлов конфигурации csync2. В этом случае создается такое-же количество баз данных SQLite, используемых для хранения информации о файлах. Это пригодится, когда файлов много и хранение их в одной базе отрицательно сказывается на производительности.
Сервер утилиты при этом работает на одном порту и разбирает с какими конфигами работать в зависимости от режима работы клиента.
Начальный импорт данных
Если вы не можете остановить основной сервер с файлами при настройке синхронизации файлов на вторую ноду веб-кластера, то
можно поступить так:
1) Выполнить индексацию файлов на ноде1: csync2 -cIr /
2) Запустить архивацию файлов на ноде1. Да, мы понимаем, что архив может оказаться нецелостным, но мы сделали "снимок" в п.1
3) Распаковать архив на ноде2.
4) Выполнить индексацию файлов на ноде2: csync2 -cIr /
5) Выполнить первоначальную синхронизацию в обе стороны. На ноде1, затем на ноде2: csync2 -cr /, csync2 -u
Логика работы
Важно понять, что существует 2 главных режима работы утилиты - сбор изменений и их отправка на ноды веб-кластера.
Собираем изменения: csync2 -cr /
Проверяем, что локально что-то поменялось: csync2 -M - выводятся данные, которые будут возможно переданы на другие ноды веб-кластера.
Отправляем изменения на другие ноды веб-кластера: csync2 -u. Предварительно можно добавить ключик "холостого" запуска - d.
Проверяем, что изменения ушли из списка модификаций: csync2 -M - он должен быть пустым.
Режим отладки
Если утилита сообщает об ошибке, подробности процесса можно посмотреть, добавив ключики -v или -vv. Как правило причина ошибки становится понятной.
Производительность
На относительно небольшом количестве файлов (до 100к) утилита стабильно работает с частотой синхронизации 1 раз в минуту.
Для большего количества файлов можно ее запускать реже, если это позволяет бизнес-процесс.
Балансировщик
В nginx, например, можно настроить балансировку используя модуль как в режиме round-robin, так и путем ip-адреса клиента.
Для "быстрого" достижения эффекта он-лайн синхронизации файлов между нодами веб-кластера поможет использование режима - каждый клиент будет ходить на "свой" сервер и сразу видеть загруженные им файлы. Правда это уже будет не балансировка, а скорее дистрибуция, но конфигурация будет устойчивой - при выходе из строя одной из нод, запросы автоматически будут обслуживаться другой нодой веб-кластера.
Для высоконагруженных конфигураций можно использовать балансировщик, предоставляемый провайдером, в т.ч. облачным.
Тут можно выбрать один из режимов сессии клиента к серверу (ноде).
Однако, если для вас критично, чтобы любые изменения на одной из нод веб-кластера "мгновенно" появлялись на всех других нодах, смотрите на кластерные файловые системы типа OCFS2/GFS2.
SSL-termination
Если вы защищаете доступ к веб-кластеру с помощью SSL - с точки зрения производительности и простоты администрирования рекомендуется установить сертификаты на балансировщике.
Передача IP-адреса через балансировщик на ноды кластера
При использовании балансировщика не забывайте передавать реальный адрес клиента в ноды веб-кластера. Это можно сделать различными способами, которые хорошо известны и описаны - например путем установки заголовка на nginx.
ИТОГИ
Мы предметно поговорили о стратегиях организации работы с файлами, научились выбирать балансировщик и режимы его работы для использования в кластере, изучили типы размещения "больших" файлов, CDN, кэширование.
Задачи 2.0. Шаблоны задач, история изменений, MS Excel.
07.06.201114:5407.06.2011 14:54:11
Сегодня вышло очередное обновление модуля "Задачи". С момента появления модуля изменения, пожалуй, самые значительные, поэтому на некоторых из них хотелось бы остановиться поподробнее. А также немного поделиться планами по дальнейшему развитию модуля.
Фото:
Курс Пользователя корпоративного портала
07.06.201113:1007.06.2011 13:10:25
Очередные новости от отдела Документации
Закончена работа над курсом . Работа длилась чуть дольше чем планировалось. Сделали курс.. и в очередной раз расстроились: опять разработчики на портале компании новые фичи внедрили, значит скоро будут эти фичи в дистрибутиве, значит опять переделывать.
Ну что ж поделать, такова наша работа.
Текущий курс войдет в дистрибутив "1С-Битрикс: Корпоративный портал" в следующем релизе, 10.5. Если кому он будет нужен раньше - обращайтесь, дам архив для включения курса в уже работающие порталы.
Курс сделан в общей тенденции: по ролям пользователей. Сотрудники в компаниях будут в разных группах пользователей, вот с точки зрения этих групп пользователей и описан функционал "1С-Битрикс: Корпоративный портал".
Естественно, что описание дано согласно группам пользователей, имеющихся в дистрибутиве. Соглашусь, что дистрибутивные группы не исчерпывают всех потребностей владельцев портала, но мы не можем знать потребности каждой фирмы.
Ждем замечаний и предложений по этому курсу.
Теперь принимаемся за курс Администратора КП. Сроки его выхода затянуться, так как лето и работники у меня просятся в отпуска. Право законное, отказать не могу.
Закончена работа над курсом . Работа длилась чуть дольше чем планировалось. Сделали курс.. и в очередной раз расстроились: опять разработчики на портале компании новые фичи внедрили, значит скоро будут эти фичи в дистрибутиве, значит опять переделывать.
Ну что ж поделать, такова наша работа.
Текущий курс войдет в дистрибутив "1С-Битрикс: Корпоративный портал" в следующем релизе, 10.5. Если кому он будет нужен раньше - обращайтесь, дам архив для включения курса в уже работающие порталы.
Курс сделан в общей тенденции: по ролям пользователей. Сотрудники в компаниях будут в разных группах пользователей, вот с точки зрения этих групп пользователей и описан функционал "1С-Битрикс: Корпоративный портал".
Естественно, что описание дано согласно группам пользователей, имеющихся в дистрибутиве. Соглашусь, что дистрибутивные группы не исчерпывают всех потребностей владельцев портала, но мы не можем знать потребности каждой фирмы.
Ждем замечаний и предложений по этому курсу.
Теперь принимаемся за курс Администратора КП. Сроки его выхода затянуться, так как лето и работники у меня просятся в отпуска. Право законное, отказать не могу.
Больше хостингов - хороших и разных!
03.06.201115:3603.06.2011 15:36:51
У компании "1С-Битрикс" более 100 хостинг-партнеров. :
Я хочу рассказать вам о том, что он означает. И чем он полезен как для самих хостеров, так и для конечных клиентов.
Я хочу рассказать вам о том, что он означает. И чем он полезен как для самих хостеров, так и для конечных клиентов.
Для чего нужен Internet Explorer?
31.05.201119:0931.05.2011 19:09:03
В одном научно-популярном журнале прочитал когда-то, что Internet Explorer - программа, которая позволяет войти в интернет и скачать свой любимый браузер. Так я его и использовал до сегодняшнего дня. А тут поставил Windows Server 2008... и на тебе!
Фото:
Инструкция по настройке интеграции с интернет-магазином на 1С-Битрикс, в 1С:Управление торговлей 11
30.05.201112:3730.05.2011 12:37:38
Уважаемые коллеги, мы знаем, что многие наши клиенты и партнеры испытывают затруднения в настройке интеграции с 1С, и очень много вопросов - по настройкам именно в самой 1С:Управление торговлей 11 (платформа 8.2).
Решение от 1С сильно изменилось по сравнению с версией 10.3, появилось много нюансов и подводных камней, которые нужно учитывать.
Чтобы помочь вам, мы подготовили достаточно подробную инструкцию по настройке 1С, в части обмена с веб-сайтами, которая доступна в разделе документации:
Инструкция традиционно доступна в формате и .
Надеемся, что она окажется вам полезной
Если будут пожелания/замечания к материалу, пишите здесь в комментариях или мне на почту.
UPD:
Материалы теперь находятся здесь:
Решение от 1С сильно изменилось по сравнению с версией 10.3, появилось много нюансов и подводных камней, которые нужно учитывать.
Чтобы помочь вам, мы подготовили достаточно подробную инструкцию по настройке 1С, в части обмена с веб-сайтами, которая доступна в разделе документации:
Инструкция традиционно доступна в формате и .
Надеемся, что она окажется вам полезной
Если будут пожелания/замечания к материалу, пишите здесь в комментариях или мне на почту.
UPD:
Материалы теперь находятся здесь:
Технологии кластеризации 1С-Битрикс - увеличиваем "мощность" и надежность базы данных
30.05.201112:3130.05.2011 12:31:58
В прошлый раз мы об эффективном кэшировании на базе memcached, которое появилось в 10 версии платформы "1C-Битрикс: Управление сайтом" (редакции "Веб-кластер", "Бизнес веб-кластер" ).
Сегодня хочу рассказать о появившейся возможности практически неограниченно увеличить "мощность" базы данных интернет-проекта - путем ее кластеризации.
Все лучшее ... Базе!
Обычно для высоконагруженного сайта, особенно со сложной бизнес-логикой, покупают/арендуют отдельный сервер. Мы же не хотим заставить Клиента ждать 10 минут, пока пройдет его платежная транзакция или выгрузится отчет?
Сервер базы данных, так сказать "сердце" сайта, выбирают и покупают, можно сказать, "с трепетом" - еще бы, тут будут хранится оформленные и оплаченные заказы, лицевые счета, персональные данные Клиентов и прочая критичная для бизнеса информация.
Да, мы выбираем конфигурацию для сервера базы данных с резервным блоком питания, подключенным к отдельной шине питания в датацентре, с задублированными вентиляторами.
Иногда, зная что пролет элементарной частицы через микросхему оперативной памяти может инвертировать бит информации, мы устанавливаем более дорогую память типа (я не шучу, такие технологии нередко востребованы, например в системах управления полетами, медицине и др.).
Для быстрой работы дисковой подсистемы, если позволяет бюджет, мы конечно используем эффективный и надежный . Ну или хотя бы, как минимум, - для надежного зеркалирования информации.
Для быстрой работы базы данных нам все чаще требуется распространенная сейчас (write back disk cache). Разумеется, зная, что при экстренном выключении питания рейд-контроллер или жесткий диск может потерять закэшированную им информацию (несколько заказов, финансовых транзакций) - мы обязательно покупаем .
Ну и конечно мы устанавливаем на наш сервер побольше оперативной памяти. Идеальная ситуация, это когда база данных полностью помещается в оперативную память. Например у магазина база занимает 10 Гигабайт - вот если установить на сервер 15 Гигабайт - приложение будет нам благодарно (иначе будет происходить периодическая загрузка данных базы с диска, что конечно медленнее).
Если мы работаем на MySQL - то, как известно, самый производительный (данные размещаются в оперативной памяти) и устойчивый к конкурентной нагрузке формат базы данных - Innodb.
И еще раз внимательно просмотрев мы наконец запускаем быстрый, надежный и крутой сервер базы данных!
Да, да. Мы еще настроили резервное копирование информации из базы данных. Оно делается раз в сутки и архив переносится на отдельный сервер бэкапов ( расположенный в отдельном охраняемом помещении ).
Можем ли мы быть теперь уверенными в быстрой и надежной работе базы данных интернет-проекта?
К сожалению, нет. Мы упустили два ключевых риска...
Проблема 1 - Дорогое масштабирование вверх
В наш век информации, когда объемы данных экспоненциально увеличиваются каждый год, мы достаточно быстро (кто через полгода, кто через 1-2 года) упремся в производительность сервера базы данных.
Почему? Ведь мы все тщательно будем кэшировать, мы собрали крутой сервер базы данных, быстрый и с большим объемом оперативной памяти...
Дело в том, что интересной и ценной для принятия бизнес-решений информации - много и ее будет все больше и больше. Вы захотите, к примеру, сохранять пути клиентов по сайту и их хиты на ... полгода для детального анализа отделом маркетинга.
Или вам потребуется открыть и подключить к интернет-сайту десяток-другой филиалов с каталогами и ценами и отдельными остатками. И очень захочется (именно захочется) синхронизировать информацию в каталогах с 1С каждые, к примеру, 5 минут.
И наш крутой и мощный сервер базы данных через определенное время начнет уже неуспевать и спотыкаться за полетом фантазии и креативных идей руководителя интернет-проекта.
Вы достаточно быстро выпустите "последнюю пулю" - купите самый самый быстрый процессор и самую большую планку памяти (причем топовые, самые быстрые комплектующие стоят значительно дороже - зависимость нелинейная), которые еще можно установить в сервер базы данных и ... и всё.
Я нередко вижу проекты, которым для базы данных уже не хватает 8 ядер и 32G оперативной памяти.
Придется снова покупать и настраивать мощный сервер. Или может купить для сервера базы данных
Решение проблемы 1 - "Master-Slave репликация"
Master-Slave репликация, доступная в модуле платформы "1C-Битрикс: Управление сайтом", позволяет эффективно решить описанную выше проблему вертикального масштабирования сервера базы данных.
Технология репликации базы данных существует довольно давно и она успешно используется для решения задач повышения производительности. Однако мы понимаем, что в данном случае приложение работает не с одной, а несколькими базами данных:
- в одну базу данных приложение пишет (есть еще более сложные варианты, но опускаем их)
- из остальных читает
Сложность в том, что если сразу при разработке приложения не учитывать что оно в будущем должно работать с несколькими базами данных, переделать его когда это потребуется может оказаться сложной и трудоемкой, а иногда и практически невыполнимой задачей ( ради эксперимента, спросите у разработчиков проекта - сможет приложение работать с двумя базами данных? и вы будете удивлены ответом ).
Благодаря тому, что возможность работы с несколькими базами данных была изначально заложена в архитектуру платформы 1С-Битрикс и реализована в кластерных редакциях, вашему проекту открываются новые вершины производительности.
И, на что хочется обратить особое внимание, В КОД РАБОТАЮЩЕГО ПРОЕКТА ПРИ КЛАСТЕРИЗАЦИИ БАЗЫ ДАННЫХ НЕ НУЖНО ВНОСИТЬ ИЗМЕНЕНИЯ! Технологию распределения запросов на серверы базы данных мы взяли на себя, предоставим вам возможность эффективно "дирижировать" нагрузкой через определение весов для каждого дополнительного сервера.
Вам достаточно лишь настроить и подключить к платформе один или несколько стандартных недорогих серверов базы данных, с помощью удобного мастера в течении нескольких минут перенести туда данные и ... наслаждаться увеличенной в N-раз производительностью базы данных!
Если нагрузка через полгода-год на базу данных снова возрастет (вы подключите к проекту еще 5-10 филиалов и откроете 2 языковых зеркала) или планируется увеличение нагрузки в ближайшие выходные в связи с рекламной акцией - вы снова просто можете добавить к платформе стандартный сервер базы данных (операция подключения и миграции данных занимает несколько минут).
Отключается сервер базы данных также легко и интуитивно через админку.
Подключение дополнительного сервера базы данных к сайту занимает несколько минут.
Наслаждаемся эффективной и производительной работой кластеризованной базы данных. Добавляем серверы к кластеру при необходимости - за несколько минут.
Проблема 2 - "Непрерывное" резервное копирование
Итак. Нагрузку на базу данных мы победили и в случае чего - добавим в кластер сервер в течение минут. А как обстоят дела с резервным копированием данных?
Оно выполняется раз в сутки. Иногда этого недостаточно.
Допустим, наш прекрасный мощный сервер базы данных ломается - сгорает процессор или материнская плата или ее элемент. Текущие заказы и транзакции где - на дисках этого сгоревшего сервера. Нужно ехать, вынимать их оттуда, подключать к другому и т.п. - в это время вам будут беспрерывно звонить клиенты.
Есть достаточно сложные решения, как "пережить" выход из строя сервера базы данных, типа DRBD репликации, кластерных файловых систем OCFS2, GFS2... но мы рассмотрим наиболее простое, распространенное и надежное решение - да, да, снова репликацию.
Решение проблемы 2 - "Master-Slave репликация"
Master-Slave репликация, доступная в модуле платформы "1C-Битрикс: Управление сайтом", позволяет эффективно решить задачу "непрерывного" резервного копирования и высокой доступности базы данных.
При репликации, данные с главного сервера базы данных в онлайне передаются на дополнительные (SLAVE) сервера - т.е. вы имеете копию данных = онлайн бэкап в нескольких экземплярах.
Более того, чтобы не замедлять основной и дополнительные сервера при создании логического бэкапа (который также необходимо делать периодически - иначе после случайного удаления, например, таблицы заказов, у вас не будет шансов ее вернуть, т.к. изменения реплицируются на все сервера базы данных) - мы можете выделить для этого отдельный сервер базы данных, на котором и выполнять процедуру создания логического бэкапа:
А для решения задачи быстрого переключения интернет-сайта на работающую базу данных (простой проекта составит пару минут или даже меньше) - вы скриптом или вручную переключаете систему на использование дополнительного сервера базы данных, на котором, благодаря репликации, имеется самая свежая копия бизнес-данных.
Выводы
Мы рассмотрели основные задачи, которые необходимо решить для организации высокопроизводительной и отказоустойчивой конфигурации базы данных, и увидели, как они просто решаются модулем "Веб-кластер" в 10 версии платформы "1C-Битрикс: Управление сайтом" (редакции "Веб-кластер", "Бизнес веб-кластер" ).
В следующей статье поговорим о создании высокопроизводительного кластера серверов приложений - такая задача нередко возникает при создании высоконагруженных интернет-проектов на платформе 1С-Битрикс.
Сегодня хочу рассказать о появившейся возможности практически неограниченно увеличить "мощность" базы данных интернет-проекта - путем ее кластеризации.
Все лучшее ... Базе!
Обычно для высоконагруженного сайта, особенно со сложной бизнес-логикой, покупают/арендуют отдельный сервер. Мы же не хотим заставить Клиента ждать 10 минут, пока пройдет его платежная транзакция или выгрузится отчет?
Сервер базы данных, так сказать "сердце" сайта, выбирают и покупают, можно сказать, "с трепетом" - еще бы, тут будут хранится оформленные и оплаченные заказы, лицевые счета, персональные данные Клиентов и прочая критичная для бизнеса информация.
Да, мы выбираем конфигурацию для сервера базы данных с резервным блоком питания, подключенным к отдельной шине питания в датацентре, с задублированными вентиляторами.
Иногда, зная что пролет элементарной частицы через микросхему оперативной памяти может инвертировать бит информации, мы устанавливаем более дорогую память типа (я не шучу, такие технологии нередко востребованы, например в системах управления полетами, медицине и др.).
Для быстрой работы дисковой подсистемы, если позволяет бюджет, мы конечно используем эффективный и надежный . Ну или хотя бы, как минимум, - для надежного зеркалирования информации.
Для быстрой работы базы данных нам все чаще требуется распространенная сейчас (write back disk cache). Разумеется, зная, что при экстренном выключении питания рейд-контроллер или жесткий диск может потерять закэшированную им информацию (несколько заказов, финансовых транзакций) - мы обязательно покупаем .
Ну и конечно мы устанавливаем на наш сервер побольше оперативной памяти. Идеальная ситуация, это когда база данных полностью помещается в оперативную память. Например у магазина база занимает 10 Гигабайт - вот если установить на сервер 15 Гигабайт - приложение будет нам благодарно
(иначе будет происходить периодическая загрузка данных базы с диска, что конечно медленнее).Если мы работаем на MySQL - то, как известно, самый производительный (данные размещаются в оперативной памяти) и устойчивый к конкурентной нагрузке формат базы данных - Innodb.
И еще раз внимательно просмотрев мы наконец запускаем быстрый, надежный и крутой сервер базы данных!
Да, да. Мы еще настроили резервное копирование информации из базы данных. Оно делается раз в сутки и архив переносится на отдельный сервер бэкапов ( расположенный в отдельном охраняемом помещении ).
Можем ли мы быть теперь уверенными в быстрой и надежной работе базы данных интернет-проекта?
К сожалению, нет. Мы упустили два ключевых риска...
Проблема 1 - Дорогое масштабирование вверх
В наш век информации, когда объемы данных экспоненциально увеличиваются каждый год, мы достаточно быстро (кто через полгода, кто через 1-2 года) упремся в производительность сервера базы данных.
Почему? Ведь мы все тщательно будем кэшировать, мы собрали крутой сервер базы данных, быстрый и с большим объемом оперативной памяти...
Дело в том, что интересной и ценной для принятия бизнес-решений информации - много и ее будет все больше и больше. Вы захотите, к примеру, сохранять пути клиентов по сайту и их хиты на ... полгода для детального анализа отделом маркетинга.
Или вам потребуется открыть и подключить к интернет-сайту десяток-другой филиалов с каталогами и ценами и отдельными остатками. И очень захочется (именно захочется) синхронизировать информацию в каталогах с 1С каждые, к примеру, 5 минут.
И наш крутой и мощный сервер базы данных через определенное время начнет уже неуспевать и спотыкаться за полетом фантазии и креативных идей руководителя интернет-проекта.
Вы достаточно быстро выпустите "последнюю пулю" - купите самый самый быстрый процессор и самую большую планку памяти (причем топовые, самые быстрые комплектующие стоят значительно дороже - зависимость нелинейная), которые еще можно установить в сервер базы данных и ... и всё.
Я нередко вижу проекты, которым для базы данных уже не хватает 8 ядер и 32G оперативной памяти.
Придется снова покупать и настраивать мощный сервер. Или может купить для сервера базы данных
Решение проблемы 1 - "Master-Slave репликация"
Master-Slave репликация, доступная в модуле платформы "1C-Битрикс: Управление сайтом", позволяет эффективно решить описанную выше проблему вертикального масштабирования сервера базы данных.
Технология репликации базы данных существует довольно давно и она успешно используется для решения задач повышения производительности. Однако мы понимаем, что в данном случае приложение работает не с одной, а несколькими базами данных:
- в одну базу данных приложение пишет (есть еще более сложные варианты, но опускаем их)
- из остальных читает
Сложность в том, что если сразу при разработке приложения не учитывать что оно в будущем должно работать с несколькими базами данных, переделать его когда это потребуется может оказаться сложной и трудоемкой, а иногда и практически невыполнимой задачей ( ради эксперимента, спросите у разработчиков проекта - сможет приложение работать с двумя базами данных? и вы будете удивлены ответом ).
Благодаря тому, что возможность работы с несколькими базами данных была изначально заложена в архитектуру платформы 1С-Битрикс и реализована в кластерных редакциях, вашему проекту открываются новые вершины производительности.
И, на что хочется обратить особое внимание, В КОД РАБОТАЮЩЕГО ПРОЕКТА ПРИ КЛАСТЕРИЗАЦИИ БАЗЫ ДАННЫХ НЕ НУЖНО ВНОСИТЬ ИЗМЕНЕНИЯ! Технологию распределения запросов на серверы базы данных мы взяли на себя, предоставим вам возможность эффективно "дирижировать" нагрузкой через определение весов для каждого дополнительного сервера.
Вам достаточно лишь настроить и подключить к платформе один или несколько стандартных недорогих серверов базы данных, с помощью удобного мастера в течении нескольких минут перенести туда данные и ... наслаждаться увеличенной в N-раз производительностью базы данных!
Если нагрузка через полгода-год на базу данных снова возрастет (вы подключите к проекту еще 5-10 филиалов и откроете 2 языковых зеркала) или планируется увеличение нагрузки в ближайшие выходные в связи с рекламной акцией - вы снова просто можете добавить к платформе стандартный сервер базы данных (операция подключения и миграции данных занимает несколько минут).
Отключается сервер базы данных также легко и интуитивно через админку.
Подключение дополнительного сервера базы данных к сайту занимает несколько минут.
Наслаждаемся эффективной и производительной работой кластеризованной базы данных. Добавляем серверы к кластеру при необходимости - за несколько минут.
Проблема 2 - "Непрерывное" резервное копирование
Итак. Нагрузку на базу данных мы победили и в случае чего - добавим в кластер сервер в течение минут. А как обстоят дела с резервным копированием данных?
Оно выполняется раз в сутки. Иногда этого недостаточно.
Допустим, наш прекрасный мощный сервер базы данных ломается - сгорает процессор или материнская плата или ее элемент. Текущие заказы и транзакции где - на дисках этого сгоревшего сервера. Нужно ехать, вынимать их оттуда, подключать к другому и т.п. - в это время вам будут беспрерывно звонить клиенты.
Есть достаточно сложные решения, как "пережить" выход из строя сервера базы данных, типа DRBD репликации, кластерных файловых систем OCFS2, GFS2... но мы рассмотрим наиболее простое, распространенное и надежное решение - да, да, снова репликацию.
Решение проблемы 2 - "Master-Slave репликация"
Master-Slave репликация, доступная в модуле платформы "1C-Битрикс: Управление сайтом", позволяет эффективно решить задачу "непрерывного" резервного копирования и высокой доступности базы данных.
При репликации, данные с главного сервера базы данных в онлайне передаются на дополнительные (SLAVE) сервера - т.е. вы имеете копию данных = онлайн бэкап в нескольких экземплярах.
Более того, чтобы не замедлять основной и дополнительные сервера при создании логического бэкапа (который также необходимо делать периодически - иначе после случайного удаления, например, таблицы заказов, у вас не будет шансов ее вернуть, т.к. изменения реплицируются на все сервера базы данных) - мы можете выделить для этого отдельный сервер базы данных, на котором и выполнять процедуру создания логического бэкапа:
А для решения задачи быстрого переключения интернет-сайта на работающую базу данных (простой проекта составит пару минут или даже меньше) - вы скриптом или вручную переключаете систему на использование дополнительного сервера базы данных, на котором, благодаря репликации, имеется самая свежая копия бизнес-данных.
Выводы
Мы рассмотрели основные задачи, которые необходимо решить для организации высокопроизводительной и отказоустойчивой конфигурации базы данных, и увидели, как они просто решаются модулем "Веб-кластер" в 10 версии платформы "1C-Битрикс: Управление сайтом" (редакции "Веб-кластер", "Бизнес веб-кластер" ).
В следующей статье поговорим о создании высокопроизводительного кластера серверов приложений - такая задача нередко возникает при создании высоконагруженных интернет-проектов на платформе 1С-Битрикс.
Технологии кластеризации 1С-Битрикс - эффективное кеширование в memcached
23.05.201111:1723.05.2011 11:17:45
Сегодня хочу рассказать о полезной возможности, которая появилась в 10 версии продукта (редакции "Веб-кластер", "Бизнес веб-кластер" ) - о кластерном кешировании в memcached. Но сначала поговорим ... просто о кешировании.
Для чего используется технология кеширования в платформе 1С-Битрикс
Веб-сайт содержит информацию, которая хранится в надежном хранилище: базе данных. В принципе, можно "ходить" за информацией в базу данных постоянно, при каждом обращении к веб-сайту. И такие веб-сайты существуют в природе
Однако, если наш веб-сайт станет популярным, то, каким бы оптимальным и качественным не был программный код - база данных быстро станет перегруженной и придется наращивать аппаратные мощности сервера базы данных, докупая дорогое топовое оборудование. Это поможет на определенное время, но, если посещаемость ресурса продолжает расти, вы упретесь в "потолок" производительности сервера базы данных и нужно будет срочно в авральном режиме переделывать приложение (например, на выходных или в период летних отпусков ).
Я нередко встречал высоконагруженные веб-сайты, при разработке которых, к сожалению, забыли или очень мало использовали технологии кэширования - таким проектам уже не хватало дорогого мощного многопроцессорного выделенного сервера для базы данных! И с каждым днем нагрузка на сервер базы данных все возрастала, система становилась все более нестабильной и на веб-сайте чаще и чаще наступали периодические конвульсии и перерывы в обслуживании клиентов.
Именно поэтому при разработке веб-сайта мы рекомендуем как можно раньше начать пользоваться преимуществами технологии кэширования, реализованными в платформе 1С-Битрикс.
Технология работает так:
1) Веб-сайт для получения необходимой информации обращается к базе данных и сохраняет ответ (например получаем список новостей).
2) В следующий раз, если информация не поменялась*, веб-сайт не обращается к базе данных, а отдает клиенту сохраненный ответ.
3) Однако, если информация поменялась, веб-сайт снова обращается к базе данных.
*) Технология, которая проверяет, обновилась информация в или нет, называется технологией управляемого кэширования (Сache Dependencies).
Но нередко вообще неважно, обновилась информация в базе данных или нет - веб-сайт вернет клиенту немного устаревшую информацию (обновляем список новостей раз в 30 минут, к примеру). Время критичности или устаревания мы устанавливаем в настройках компонента.
Таким образом, закладывая в ТЗ проекта интенсивное использование технологии кэширования, мы предусмотрительно максимально ограничиваем нагрузку на базу данных. Это позволит нашему проекту выдержать в будущем значительно более высокие нагрузки.
Возможно, у вас возник вопрос - а может заняться внедрением кэширования уже после того, как проект запущен и эксплуатируется? Опыт показывает, что внедрять в уже запущенный веб-сайт кэширование, как правило, значительно дороже и сложнее и чревато рисками и ошибками.
"Быстрокэширование" - известная ловушка
Иногда во время разработки активно используются технологии кэширования, однако при возрастании нагрузки база данных подвергается перегрузкам. Почему? Для предупреждения данного риска необходимо сначала обеспечить наиболее оптимальную работу с базой данных С ВЫКЛЮЧЕННЫМ КЭШИРОВАНИЕМ, прежде чем его включать (рекомендую менеджерам интернет-проектов взять это на заметку и включить в чеклист контроля качества проекта).
Типичный кейс данной "ловушки" такой - при включенном кэшировании кастомизированное меню использует 0 SQL-запросов, при выключенном - 5000!
Эффективное кэширование
Теперь, когда мы убедились, что использовать технологию кэширования для веб-сайта - нужно и предусмотреть кэширование необходимо еще на стадии написания ТЗ, давайте заглянем немного в будущее.
Допустим, через определенное время, наш веб-сайт стал популярным ресурсом. Благодаря активному использованию технологии кэширования мы надежно защитили базу данных от высокой нагрузки и она может выдержать 3-5 кратное превышение нагрузки.
Однако, у нас, из-за специфики веб-сайта, скопился большой объем самих закэшированных данных, использование которых (десятки тысяч файлов) вызывает "некоторые" неудобства - возросла нагрузка на дисковую подсистему. А также, к сожалению, при разработке вкрались ошибки и наши закэшированные данные чистятся не полностью и постепенно их объем на диске становится все больше и больше...
Решение есть - перенести кэш в memcached. Сервер memcached устанавливается системным администратором за считанные минуты и на веб-сайте нужно установить всего лишь одну настройку платформы 1С-Битрикс.
При использовании memcached временные данные будут храниться в оперативной памяти. Можно выделить для хранения кэша недорогой сервер с несколькими гигабайтами памяти.
При этом, устаревшие данные будут автоматически вытесняться и наш кэш перестанет "расползаться" по системе, пожирая все больше и больше места. Допустим, мы выделили в memcached 4GB места для кэширования и можем быть уверенными, что больше 4GB кэш не вырастет, а наименее часто используемые данные будут вытесняться (алгоритм LRU). Очень удобно и эффективно.
Кластеризованный кэш на базе memcached
Для увеличения производительности и отказоустойчивости проекта, мы переходим на редакцию продукта "Веб-кластер" (или "Бизнес веб-кластер" ). Теперь веб-сайт размещен на двух серверах.
Для хранения кэша уже недостаточно одного сервера memcached. Также, для эффективного использования вычислительных ресурсов мы хотим, чтобы созданный кэш на одном сервере веб-кластера использовался на другом сервере веб-кластера.
Для решения этой задачи - используем кластеризованный кэш серверов memcached ("Рабочий стол/Настройки/Веб-кластер/Memcached" ). Мы подключаем к проекту столько кэширующих серверов, сколько нам нужно - никаких ограничений.
Если подключаемые к кластеру memcached сервера разной мощности или с разным объемом оперативной памяти - желательно соответственно настроить коэффициент их использования через настройку параметра "Процент распределения нагрузки (0..100)" (1).
При настройке подсистемы кластерного кэширования обращаем внимание на параметр:
get_hits: #count# (#hitrate#%)
#hitrate# - показывает эффективность кэширования (3) и должен быть как можно ближе к 100%. Экспериментально регулируем эффективность, постепенно увеличивая объем памяти (2), выделяемой серверу memcached (limit_maxbytes). Рекомендую начинать с объема памяти в 128MB и увеличивать с шагом в 32MB, пока #hitrate# перестанет заметно увеличиваться.
Не следует опасаться того, что память memcached-серверов будет постепенно заполнять все отведенное пространство, т.к. устаревший кэш будет автоматически вытеснен и заменен наиболее актуальным.
Также хочу отметить, что при использовании нескольких memcached-серверов увеличивается надежность подсистемы кэширования - в случае отказа одного из memcached-серверов ничего страшного не произойдет, веб-сайт будет эффективно использовать оставшиеся серверы.
В результате кэш нашего веб-проекта будет всегда "в хорошем тонусе" - небольшой, централизованный и эффективный.
Итоги
1) Мы убедились, что технологии кэширования веб-проекта это не дань моде, а насущная необходимость, обеспечивающая устойчивость веб-сайта к возрастающим нагрузкам за счет максимального снижения загруженности базы данных. И нужно предусмотреть использование этих технологий как на этапе проектирования в ТЗ, так и ранних стадиях разработки.
2) Если вовремя не внедрить в веб-проект технологии кэширования, то скорее всего этим придется заниматься в самое неожиданное время (выходные, летние отпуска) из-за перегрузки базы данных.
3) Мы рассмотрели, как наиболее эффективно использовать технологии кластеризованного кэширования в memcached для повышения отказоустойчивости и производительности веб-проектов на платформе 1С-Битрикс (редакции "Веб-кластер", "Бизнес веб-кластер" ).
Для чего используется технология кеширования в платформе 1С-Битрикс
Веб-сайт содержит информацию, которая хранится в надежном хранилище: базе данных. В принципе, можно "ходить" за информацией в базу данных постоянно, при каждом обращении к веб-сайту. И такие веб-сайты существуют в природе
Однако, если наш веб-сайт станет популярным, то, каким бы оптимальным и качественным не был программный код - база данных быстро станет перегруженной и придется наращивать аппаратные мощности сервера базы данных, докупая дорогое топовое оборудование. Это поможет на определенное время, но, если посещаемость ресурса продолжает расти, вы упретесь в "потолок" производительности сервера базы данных и нужно будет срочно в авральном режиме переделывать приложение (например, на выходных или в период летних отпусков
).Я нередко встречал высоконагруженные веб-сайты, при разработке которых, к сожалению, забыли или очень мало использовали технологии кэширования - таким проектам уже не хватало дорогого мощного многопроцессорного выделенного сервера для базы данных! И с каждым днем нагрузка на сервер базы данных все возрастала, система становилась все более нестабильной и на веб-сайте чаще и чаще наступали периодические конвульсии и перерывы в обслуживании клиентов.
Именно поэтому при разработке веб-сайта мы рекомендуем как можно раньше начать пользоваться преимуществами технологии кэширования, реализованными в платформе 1С-Битрикс.
Технология работает так:
1) Веб-сайт для получения необходимой информации обращается к базе данных и сохраняет ответ (например получаем список новостей).
2) В следующий раз, если информация не поменялась*, веб-сайт не обращается к базе данных, а отдает клиенту сохраненный ответ.
3) Однако, если информация поменялась, веб-сайт снова обращается к базе данных.
*) Технология, которая проверяет, обновилась информация в или нет, называется технологией управляемого кэширования (Сache Dependencies).
Но нередко вообще неважно, обновилась информация в базе данных или нет - веб-сайт вернет клиенту немного устаревшую информацию (обновляем список новостей раз в 30 минут, к примеру). Время критичности или устаревания мы устанавливаем в настройках компонента.
Таким образом, закладывая в ТЗ проекта интенсивное использование технологии кэширования, мы предусмотрительно максимально ограничиваем нагрузку на базу данных. Это позволит нашему проекту выдержать в будущем значительно более высокие нагрузки.
Возможно, у вас возник вопрос - а может заняться внедрением кэширования уже после того, как проект запущен и эксплуатируется? Опыт показывает, что внедрять в уже запущенный веб-сайт кэширование, как правило, значительно дороже и сложнее и чревато рисками и ошибками.
"Быстрокэширование" - известная ловушка
Иногда во время разработки активно используются технологии кэширования, однако при возрастании нагрузки база данных подвергается перегрузкам. Почему? Для предупреждения данного риска необходимо сначала обеспечить наиболее оптимальную работу с базой данных С ВЫКЛЮЧЕННЫМ КЭШИРОВАНИЕМ, прежде чем его включать (рекомендую менеджерам интернет-проектов взять это на заметку и включить в чеклист контроля качества проекта).
Типичный кейс данной "ловушки" такой - при включенном кэшировании кастомизированное меню использует 0 SQL-запросов, при выключенном - 5000!
Эффективное кэширование
Теперь, когда мы убедились, что использовать технологию кэширования для веб-сайта - нужно и предусмотреть кэширование необходимо еще на стадии написания ТЗ, давайте заглянем немного в будущее.
Допустим, через определенное время, наш веб-сайт стал популярным ресурсом. Благодаря активному использованию технологии кэширования мы надежно защитили базу данных от высокой нагрузки и она может выдержать 3-5 кратное превышение нагрузки.
Однако, у нас, из-за специфики веб-сайта, скопился большой объем самих закэшированных данных, использование которых (десятки тысяч файлов) вызывает "некоторые" неудобства - возросла нагрузка на дисковую подсистему. А также, к сожалению, при разработке вкрались ошибки и наши закэшированные данные чистятся не полностью и постепенно их объем на диске становится все больше и больше...
Решение есть - перенести кэш в memcached. Сервер memcached устанавливается системным администратором за считанные минуты и на веб-сайте нужно установить всего лишь одну настройку платформы 1С-Битрикс.
При использовании memcached временные данные будут храниться в оперативной памяти. Можно выделить для хранения кэша недорогой сервер с несколькими гигабайтами памяти.
При этом, устаревшие данные будут автоматически вытесняться и наш кэш перестанет "расползаться" по системе, пожирая все больше и больше места. Допустим, мы выделили в memcached 4GB места для кэширования и можем быть уверенными, что больше 4GB кэш не вырастет, а наименее часто используемые данные будут вытесняться (алгоритм LRU). Очень удобно и эффективно.
Кластеризованный кэш на базе memcached
Для увеличения производительности и отказоустойчивости проекта, мы переходим на редакцию продукта "Веб-кластер" (или "Бизнес веб-кластер" ). Теперь веб-сайт размещен на двух серверах.
Для хранения кэша уже недостаточно одного сервера memcached. Также, для эффективного использования вычислительных ресурсов мы хотим, чтобы созданный кэш на одном сервере веб-кластера использовался на другом сервере веб-кластера.
Для решения этой задачи - используем кластеризованный кэш серверов memcached ("Рабочий стол/Настройки/Веб-кластер/Memcached" ). Мы подключаем к проекту столько кэширующих серверов, сколько нам нужно - никаких ограничений.
Если подключаемые к кластеру memcached сервера разной мощности или с разным объемом оперативной памяти - желательно соответственно настроить коэффициент их использования через настройку параметра "Процент распределения нагрузки (0..100)" (1).
При настройке подсистемы кластерного кэширования обращаем внимание на параметр:
get_hits: #count# (#hitrate#%)
#hitrate# - показывает эффективность кэширования (3) и должен быть как можно ближе к 100%. Экспериментально регулируем эффективность, постепенно увеличивая объем памяти (2), выделяемой серверу memcached (limit_maxbytes). Рекомендую начинать с объема памяти в 128MB и увеличивать с шагом в 32MB, пока #hitrate# перестанет заметно увеличиваться.
Не следует опасаться того, что память memcached-серверов будет постепенно заполнять все отведенное пространство, т.к. устаревший кэш будет автоматически вытеснен и заменен наиболее актуальным.
Также хочу отметить, что при использовании нескольких memcached-серверов увеличивается надежность подсистемы кэширования - в случае отказа одного из memcached-серверов ничего страшного не произойдет, веб-сайт будет эффективно использовать оставшиеся серверы.
В результате кэш нашего веб-проекта будет всегда "в хорошем тонусе" - небольшой, централизованный и эффективный
.Итоги
1) Мы убедились, что технологии кэширования веб-проекта это не дань моде, а насущная необходимость, обеспечивающая устойчивость веб-сайта к возрастающим нагрузкам за счет максимального снижения загруженности базы данных. И нужно предусмотреть использование этих технологий как на этапе проектирования в ТЗ, так и ранних стадиях разработки.
2) Если вовремя не внедрить в веб-проект технологии кэширования, то скорее всего этим придется заниматься в самое неожиданное время (выходные, летние отпуска) из-за перегрузки базы данных.
3) Мы рассмотрели, как наиболее эффективно использовать технологии кластеризованного кэширования в memcached для повышения отказоустойчивости и производительности веб-проектов на платформе 1С-Битрикс (редакции "Веб-кластер", "Бизнес веб-кластер" ).
Фото:
Поиск: ограничение области поиска по произвольным параметрам
20.05.201112:2520.05.2011 12:25:25
Создание отказоустойчивых высокопроизводительных систем на базе веб-кластера
17.05.201112:5117.05.2011 12:51:44
На конференции CodeFest которая прошла в Новосибирске 19-20 марта этого года я прочитал доклад по теме веб-кластерных решений.
Конференция была замечательной, спасибо организаторам!
Вообще тема веб-кластерных решений очень активно развивается. Сейчас у нас в разработке находится поддержка внешних хранилищ S3, Google и MS Azure и новое решение по веб-кластеру.
Два проекта клиентов уже работают на веб-кластере.
Сорока на хвосте принесла, что Портал ЖКХ Архангельской области работает уже на Веб-кластере.
Ну и наш сайт уже практически уже веб-кластерный
пока база данных кластеризована, мемкеш, веб-сервера уже, но еще не под нагрузкой. Скоро ждем переключение на балансировщик и тогда об этом отдельно напишем. Торговые предложения в решении «1С-Битрикс: Интернет-магазин» (поддержка SKU)
10.05.201115:5510.05.2011 15:55:14
«1С-Битрикс: Интернет-магазин» - это готовое решение из серии «коробочных» веб-проектов, построенное на основе продукта «1С-Битрикс: Управление сайтом». Всего за несколько часов, с помощью удобных Мастеров, вы не только установите и настроите свой Интернет-магазин, но и запустите его в работу.
Теперь торговые предложения есть и в решении. Обновлены шаблоны решений «Интернет магазин» и «Мобильный интернет магазин», а так же в мастера добавлена возможность создавать каталоги с поддержкой торговых предложений.
Теперь торговые предложения есть и в решении. Обновлены шаблоны решений «Интернет магазин» и «Мобильный интернет магазин», а так же в мастера добавлена возможность создавать каталоги с поддержкой торговых предложений.
Фото:
Проблема последовательных вызовов API ИБ на сервере с ZendOptimizer+
04.05.201112:3104.05.2011 12:31:52
Привет.
Обратился клиент с проблемой следующего рода
Корректная последовательность вызовов
приводит к ошибке "Неверный тип информационного блока", причем через раз запуск скрипта успешный.
Обратился клиент с проблемой следующего рода
Корректная последовательность вызовов
$IBLOCK_TYPE_ID = "altasib_feedback_".substr(md5(time()),0,3);
CModule::IncludeModule("iblock");
$arFields = array("ID" => $IBLOCK_TYPE_ID,
"LANG" => array ("ru" => array (
"NAME" => "feedback",),
"en" => array ("NAME" => "feedback",)
),
"SECTIONS" => "Y");
$obBlocktype = new CIBlockType;
if(!CIBlockType::GetByID($IBLOCK_TYPE_ID)->Fetch())
$IBLOCK_TYPE_ID = $obBlocktype->Add($arFields);
$arSites = Array();
$obSites = CSite::GetList();
while($arSite = $obSites->Fetch())
$arSites[] = $arSite["ID"];
$ib = new CIBlock;
$arFieldss = Array(
"NAME" => "GuestBook",
"CODE" => "altasib_guestbook",
"IBLOCK_TYPE_ID" => $IBLOCK_TYPE_ID,
"SITE_ID" =>$arSites,
);
if($ID = $ib->Add($arFieldss))echo "Ok!";
else
echo $ib->LAST_ERROR;
|
Есть ли хостинг не в Москве и не в Санкт-Петербурге? Знакомьтесь - NetAngels.
28.04.201118:4228.04.2011 18:42:34
Если посмотреть на , то окажется, что почти все они так или иначе (адрес офиса, контакты службы тех. поддержки, расположение датацентра) находятся в Москве или Санкт-Петербурге. И только буквально 2-3 хостера - из других городов.
Подобная картина, конечно, объяснима и понятна. И в большинстве случаев для пользователей нет большой разницы, находится ли их хостер в их же городе или же где-то еще: вопросы в тех. поддержку решаются по e-mail и по телефону, бухгалтерские документы отправляются по почте, управление всем веб-проектом - естественно - осуществляется через интернет.
Тем не менее, иногда очень хочется и "территориальной близости" - зайти в гости, более оперативно обменяться документами, провести те или иные работы с сервером, если речь идет о colocation (размещении собственного оборудования в датацентре хостинг-провайдера). Да и просто личный контакт - важен всегда.
Именно поэтому я рад познакомить всех наших существующих и потенциальных клиентов и партнеров из Уральского региона с хостером из Екатеринбурга - .
Подобная картина, конечно, объяснима и понятна. И в большинстве случаев для пользователей нет большой разницы, находится ли их хостер в их же городе или же где-то еще: вопросы в тех. поддержку решаются по e-mail и по телефону, бухгалтерские документы отправляются по почте, управление всем веб-проектом - естественно
- осуществляется через интернет.Тем не менее, иногда очень хочется и "территориальной близости" - зайти в гости, более оперативно обменяться документами, провести те или иные работы с сервером, если речь идет о colocation (размещении собственного оборудования в датацентре хостинг-провайдера). Да и просто личный контакт - важен всегда.
Именно поэтому я рад познакомить всех наших существующих и потенциальных клиентов и партнеров из Уральского региона с хостером из Екатеринбурга - .
Фото:
