|
|
Инструкции по vBulletin Всевозможные мануалы, FAQ и инструкции по vBulletin |
|
Опции темы | Поиск в этой теме |
09.03.2008, 23:52 Вверх | #1 | |||
Коварный тип
|
Производительность и оптимизация скрипта vBulletin [FAQ]
Производительность и оптимизация vBulletin
Плагины, модификации, хаки Предельно осторожно используйте дополнительные расширения и продукты, особенно те, которые каким-либо образом дополнительно выводят (модифицируют) информацию на главную страницу. Обязательно проверяйте, сколько запросов делает расширение – сравнивайте количество запросов до/после установки, смотрите исходники плагинов и читайте документацию разработчиков. Оптимально, на главной странице не должно быть более 10-12-ти запросов. Метод хранения вложений Метод хранения вложений очень влияет на скорость работы форума. Хранить вложения в файловой системе «быстрее», чем в MySQL. Критичный объем вложений для перехода на файловую систему – 200-300Mb. Если вложений больше 700Mb, и метод хранения MySQL, то тормозить будет даже двухпроцессорный Xeon. Тип поиска Тип поиска очень влияет на скорость работы форума. MySQL Fulltext намного быстрее родного поиска vbulletin, кроме того, экономится размер БД, за счет удаления таблиц postindex и searchindex. Оптимизация настроек движка (Линейка 3.6.x) Ниже представлен перечень опций и настроек, которые замедляют работу форума. При возникновении проблем с производительностью на них следует обратить внимание в первую очередь. Приоритет выставлен субъективно, по своему опыту. Использован перевод от zCarot. 1. Ключевые слова META, текст авторских прав и название форума не должны быть очень большими. Даже если это не сильно загрузит страницу, это загружает глаза посетителей. (Приоритет: низкий) 2. Использовать меню быстрого перехода – Нет. Экономит код, размер страницы. (Приоритет: низкий) 3. Ссылок на номера страниц – 5-10. (Приоритет: низкий) 4. Относительные переходы для навигатора по страницам – 5-10. (Приоритет: низкий) 5. Включить маски доступа. Если вы не используете различные права и маски доступа для разных разделов, то выключите. В ранних линейках эта опция очень сильно влияла на производительность, сейчас влияние менее заметно, но существенно для больших (много разделов и пользователей) форумов. (Приоритет: средний) 6. Добавление названий шаблонов в комментарии HTML – Нет. Используйте опцию только на момент отладки шаблонов, это лишний код, пробелы, переносы строк. (Приоритет: низкий) 7. Тип пометки тем/разделов как прочитанных - Не активность/cookie. (Приоритет: низкий) 8. Выключение функций AJAX – Все функции включить. У хорошему привыкаешь быстро. (Приоритет: средний) 9. Библиотека обработки изображений – GD (IM заметно медленнее). (Приоритет: средний) 10. Вывод в формате GZIP HTML. Запущен ли apache c модулем mod_gzip? Если да, то отключаем GZIP HTML Output. Соответственно параметр «степень сжатия GZIP» не нужен. Выяснить ситуацию с gzip можно по статусу apache в phpinfo, например по строке Apache/1.3.37 (Unix) mod_gzip/1.3.26.1a PHP/4.4.4. Если у вас проблема с производительностью и нет проблем с трафиком, то не используйте gzip вообще. (Приоритет: высокий) 11. Добавлять стандартные HTTP заголовки – Нет. (Приоритет: низкий) 12. Добавлять в HTTP заголовки "No-Cache" – Нет (лучше дописать свой вариант No-Cache в headerinclude). (Приоритет: низкий) 13. Удалить страницы сообщений о перенаправлении – Да. (Приоритет: низкий) 14. Обновлять счетчик просмотра темы немедленно – Нет. (Приоритет: средний) 15. Обновлять счетчик просмотра вложений немедленно – Нет. (Приоритет: средний) 16. Дублировать информацию индекса поиска в копии темы - Нет. (Приоритет: средний) 17. Хранить таблицы стилей CSS в файлах - Да. (Приоритет: низкий) 18. Показывать иконки программ быстрых сообщений - Нет. (Приоритет: низкий) 19. Включить авто-цензора - Нет. (Приоритет: низкий) 20. Использовать почтовую очередь – Да, с блокировкой. (Приоритет: средний) 21. Количество email, отправляемых за один раз – 3-5. (Приоритет: средний) 22. Быстрый ответ - Да, Нажатие не требуется (не древовидный режим). (Приоритет: низкий) 23. Быстрое редактирование – Да. (Приоритет: низкий) 24. Макс. длина сообщения – 2000-3000 символов. (Приоритет: средний) 25. Разрешить динамические ссылки для тега [IMG] – Да. (Приоритет: низкий) 26. Минимальное время между сообщениями – Пусть думают, прежде чем писать. (Приоритет: низкий) 27. Включить управление форматированием сообщениями - Быстрый ответ и редактирование – только стандартная панель. (Приоритет: средний) 28. Макс. вложений в сообщении и Загрузка вложений – В разумных пределах (1-3) (Приоритет: низкий) 29. Разрешить дублировать вложенные изображения – Да, на проверку дублей уходит время и ресурсы. (Приоритет: высокий) 30. Создание миниатюр изображений – Да, если позволяет, с границами и размерами. (Приоритет: средний) 31. Размер миниатюр – Не более 100 пикселей. (Приоритет: средний) 32. Мин. время между поисками - Пусть думают над запросом, прежде чем искать. (Приоритет: низкий) 33. Найденных сообщений на страницу и Макс. количество результатов поиска - В разумных пределах, особенно на больших форумах. (Приоритет: средний) 34. Автоматический поиск похожих тем – Нет. (Приоритет: высокий) 35. Отображать вошедших пользователей – Если в алфавитном порядке, то нагружает очень значительно при большом количестве посетителей. (Приоритет: высокий) 36. Глубина отображения подразделов - Главная страница/ Разделы форума/отображение подразделов – 2/3/1. При большой загрузке отключить вывод подразделов на главной странице. (Приоритет: средний) 37. Отображать описание раздела в списке разделов (forumhome) – Нет, при условии, что названия разделов продуманы. (Приоритет: низкий) 38. Отображать колонку модераторов – Нет. (Приоритет: низкий) 39. Показывать пользователей, просматривающих разделы – Нет/В разброс для участников. (Приоритет: средний) 40. Показывать, кто просматривает тему – Нет/В разброс для участников. (Приоритет: средний) 41. Макс. сообщений на страницу – около 10-и. (Приоритет: высокий) 42. Варианты Макс. сообщений на страницу – 5,10,15. (Приоритет: высокий) 43. Проверять рейтинг темы – Нет. (Приоритет: средний) 44. Проверять подписку на темы – Нет. (Приоритет: средний) 45. Отображать похожие темы – Нет. (Приоритет: средний) 46. Время обновления 'Кто на Форуме' – 0 или пара минут. (Приоритет: средний) 47. Архив форума - Архивных тем на страницу - Количество сообщений на страницу при просмотре архива – в разумных пределах. (Приоритет: низкий) Выбор и оптимизация платформы В качестве основы для развертывания сервера лучше всего подойдет Unix/Linux ОС. Дистрибутивы и комплексные инсталляции по типу все-в-одном для Windows значительно медленнее своих старших Unix братьев. Не рекомендуется использовать платформу Windows для нагруженного сервера, но вполне правильно использовать Windows для параллельных экспериментов с форумом, тестирования разработок, проверок хаков на стабильность, и т.д. Можно рекомендовать к выбору Linux (Gentoo, Slackware и др.) и различные дистрибутивы BSD, на которых можно добиться хорошей производительности. Следует отметить, что MySQL в общем случае быстрее на Linux нежели на FreeBSD. В общем случае использование Linux предпочтительнее, но в частном (при достаточном опыте и стаже работы) использование FreeBSD может дать несколько важных преимуществ. В FreeBSD 6.X и 7 current ситуация кардинально улучшилась, но правильная настройка и тюнинг MySQL под FreeBSD требуют опыта и некоторых ритуальных танцев. Следует заранее подумать о проблемах дискового ввода-вывода. Помните, что swap, место_где_расположена_база, место_где_расположен_wwwroot должны по возможности быть на разных физических HDD. Другими словами, система должна иметь максимально быстрый доступ для всех часто используемых данных. Использование SCSI предпочтительнее, чем SATA/IDE. Особого внимания заслуживает тема выделения оперативной памяти под размещение часто используемых файлов и приложений. При большой нагрузке может оказаться, что пользователи получат отказ даже при заведомо выставленных правильно параметрах max_connections и back_log в mysql. Дело в том, что существует еще ограничение дескрипторов файлов и процессов в Unix. В разных системах решение разное, возможно потребуется пересборка ядра или подгрузка соответствующих модулей. Желательно, не нагружать сервер дополнительными задачами, минимально использовать сервисы и перекладывать все дополнительные задачи на другие ресурсы. Текущие версии vbulletin позволяют использовать технологию slave/master, это может быть база на физически другой машине, или локальная – для страховки. Для очень загруженных проектов следует разделить нагрузку между несколькими серверами. Например, один выделить для отдачи статического контента, другой для динамического, третий – для базы данных. Автор статьи: intolerance |
|||
09.03.2008, 23:57 Вверх | #2 | |||
Коварный тип
|
Немного резюмирую информацию по apache и php, т.к. производительность httpd сильно зависит от настроек подгружаемых модулей/расширений, главное из которых - php.
Информация имеет отношение только к относительно мало/средне загруженным проектам, прошу не отвечать с критическими стрелами в разрезе кластеров/распараллелов нагрузки и т.п. Если система не FreeBSD, обязательно проверить (во фрях по умолчанию) php.ini, раздел [MySQL], должно быть: mysql.allow_persistent = On mysql.max_persistent = -1 (не ограничено) mysql.max_links = -1 (не ограничено) В любом случае, последить за логами httpd и возможно увеличить следующие значения: max_execution_time max_input_time memory_limit Опять же, нужен баланс, т.е. задирать memory_limit сильно нельзя. Проверим конфиг vb config.php используем pg_pconnect() вместо pg_connect(), $config['MasterServer']['usepconnect'] = 1; Далее, непосредственно apache, и его конфиг httpd.conf На каждое обращение apache стартует процесс, который занимает память и камень. Суть настройки проста: нужно иметь запас запущенных серверов, не давая им (процессам) плодиться слишком часто и много, вовремя убирая лишние. Были случаи, когда вполне работающий сервер внезапно погибал под шквалом рекламы или чего-то подобного. Сейчас я не совсем администратор, и более знающие люди могут меня поправить на примерах. MaxClients можно ставить исходя из реальных показателей одновременного пребывания на сайте + накидка на случай незапланированной спам акции. К примеру, если vb показывает 300 человек онлайн при тайм-ауте для cookies 600-900 секунд, то MaxClients можно ставить ~ 150-200, максимум 250. Лишние процессы будут мешать. Timeout определяет время ожидания действия клиента. Вот удачное пояснение: обрывы связи иногда случаются и если браузер обратился к серверу, не получил ответа и послал повторный запрос (скажем, пользователь нажал reload), то у вас запустятся два процесса, причем один из них будет просто висеть и в течение указанного времени ждать, когда посетитель подтвердит свое желание посмотреть страничку. По умолчанию этот параметр установлен в 300 секунд, его можно и нужно снизить до 30, в интранете с хорошими каналами до 15-20. KeepAlive это нечто похожее на pconnect, используется существующее соединение при отправке данных клиенту без создания нового процесса. Сейчас включенный KeepAlive обязателен (экстрим apache рассматриваем не сейчас). KeepAlive имеет свой timeout, назначение которого описано выше. Значение должно быть немного меньше, чем у общего Timeout, т.к. процесс KeepAlive сугубо направлен одному клиенту, и задержки могут дорогого стоить. Я ставлю 20, интранет 7-10. Если запросов в рамках одного KeepAlive слишком много, apache может сильно тормозить. Для этого есть MaxKeepAliveRequests и MaxRequestsPerChild. Первый параметр отвечает за принудительное закрытие процесса после обработки указанного числа KeepAlive запросов, а второй - после указанного числа обычных запросов. MaxKeepAliveRequests лучше не жалеть, начать можно с 200 и смотреть за top. StartServers MinSpareServers MaxSpareServers. Запускаем при старте сервера указанное число apache, определяем минимальное и максимальное их число. К примеру: 25, 5 и 10. При указанных значениях критических отклонениях не будет, но если ставить слишком не/большие значения, производительность может резко упасть, особенно, если по каким-то причинам неадекватно отрабатывает KeepAlive. Результаты изменений отслеживаем с помощью top и netstat. В период отладки включаем LogLevel debug и выгружаем все ненужные модули и расширения apache. Многое зависит от версии php и типа его сборки. Многое зависит от версии apache и типа его сборки. Не нужно собирать apache13+ipv6 или apache13-modssl или их комбинацию, если реально нет необходимости. Не нужно переходить на apache2х если функциональность 13 вас устраивает. Автор статьи: intolerance |
|||
Метки |
vbulletin, вобла, воблы, инструкция, метод, нагрузки, настройка, оптимизация, отладка, перегружен, потребление, ресурсов, сервер, скрипта, снижение, способ |
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Видеоурок по установке и обновлению скрипта форума vBulletin | Serberg | Инструкции по vBulletin | 11 | 06.01.2012 03:34 |
Производительность мобильных видео карт ноутбуков и процессоров. | Serberg | Ноутбуки | 0 | 23.04.2011 17:29 |
[Статья] Хаки для оптимизации работы скрипта и его отладки | Serberg | Хаки для vBulletin | 1 | 23.07.2009 00:53 |
Производительность видеокарт ноутбуков | Serberg | Ноутбуки | 5 | 13.12.2008 17:42 |
Фиксы скрипта vBulletin | Serberg | vBulletin 3.х | 0 | 14.07.2008 17:05 |