Последние сообщения блогов

Последствия медленной отправки почты на производительность Битрикс, влияние использования постоянных соединений с БД (MySQL Innodb) на блокировки

Партнёры "Битрикс" готовят к запуску сайт с высокой ожидаемой посещаемостью и большой активностью по добавлению и модификации контента (инфоблоки).
Конфигурация: два выделенных сервера (для Веб и БД), в качестве БД использовалась MySQL с обязательным хранением таблиц в Innodb, учитывая планируемую нагрузку.

Предварительная конфигурация сайта, Apache и MySQL проводилась в соответствии с рекомендациями курса «Конфигурирование веб-систем для оптимальной работы» и активно используя "Монитор производительности" для диагностики "тяжёлых" страниц и запросов, мониторинга и настройки параметров БД (query_cache_size, tmp_table_size, max_heap_table_size, max_tmp_tables, table_cache и т.д.).
Однако, когда уже казалось, что сайт показывает хорошие результаты по производительности, проявились 2 неприятные проблемы:

• периодически без системы возникающие ошибки вида MySQL Query Error: UPDATE b_stat_day SET ... [Lock wait timeout exceeded; try restarting transaction], и в этом случае все серверные процессы Apache оказывались блокированными, сайт блокирован до перезапуска MySQL.
  
• непредсказуемое бессистемное замедление формирования отдельных страниц, которое проявлялось либо в большом времени формирования страниц - 30-60 секунд, либо даже ошибке 504 nginx timeout!
  

Начали разбираться с MySQL, мониторинг состояния производился командами:

  mysql> show full processlist;
  mysql> drop table if exists innodb_lock_monitor;
  mysql> CREATE TABLE innodb_lock_monitor (a INT) ENGINE=INNODB;
  mysql> SHOW ENGINE INNODB STATUS\G;
  mysql> DROP TABLE innodb_lock_monitor;

Выяснилось, что перед ошибкой, которую выводил PHP, в БД происходил deadlock на одних и тех же SQL-запросах типа

  INSERT INTO b_iblock_section_element...

Попытались решить проблему на уровне приложения - уменьшая количество одновременных вставок элементов инфоблоков - безрезультатно.
DEADLOCK этот довольно интересного типа insert intention waiting, описание которого можно посмотреть в багах MySQL. Возникает при множественных одновременных вставках в таблицу (как раз наш случай - активная работа с инфоблоками) и, по мнению специалистов MySQL, [как бы] багом вовсе не является, а есть правильное поведение MySQL+Innodb в определённых условиях. Ну да шут с ним
Интереснее показалось нам другое: судя по диагностике блокировок Innodb (которая выводится в секции TRANSACTION команды SHOW ENGINE INNODB STATUS), всякий раз при возникновении проблем, блокирующей оказывалась транзакция с тем же OS thread id, что и транзакция, которую ранее MySQL выбирал в качестве "жертвы" при разборе DEADLOCK'а и должен был откатить. В подтверждение этого предположения, проблема с возникшими блокировками решалась силовым удалением "виновного" thread'а:

  MYSQL> kill thread_id

Бесплатная служба поддержки MySQL пока не сильно помогла нам в анализе причин происходящего

По совету Максима Смирнова, обратили внимание на используемое постоянное соединение с БД, которое могло быть причиной подобного поведения - см., например, обсуждение в блоге Peter Zaitsev Are PHP persistent connections evil ?. Для исключения каких бы то ни было проблем и учитывая, что в случае с MySQL новые соединения создаются быстро и незначительно влияют на общую производительность сайта, мы отключили постоянное соединение с БД:

  define("DBPersistent", false); в файле dbconn.php

Блокировки больше не проявлялись.

В это же время Денис Шаромов с Максимом Смирновым обнаружили похожую периодически возникающую проблему (nginx timeout) на другом сайте, связанную с медленной работой процедуры отправки почты.

Проверили на нашем проекте - 60 секунд на отправку сообщения!
Это и была причина появления обеих проблем: и Nginx timeout, и MySQL Lock! В первом случае связь очевидна, во втором - задержка отправки почтового уведомления на хите задерживала завершение транзакции по добавлению/модификации элемента инфоблока, дальше - заложенный в MySQL-Innodb DEADLOCK и, видимо, проблема с открытыми транзакциями и постоянными соединениями. Возникала проблема неожиданно, при обработке события отправки почты на хите.
Администраторы разобрались с почтой, обработка почтовых событий была перенесена на cron:

  1) define("BX_CRONTAB_SUPPORT", true); в dbconn.php
  2) добавить в crontab вызов php -f /..../bitrix/modules/main/tools/cron_events.php


