Регистрация
Вход через соцсети
Восстановление пароля

Нагрузка на хостинг

Новый топик
Страницы: 1  |  2
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
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
DiGGy

Зарегистрирован:
2005-04-04
Сообщений: 1546

Можно и от неткета отказаться и использовать статичный html )

То что автор на храбре сократил кол-во запросов со 150 до 50 - это не показатель. Кол-во запросов зависит не только от движка, а от квалификации того, кто собирает на нем сайт. Что в данном случае скорее имело место быть.

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

На счет s_list_class - вы можете корректировать sql-запрос в нем, можете составить свой. Ф-ия полезна, когда вам требуется выводить записи с кнопками администрирования. В остальных случаях можно от нее отказаться - ну если не лень структуру таблиц выучить и вывести именно то что надо, да еще и с учетом того, что версия неткета может изменится и ваш собственный sql-запрос перестанет работать.

зы. Из опыта - один из проектов начали досить, кол-во юзеров доходило до 25тыс. в сутки. Обычные хостинговые компании просто загибались. Вопрос решился сменой хостера и установкой кеширования средствами апача. Ни о какой оптимизации запросов и речи не шло...

Temet nosce...
198 196 2010-12-28 14:01:53 10696
Страницы: 1  |  2
Описание проекта