| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > Оптимизация сайта, прошу помощи |
| Автор: sanich_ 2.3.2008, 19:16 | ||
| Вопрос в следующем еще не законченная страница сайта генерируется за 0,52 ms на локальном сервере, это время включает все операции (выборка из базы, работа php) Хороший ли это показатель? Надо ли оптимизировать? Страница состоит из двух частей: 1 левая рубрикатор - на ее часть отводится примерно 0,25-0,30 ms 2 Центральная список данных - очень большая 0,25-0,3ms думаю здесь нормально Вот кусок кода левой проблемной части, есть ли здесь проблемные места? Что касается базы, то выбоки не дожны тормозить, построены индексы по полям: order_ id_categ
|
| Автор: GeneralElectric 2.3.2008, 20:52 |
| скажи, ты буковки ms для красоты пишешь, или это действительно миллисекунды? прелестное утверждение. вне зависимости от того, тормозит база, или нет. Просто прелестное. |
| Автор: sanich_ 3.3.2008, 12:06 |
| 1. Это действительно милисекунды 2. Странно как то но сейчас страница генерируется за 0.13ms после кеширования, когда проставил индексы этого срузу не ощутилось, индексы начинают работать после перезагрузки сервера? |
| Автор: skyboy 3.3.2008, 12:35 |
cсразу после создания, насколько мне известно. с другой стороны, индексы - только механизм. если твои запросы не допускают использование индексов, то наличие/отсутствин индекса никак не отобразится на скорости. |
| Автор: awers 3.3.2008, 13:18 |
| жутко криво... очень много времени. |
| Автор: sanich_ 3.3.2008, 13:24 | ||
Давайте попорядку.. 1. Я построил индексы по полям которые учавствуют в запросе where и order, не силен в оптимизации но мои знания подсказали что нужно сделать именно так. Результат: страница стала генерироваться за 0,13-0,10 ms после кешировая запросов Это долго?Что можно еще сделать? Код PHP оптимизируемый? |
| Автор: awers 3.3.2008, 13:26 |
| sanich_, обычно оптимизируют логику, а не просто код |
| Автор: GeneralElectric 3.3.2008, 13:50 |
| sanich_, наверное, ты имеешь в виду все-таки секунды. а оптимизировать работу БД надо не теоретически, "я там где-то какие-то индексы поставил", а практически. В частности, измерять время выполнения запросов. А не заявлять, что они работают быстро, хотя ты это никак не проверил |
| Автор: mishaSL 3.3.2008, 14:05 |
| sanich_, дам свои несколько комментариев: 1. Код который ты привел очень "кривой". Построение этого списка нужно делать с помощью 1 запроса. Нужно избегать вложенные с цикл запросы. 2. На мой взгляд, если БД практически пустая и ты это делаешь на локальном сервере, то это большое время. (Опять таки если ты имеешь в виду 0.52 сек, если это 0.52 миллисекунды то это очень хороший результат). 3. Измерей кол-во запросов к БД при генерации одной страницы, их кол-во желательно тоже минимизировать. |
| Автор: sanich_ 3.3.2008, 14:14 | ||
Сорри, конечно же секунды, сразу не понял о чем вы мне говорили, Спасибо за советы, щас все обдумаю, отпишусь о принятых мерах |
| Автор: sanich_ 4.3.2008, 09:10 | ||||
Переписал страницу, ушел от вложенных в цикл подзапросов, но проблема со скоростью не разрешилась, теперь сам запрос долго выполянется Только на запрос уходит ~16ms-30ms
План запроса показал следующее, подскажите пожалуйста как оптимизировать |
| Автор: GeneralElectric 4.3.2008, 11:20 |
| mishaSL, вот хотел я возразить, но не стал. И что получилось. От такой вот "оптимизации" - один вред. Во-первых, запросы в цикле - не всегда зло. 20, скажем, однострочных выборок по первичному индексу никого ничем не затормозят. Во-вторых, желание "хоть тушкой, хоть чучелком" но запихнуть все в один запрос приводит к появлению таких вот монстров. Злокачественных опухолей на теле реляционной модели. Суть осталась та же, но можем гордо рапортовать, что один запрос!!! Вообще, появление в мускуле вложенных ползапросов и юниона принесло очень много вреда, учитывая тот факт, что в подавляющей массе своей люди, использующие мускуль, являются новичками. Это как коробка-автомат. Да, научиться ездить очень легко. Но водителем он уже никогда не станет. Теперь по сути проблемы. Тут уже высказывалось замечание о том, что проблема очень странная, и на таком количестве данных просто не может быть таких тормозов. Тут либо мускуль на машине загружен по самые уши, либо машина дохлая, либо еще какая-то причина, не имеющая отношения к собственно коду. sanich_, если вернуться к первому варианту. Сколько времени выполняется запрос select id_categ,categ from categ order by order_ в консоли mysql.exe и сколько - вложенный в него, из рубрик. один, не все. они должны исполняться, каждый, не дольше одной сотой секунды (мускуль пишет что-то вроде (0.05 sec). причем выполнять надо не один раз, а несколько раз подряд. И постарайся не путаться с указанием времени. Это не так уж и сложно - отличать секунды от миллисекунд и писать десятичные доли секунды. а ещё лучше - не от себя время пиши, а копируй из консоли. |
| Автор: mishaSL 4.3.2008, 11:31 | ||
sanich_, SQL запрос должен быть примерно такой:
Как его результаты обработать в PHP думаю уже разберешься. Добавлено через 8 минут и 36 секунд GeneralElectric, я не говорю что всегда стоит все пихать в один запрос, но конкретно в данной ситуации - это практически стандартный и очень простой запрос. Здесь не должно быть никаких UNION и тем более вложенных запросов. Именно по-этому я дал такую критику вложенных в цикл запросов, т.к. в данном случае не используется никаких LIMIT, что может с ростом сайта привести к проблемам в его загрузке. |
| Автор: sanich_ 4.3.2008, 12:17 |
| to GeneralElectric Ну если чесно то самый первый вариант получения данных был хотябы проще для понимания, выбрал категорию, выбрад рубрики и.д. А щас большой массив данных который еще пришлось по хитрому обработать, но повышения производительности это не прибавило! Консоли Mysql у меня нет, стоит пакет TopServer, в папке mysql5 только mysqld-max-nt.exe ядро и тулза для дампа Короче, я пользуюсь SQL yog enterprise Запрос select id_categ,categ from categ order by order_ в статус баре пишет то 0ms то 16ms, но чаще 0ms при многократном вызове, всего строк 42 Возможно не точно время определяется, подскажите как его точно засечь Запрос select id_rubrika,rubrika from rubrika where id_categ=2 7 строк, время 0ms Наверно, по этим реультатам судить о скорости сложно, надо или более точное время или проверять на в цикле на N раз вызовов, но в этой версии мускуля нет хранимок и функци раньше я проверял производительность простых запросов именно так. Щас и не знаю как проверить, разве что на ПХП мастерить цикл. |
| Автор: GeneralElectric 4.3.2008, 12:20 |
| черт возьми. 16 ms - это ОТЛИЧНАЯ СКОРОСТЬ! О чем тебе уже писали. |
| Автор: awers 4.3.2008, 13:34 |
| я только сейчас понял о чем говорил автор ... не ~0,50сек, а 0,050 ))) да супер... нормальная скорость |
| Автор: mishaSL 4.3.2008, 13:51 | ||
| Возможно скорость каждого отдельного запроса хорошая, но 43 запроса для построения меню - это на мой взгляд перебор. Если у автора возникли проблемы с обработкой данных полученных после выполнения запроса с LEFT JOIN, то вот накидал примерно как это должно выглядеть на мой взгляд:
Код не проверял, но он должен работать и логику из него можно понять. |
| Автор: sanich_ 5.3.2008, 14:53 | ||
| mishaSL, спасибо за код. Но я не много по другому сделал. Думаю что ваш код не оптимален т.к. в нем 2 цикла, а можно обойтись и одним У меня сейчас 42категори, 258 рубрик Короче ваш код протестил вышло время 0,19-0,20 sec я не знаю стоит ли пытаться еще оптимизировать или нет Мой код вытянул на 0,14-0,15sec Небольшая разница, но все же
|
| Автор: awers 5.3.2008, 14:59 |
| sanich_, опиши метод замера скорости |
| Автор: sanich_ 5.3.2008, 15:26 | ||
| Это скрипт позволяющий вычислять время работы запросов. В странице точно так же - в начале страницы засекаем в конце, после обработки кода, выводим
|
| Автор: awers 5.3.2008, 15:31 |
| да, все верно ) потестил пустой пхп файл. Время выполения 0.000233 секунд |
| Автор: mishaSL 5.3.2008, 17:39 |
| sanich_, я не говорю что мой код оптимальный, я просто привел пример выполнения одним запросом + хотел вам показать что все же лучше разделить логику от вывода информации. Хоть это и не относится к теме. Добавлено через 2 минуты и 56 секунд Если вы ходите акцентировать внимание только на скорости, то скиньте дамп БД (прикрепите к посту в архиве) и ради интереса когда у меня появится время я предложу оптимальный вариант по скорости. Думаю 0,14-0,15sec это далеко не предел мечтаний |