Последнюю рекомендацию, с моей точки зрения, нужно применять на всех сайтах во избежание зависимости доступности сайта от работы службы почты. Либо постоянно мониторить скорость работы почты.

Тут спросил про изменение value в полях веб-форм, пару раз тему просмотрели и бросили, никто не ответил.

Делать надо было, знаете че сделал?



Т.е. полез в html-код лежащий в arQuestions-ах, и перед параметром name, который есть во всех инпутах\ареах, вставлял нужный мне код.

Так вот может здесь кто ответит, есть ли более разумное решение?

Посмотрел, нашел в настройках веб-форм, в Ответах, там есть answer_text и answer_value... оттуда и надо было наверное плясать, да?

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

Для поиска подходящих специалистов мы использовали форму отправки заявки на создание сайта прямо на сайте Битрикс.

В заявке поставили ограничение, что партнер обязательно должен иметь опыт создания сайта с посещаемостью от 10000 хостов на Битрикс:

Несмотря на это, половина заявок пришла от партнеров, которые делают сайты-визитки. Причем менеджеры этих компаний зачастую вообще не понимают о чем речь:
Вот, например, одно из писем:


Очевидно, что человек вообще не в теме...

Удручает, что таких ответов великое множество.
Но есть же профессионалы, например, кто-то же делал сайты banki.ru, eldorado.ru и другие высоконагруженные проекты?

Специалисты, где вы, отзовитесь!

И так, 13 Марта, 2009 16:07 появилась следующая новость на данном ресурсе "Долгожданный XML-сервис!!!".

Это событие необычайно меня обрадовало, ещё бы такой сервис на таком ресурсе и сразу ручки шаловливые зачесались!

Читать подробнее...

Редактору сайта (будем называть его менеджером, чтобы не путать понятия) очень важно уметь работать с визуальным редактором, так как менеджер как правило не знает HTML\CSS\JS\PHP. И мы прописываем визуальный редактор в качестве болеутоляющего клиенту, нажившему мигрень в попытке создать подобающе оформленную страницу с текстом, картинками, таблицами, списками и т.п., не всегда предупреждая о побочных эффектах.

А именно о том, что:

1) предопределённые стили оформления элементов содержания сайта, нельзя применить к определённой ячейке или строке (только ко всей таблице целиком)

2) не может быть и речи об изменении ширины столбца или высоты строки таблицы без указания точных размеров, если клиент не выучил, что дизайн-шаблон фиксированный, максимальная ширина для контента столько-то пикселей (иначе в ie6..., ну вы поняли), что ширина пикселя это 1/72 дюйма, а дюйм 2,54 сантиметра (тогда как все давно уже пользуются http://www.ita.es/jquery/jquery.kiketable.colsizable.htm#section-4 - последняя таблица).

3) фоновые изображения в предопределённых стилях оформления элементов содержания сайта не отображаются в визуальном редакторе

4) сами "предопределённые стили оформления" оставляют желать лучшего: <span class="мой_стиль"> это конечно хорошо, но изменить стиль ненумерованного списка вам не удастся, кроме как превратить его в опухоль вида:



А это значит никаких собственных list-style-image, либо только один вид, без надежды на 2 и более разных оформления. Оправдываться приходится фразой, что "практически нереально определять css-селекторы в styles.css шаблона сайта вида tag.class {} и довольствоваться приходится селекторами .class {} подразумевая span.class {}".

5) в визуальном редакторе клиент не сможет сделать ячейку таблицы заголовком (то что называется )

6) а если клиент посчитает себя очень умным и захочет что-то поменять в режиме исходного кода, код предстанет ему в таком неразборчивом виде, что его эго моментально вернётся на место:



Думаю, не секрет, что верстальщики пишут код руками (или они не верстальщики вообще) и указанную выше таблицу скорее всего сформируют в таком виде:



Я так проверяю психику кандидата на вакансию: заставляю написать 20-30 строчек html-кода, затем копирую код в визуальный редактор (в режиме исходного кода) и делаю "Трах-тибидох", переключаясь в режим визуального редактирования и обратно в исходный код. В полученном коде прошу найти, какой тег я удалил:



Фокус в том что никакой тег я не удалял и вообще ничего не делал, за меня все сделал редактор.

