|
|
03.09.2010, 16:22
|
|
lalals
Зарегистрирован:
2010-04-07
Сообщений: 12
|
поделитесь у кого какая и может быть кто-то занимался оптимизацией. сейчас всего порядка 1200 уников в сутки и отведенные на хостинге ресурсы почти кончились (с пиками нагрузки под 350% во время наплыва основной массы). что будет когда цифра перевалит за 1500 даже страшно подумать.
что делать?
|
|
|
06.09.2010, 08:28
|
|
malich
Андрей Малков
Зарегистрирован:
2005-08-09
Сообщений: 522
|
Оптимизировать sql запросы, отказываться от:
- opt
- opt_case
- s_list_class
и так далее, нужно смотреть что конкретно вызывает нагрузку при формировании страниц.
Использовать хеширование?
|
|
|
07.09.2010, 12:43
|
|
Гость
Гость
|
кэширование включить
|
|
|
07.09.2010, 15:22
|
|
pe3udent
Артур Юсупов
Зарегистрирован:
2008-04-03
Сообщений: 220
|
Конфигурацию железа можно глянуть?
|
|
|
29.09.2010, 14:41
|
|
lalals
Зарегистрирован:
2010-04-07
Сообщений: 12
|
Intel(R) Xeon(TM) CPU 3.00GHz
6% от одного ядра наши.
для такой машинки 6% это прилично. вся беда в большом количестве запросов к бд на каждую страницу (главная содержит 57, каталог порядка 80). и это после небольшой оптимизации.
|
|
|
29.09.2010, 16:53
|
|
Гость
Гость
|
На сайте: видео, новости, картинки: 1200 хитов держало(без учета нагрузки в админке и просмотров с целью а как это на сайте выглядит, реально под 2-2,5 тыс.) на VDS 128 Мб, 600 проц., правда потом перехали на 256 -> 350 мб, проблем бы не было если бы 512 было. Поиск правда грузит хорошо во время индексации. Дело в том сколько одновременно заходят, а не количество в день хитов, главный показатель…
|
|
|
29.09.2010, 16:56
|
|
Гость
Гость
|
кстати странно, что главная меньше, чем остальные, наверное у вас динамически какие-то показатели подсчитываются, дело не совсем в количестве, опять же, запросов, я видел на Битриксе запрос 1 исполнялся 3 секунды и только запрос к базе. Если у вас 80 запросов на 1 странице и поиск ночью индексит это все… то я не знаю… хотя кэширование снимает такую проблему
|
|
|
26.10.2010, 16:40
|
|
lalals
Зарегистрирован:
2010-04-07
Сообщений: 12
|
анализировал в очередной раз статистику нагрузки. ~2000 уников в сутки и хостер начал ругаться.
основная проблема на мой взгляд поля взаимосвязи между объектами (генерируют INNER JOIN) + немалое количество полей в обоих объектах + большое количество записей в таблицах. если вставлять через s_list_class вообще труба.
|
|
|
27.10.2010, 16:21
|
|
DiGGy
DiGGy
Зарегистрирован:
2005-04-04
Сообщений: 1546
|
как вариант - если есть файлы в компонентах, то надо сменить тип файловой системы с защищенной на любую другую.
Temet nosce...
|
|
|
09.12.2010, 08:21
|
|
Гость
Гость
|
от s_list_class вообще рекомендуют отказываться, если нет возможности кэшировать на достаточный срок по времени
Цитата:Не надо использовать функцию s_list_class если подобных вызовов набирается хотя бы > 3. Дело в том, что вызов такой функции приводит к нескольким запросам к БД (от 5 и гораздо больше) (получить шаблон, данные компонента и т. п.) Если на странице нужно вывести данные из другого компонента, то лучше написать функцию для вывода этих данных в functions.inc.php дефолтного модуля. В подобном случае практически всегда можно обойтись 1 запросом.
Вообще, один вызов s_list_class может создавать десятки запросов к БД! В зависимости от компонента, объекты которого выводятся.
http://habrahabr.ru/blogs/webdev/43485/
|
|
|
22.12.2010, 22:16
|
|
DiGGy
DiGGy
Зарегистрирован:
2005-04-04
Сообщений: 1546
|
Можно и от неткета отказаться и использовать статичный html )
То что автор на храбре сократил кол-во запросов со 150 до 50 - это не показатель. Кол-во запросов зависит не только от движка, а от квалификации того, кто собирает на нем сайт. Что в данном случае скорее имело место быть.
Очень важно наличие индексов у ключевых полей, по которым связи строятся. Немаловажным является периодическая оптимизация таблиц.
На счет s_list_class - вы можете корректировать sql-запрос в нем, можете составить свой. Ф-ия полезна, когда вам требуется выводить записи с кнопками администрирования. В остальных случаях можно от нее отказаться - ну если не лень структуру таблиц выучить и вывести именно то что надо, да еще и с учетом того, что версия неткета может изменится и ваш собственный sql-запрос перестанет работать.
зы. Из опыта - один из проектов начали досить, кол-во юзеров доходило до 25тыс. в сутки. Обычные хостинговые компании просто загибались. Вопрос решился сменой хостера и установкой кеширования средствами апача. Ни о какой оптимизации запросов и речи не шло...
Temet nosce...
|
