- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте.
Вообщем есть сайт на тему СМИ, грузится ужасно долго.
Это еще нормально, обычно больше бывает. Ну если на сайт зайдет более 50 пользователей, страница около 50-60 секунд генерируется.
Сайт построен на UMI.CMS хостинг hoster.kz с недавнего времени переехали на VPS, но нечего особого неизменилось. По рекомендациям imbalance решил обратится сюда.
По по поводу разработчиков самого сайта blackfox ( Директор Дмитрий Кубай ) говорят а куда вы смотрели когда принимали сайт.:dont:
По поводу разработчиков UMI.CMS пишут мол у нас есть порталы и по больше и они просто летают. В нашем случае заявка принята в обработку под Н-номером. И все.
Надеюсь тут помогут.
Ну переездом на vds вы бы точно скорость генерации не сократили, ибо на шареде мощность всего ядра доступна, просто считается, а на vds Зачастую жестко ограничена.
А так много еще аспектов, например если большое число файлов в генерации задействовано, по диску будет wait
esetnod, здесь есть люди которые могут помочь?
Нужны профессионалы своего дела.
Попытки решить проблему нашего сис. админа он конечно признался мне что в вебе неочень, но все таки попытался. Переписка нашего админа поддержкой UMI.CMS:
Мля, вот из-за одной очепятки теперь мучайся, пересылай все )
Читать снизу вверх
Однако, у нас такие запросы часто наблюдаются среди медленных (> 2 сек).
2 х Xeon 2000 MHz (виртуальный выделенный сервер)
2 Gb RAM
Например, вот из свежего:
[root@lada ~]$ tail -n 20 /var/log/mysql_slow_queries.log
# Query_time: 13.088721 Lock_time: 0.000045 Rows_sent: 38 Rows_examined: 38
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '45761';
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 4.329452 Lock_time: 0.000059 Rows_sent: 10 Rows_examined: 10
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '27227';
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 5.594441 Lock_time: 0.000081 Rows_sent: 4 Rows_examined: 4
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '44096';
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 3.953360 Lock_time: 0.000073 Rows_sent: 11 Rows_examined: 11
SET timestamp=1287415118;
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '2373';
# Time: 101018 21:29:43
# User@Host: ladakz_dbuser[ladakz_dbuser] @ localhost []
# Query_time: 5.991091 Lock_time: 0.000044 Rows_sent: 0 Rows_examined: 1
SET timestamp=1287415783;
DELETE FROM cms3_object_content WHERE obj_id = '44704' AND (field_id = '8792');
Заметьте, что в условии для DELETE указывается не только объект, но и поле. Разве у одного объекта в одном поле может быть больше одной записи?
Сейчас появились еще долгие SELECT из cms3_object_content
Возможные причины:
1. Фрагментированный кэш запросов (я его всего 2 дня не дефрагментировал). Фрагментация кэша составила 21%. Сейчас я сделал FLUSH TABLE CACHE и уменьшил query_cache_min_res_unit до 2 K (было 4 К)
2. Фрагментированная таблица (также 2 дня не касался). В данный момент решил ничего с ней не делать, вдруг у вас идеи появятся проверить что-то.
Напомню, что непосредственно перед письмом в техподдержку я выгружал БД, удалял ИнноДБ-файлы и загрузил базу обратно.
Мы проконсультировались с разработчиками. Использование сочетания DELETE+INSERT связано с особенностью архитектуры системы UMI.CMS. Таким образом решается проблема, когда одному объекту соответствует большое количество строк в одной таблице. Тогда оказывается быстрее удалить и заново создать записи.Также, использование UPDATE может привести к ошибкам и нарушить целостность данных.
С уважением, Кирилл Новичихин
16.10.2010 09:35 - Игорь Янковский написал(а):
Здравствуйте.
В данный момент я изучаю проблему с нагрузкой на процессор при генерации страниц сайта lada.kz (UMI.CMS Pro Commerce 2.8.1.3, сборка 15820)
Я не исключаю того, что разработчики изменяли оригинальный код UMI
Сразу же оговорюсь, что до недавнего времени с этой КМС я не сталкивался – т.е. уровень моих знаний здесь небольшой
Основную нагрузку в данный момент дает mysql.
Скрипты вроде mysqltuner.pl и tuning-primer.sh ничего плохого не говорят, только про фрагментацию. Ресурсов для mysql выделено достаточно.
Сделано удаление innodb-файлов и загрузка из дампа, чтобы исключить фрагментацию.
Но фрагментация происходит быстро. В логе mysql в первую очередь бросились в глаза транзакции вида
--- cut ---
2 Query START TRANSACTION /* Saving object 27227 */
2 Query DELETE FROM cms3_object_content WHERE obj_id = '27227' AND (field_id = '9321')
2 Query INSERT INTO cms3_object_content (obj_id, field_id, int_val) VALUES('27227', '9321', '141605')
2 Query SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '27227'
2 Query SELECT SQL_CACHE int_val FROM cms3_object_content WHERE obj_id = '27227' AND field_id = '9321' LIMIT 1
2 Query START TRANSACTION /* Updating object #27227 info */
2 Query UPDATE cms3_objects SET name = 'Новости Актау - Газета ЛАДА', type_id = '776', is_locked = '0', owner_id = '27148', guid = '' WHERE id = '27227'
2 Query COMMIT
2 Query SELECT SQL_CACHE name, type_id, is_locked, owner_id, guid FROM cms3_objects WHERE id = '27227'
2 Query COMMIT
--- cut ---
field_id = '9321'
id - 9321
name - count_view
title - Просмотров
Понятно, что обновляется кол-во просмотров в таблице, но зачем делать DELETE и сразу же INSERT, а не просто UPDATE?
Точно такие же транзакции выполняются при отображении баннеров.
name - views_count
title - i18n::field-views_count
И для изменения последнего посещения пользователя
Name - last_request_time
Title - i18n::field-last_request_time
Хочется изменить php-код так, чтобы вместо DELETE+INSERT было сразу UPDATE
Или, если при создании объекта поля 9321, 8792, 8967, … могут не создаваться автоматически, усложнить немного, например
SELECT count(*) FROM cms3_object_content WHERE obj_id = '27227' AND (field_id = '9321')
И в зависимости от результата INSERT или UPDATE
По по поводу разработчиков самого сайта blackfox ( Директор Дмитрий Кубай ) говорят а куда вы смотрели когда принимали сайт.🙅
При разработке нового софта, с длиной исходных текстов более 2000 строк, ошибки в коде есть 100%
Иногда ошибок очень много.
Для их исправления существует период тестовой эксплуатации и сопровождение разработчиком в течении хотя бы года.
При приемке сайта проверить отсутствие ошибок в новой CMS не возможно.
Для этого нужны месяцы эксплуатации.
Если разработчик вам так ответил, то это его характеризует не с лучшей стороны.
Выяснить причину почему сайт тормозит – это обязанность разработчика.
Сопровождение у разработчика нужно обговаривать заранее.
Причин может быть множество.
1) слабый ВПС
2) неоптимизированные запросы к MySQL, структура таблиц, индексов
3) Неоптимизированные скрипты PHP
4) и много чего еще.
Как бы год консультации и всевозможной помощи консультации подразумевалось, но после того как оплата поступила на счет, все! Общение только с менеджером(его работу я понял, тянуть время и говорить много красивых слов).
zexis, что можете посоветовать?
Ну, то что этот VPS слабенький и так понятно.
Попробуйте в mysql увеличить innodb_buffer_pool_size ( странно что mysqltuner вам этого не посоветовал).
innodb_flush_log_at_trx_commit=0.
Как бы год консультации и всевозможной помощи консультации подразумевалось, но после того как оплата поступила на счет, все!
а что подразумевалось в договоре ?
Я бы в этой ситуации установил скрипты и базу данных этого сайта на свой компьютер в офисе или дома и тестировал его, какую нагрузку может держать CMS.
Тестировать можно утилитой ab из апача.
Если бы выяснилось, что даже на отдельном компьютере сайт тормозит, то предъявлял бы уже аргументированные претензии разработчику.
Прежде чем заниматься тюнингом параметров MySQL, нужно убедится что оптимально делаются запросы к MySQL и используются индексы.
Сейчас точно уже и не вспомню так как все документы в офисе лежат, да и вообще я к этому делу присоединился в самом конце к сожалению.
Почему? И как вы это поняли?
Тестировать можно утилитой ab из апача.
Если бы выяснилось, что даже на отдельном компьютере сайт тормозит, то предъявлял бы уже аргументированные претензии разработчику.
Прежде чем заниматься тюнингом параметров MySQL, нужно убедится что оптимально делаются запросы к MySQL и используются индексы.
Хорошо буду пробывать.
Изначально я все валил на хостеров, они валят все на кривых разработчиков. Разработчики как я уже сказал нефига исправлять нехотят.
musulman,
1. Они все такие. В этом суть их бизнеса. Покупаете самый слабый но физический сервер с одним HDD - все резко улучшится.
2. # Query_time: 5.594441 Lock_time: 0.000081 Rows_sent: 4 Rows_examined: 4
SELECT field_id, int_val, varchar_val, text_val, rel_val, tree_val, float_val FROM cms3_object_content WHERE obj_id = '44096';
крайне медленный запрос не затрагивающий однако большое число записей. Характерный признак загруженного диска.
большие буфера и innodb_flush_log_at_trx_commit=0 в какой-то степени могут помочь.
кстати, и в руководстве по битриксу так рекомендуют, несмотря на опасность потерять горячие данные.
query_cache в мускуле настроен?
eAccelerator еще к пхп можно прикрутить, если не стоит..
это так, из административного, что можно сделать быстро и что может помочь и дать время ковырять движку спокойно..
ufkr, извините. а как это можно проверить?
Хостер:
Папка есть, файла нет.
Как эт еще можно проверить?
Есть кто уже сталкивался с такой проблемой? И как ее можно решить? Нужны профессионалы.
Я вот думаю переверстать его на css-спрайты, но это ведь нескажется некак на отдачу от сервера. Это скорее повлияет на отдачу браузера или я неправ?