В админке 5-10 манагеров делают одновременное обновление информации (запись в редакторе).
И тут приходят ВЕЛИКИЕ ТОРМОЗА!!!!
Где, что подточить, чтобы ускорить работу?
Discere ne cesses
В чем конкретно тормоза и в какие моменты? Если они не сохраняют что-то одновременно, то тормозов не должно быть, или должны быть и при работе одного менеджера. А заголовок «MySQL Update - Table lock» вообще непонятен, так как таблица не блокируется при обновлении записей, разве что кто-то сдуру постоянно оптимизирует ее.
Таблица возможна лочится при insert - пользователи активно добавляют страницы
общий размер таблицы (site_content) превышает 70 мб
Вот обычное состояние mysql :
| Table_locks_immediate | 1287742 |
| Table_locks_waited | 206 |
| Tc_log_max_pages_used | 0 |
| Tc_log_page_size | 0 |
| Tc_log_page_waits | 0 |
| Threads_cached | 29 |
| Threads_connected | 3 |
| Threads_created | 39 |
| Threads_running | 3 |
В очереди как правило - 5 и более запросов
"Тормоза" - от 2-х до 10 сек. при добавлении нового документа. В этот же момент - отображение данных с сайта - так же курит в очереди.
Пробовал играться с настройками mysql - как шаман с бубном :
key_buffer = 64M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 32
query_cache_limit = 1M
query_cache_size = 32M
Трудно сказать - полегчало или нет, в один момент все начинало работать быстро, потом все скатывалось обратно.
Тоже самое и с увеличением памяти...
Мучит меня смутное подозрение, что это связано с размером таблицы - размером соответствующего файла на диске, расположенного на виртуальной машине (vmware).
Discere ne cesses
Можно попробовать сменить тип таблиц с MyISAM на InnoDB, если проблема действительно в блокировке (чтобы блокировалась не таблица целиком, а строка), но я не думаю, что проблема именно в этом. По сравнению с 1287742 значение 206 незначительно, то есть в подавляющем большинстве случаев блокировки выполняются без задержек. Кроме того, не факт, что все блокировки именно от менеджеров – ряд сниппетов также могут писать информацию в таблицы и вызывать блокировки.
Вообще не уверен, что 10 редакторов могут существенно нагрузить систему. Все же большее время они подготавливают текст, и только потом сохраняют – вероятность, что несколько нажали в один и тот же момент на кнопку сохранения достаточно мала.
Другое дело, что при таком наполнении в таблице быстро появится большое количество записей, а MODx плохо подходит для этого. То есть, возможно, проблема не в одновременной работе нескольких менеджеров, а в общем размере сайта – сколько сейчас на нем страниц?
Общее количество страниц перевалило за 6 тыс
Я конечно понимаю, что для modx это чересчур, но менять на другое - нет возможности
Тем более до того как был сделан выбор в пользу modx - пробовал и жумлу и друпал, которые кстати при таком количестве страниц также чувствуют себя не уютно
Опять так, подчеркну, что тормоза начинаются именно в момент обновления сайта
При отдаче контента картина такая:
<!--
0,3558 s - время на запросы к базе данных
37 - запросов к базе данных
2,1203 s - время на работу PHP скриптов
2,4761 s - общее время на генерацию страницы
database - источник содержимого
-->
Discere ne cesses
Quote from: Vampire at May 26, 2010, 04:00 AM
2,1203 s - время на работу PHP скриптов
Это очень много, наверняка что-то сделано не слишком оптимально, и можно улучшать (6000 страниц – не так уж и много). Часто бывает достаточно внести исправления в Wayfinder. При обновлении, наверное, проблемы не при добавлении в базу, а при очистке кэша. Надо попробовать не чистить кэш каждый раз при добавлении и посмотреть, что изменится. Возможно, надо будет всем добавлять страницы, но не публиковать, а потом кто-то один все их опубликует и вручную почистит кэш.
Quote from: Vampire at May 26, 2010, 07:41 AM
При добавлении чистится весь кеш документов?? o_O
А как иначе? Практически невозможно определить, на каких страницах требуется обновить информацию – может на всех, так как везде есть меню и в него надо добавить новый пункт, может на одной, где выводится анонс новых страниц, а может вообще не надо обновлять. Универсальный алгоритм разработать очень сложно, так что приходится или чистить всегда или никогда не чистить, делая это вручную. А при 6000 документов очистка (то есть не сама очистка, а формирование новых данных) занимает много времени.
Wayfinder, если используется hideSubMenus, все равно читает в память все записи из таблицы, после чего отбирает нужные. На больших сайтах задержка может быть достаточно велика. Исправление выкладывалось на этом форуме несколько раз (если hideSubMenus не используется, выигрыша не будет). Если не найдете, оно описано на моем сайте (в подписи) в статье об исправлениях в MODx 1.0.3.