Вернёмся к побочным эффектам:

6) даже если клиент и знает что <thead>, <tbody> и <tfoot> - это какие-то теги и что они должны что-то значить, никто не скажет зачем по умолчанию в новую таблицу ставится тег <tbody> и как (раз уж тело вставляется) вставить голову и ноги - медицина бессильна.

7) отдельного внимания заслуживает "" - да, есть окошко где эти параметры меняются. А еще у таблицы есть align, background, bgcolor, bordercolor, cols, height и width - может стоит и их указывать ВСЕГДА? Я наверно под страхом смерти не смогу объяснить на понятном менеджеру языке чем отличается cellspacing от cellpadding в окне свойств таблицы и почему они там есть, а вот bgcolor и bordercolor нет.

В том же окне есть выбор стиля таблицы - отлично! Только давайте фильтровать стили, которые предлагаются в списке (например только селекторы table.class {} ), хотя нет, я забыл - практически нереально определять css-селекторы в styles.css шаблона сайта вида tag.class {} ....

Это все, что мне удалось вспомнить, выйдя из комы, в которую впал после публикации нескольких, на первый взгляд, простых, страниц текста. Я как мог удерживал себя от попыток открыть notepad++ и с удовлетворением окончательно нажать Save уже через 20 минут. Там я бы сделал <div class="blockLeftPadding">, <ul class="inlineItems"> или даже <hr class="lightShadow" />, но для клиента такое искусство осталось бы недоступно, как хрустальная ваза, на которую он может только смотреть, не в силах повторить на других страницах.

PS. мне очень импонирует идеология БУС, именно поэтому я и написал.

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

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

Я далеко не профессионал, я хотел чтобы мне помогла эта книга.. Пока ужасно, извините. Буду надеяться на остальные 350 страниц.

Хочу поздравить всех прекрасных девушек с этим прекрасным праздником весны и подарить Вам вот эти строки:

Спасибо вам за умопомрачение
От лицезрения вашей красоты,
За нежности счастливые мгновенья,
За наши мысли, грезы и мечты.

Так будьте ж счастливы и радуйте собою,
Не прекращая ни на миг цвести,
Удачи вам, весеннего настроя,
Поклонников, улыбок и любви!
@}->--- @}->--- @}->--- @}->--- @}->---
@}->--- @}->--- @}->--- @}->--- @}->---
@}->--- @}->--- @}->--- @}->--- @}->---
@}->--- @}->--- @}->--- @}->--- @}->---
@}->--- @}->--- @}->--- @}->--- @}->---  

В последнее время dev.1c-bitrix.ru стал чуть ли не самым посещаемым моим ресурсом.. вот думаю попробовать внутренние возможности ведения блогов - на своих сайтах как-то желания нет, а тут может атмосфера какая-то другая, "разработческая" ))

Группа видна всем пользователям - и в неё приглашаются все интересующиеся работой с SMS в Битриксе.

Мы обсуждаем:

• идеи по применению SMS на сайтах;
  
• методики работы с SMS-сервисами;
  
• ПО для работы с SMS;
  
• финансовые вопросы (например, оплата товаров с помощью SMS, закупка пакетов SMS у операторов);
  
• и всё остальное, связанное с SMS и мобильной связью.
  

Пожелания к участникам:

• пожалуйста, высказывайте идеи, предложения и замечания аргументированно и так, чтобы это было понятно всем;
  
• не стоит задавать здесь узкоспециальные вопросы по решению проблем: для этого есть техподдержка;
  
• мы все работаем, причём в разных часовых поясах и над разными проектами - поэтому не всегда можем отвечать оперативно.
  
• чтобы ваше сообщение лучше искалось, указывайте, пожалуйста, теги;
  
• если необходимо приложить иллюстрацию - воспользуйтесь сервисом хранения изоборажений (например, http://www.picamatic.com/).
  

Решил я серьезно заняться форумом Битрикс, пока ребята уже почти доделывают новую версию форума. Вот-вот и она появится. Уже почти. Но я нетерпелив. Первая мелочь, которую накидал - вывод модераторов форумов на индексной странице.  

Читать подробнее...

Создал средствами Битрикса файл sitemap для Гугля. Всё разместил как написано в битриксе, а гугль на этот файл выдаёт:




А еще внутри файла sitemap_000.xml я нашел такую строку:



У меня отродясь не было папки users и файла 2.php там. Кто-нибудь знает что это такое?