Есть проект. Не такой уж и большой, ну такой, средний. База где-то 200 мегов и растет потихоньку. Работает не быстро, я бы даже сказал медленно.
Я подумал, что есть два пути увеличения быстродействия: оптимизация запросов (ибо есть куда оптимизировать) или система кэширования.
В идеале конечно оба пути, но начинать наверное надо с одного чего-то? Так вот с чего?
С одной стороны если взять простенькую систему кэширования, то скорее всего прирост будет. С другой стороны хорошо оптимизированные запросы не всегда требуют кэширования.
Так с чего начать?
Спустя 14 минут, 18 секунд (29.09.2009 - 18:59) Nikitian написал(а):
Начать с расстановки индексов - это не должно поломать уже работающее. Главное грамотно расставить, чтобы медленнее вставки, апдейты происходить не стали. Далее есть смысла отлавливать "медленные" запросы и оптимизировать их. При невозможности - кэшировать.
Уже далее можно заняться кэшированием отдельных блоков или целых страниц.
Уже далее можно заняться кэшированием отдельных блоков или целых страниц.
Спустя 2 минуты, 56 секунд (29.09.2009 - 19:02) sergeiss написал(а):
По-моему, вопрос слишком абстрактный
Потому что только ты знаешь свой проект. В какой-то его части можно и запросы пооптимизировать, а где-то и кэшировать.
Хотя, наверное, можно и какие-то другие пути оптимизации предложить. Но это можно сделать, только зная структуру БД. Например, сделать какие-то изменения в структуре таблиц... Мог же ты на каком-то этапе понять, что структура таблиц не соответствует требованиям текущего момента?

Хотя, наверное, можно и какие-то другие пути оптимизации предложить. Но это можно сделать, только зная структуру БД. Например, сделать какие-то изменения в структуре таблиц... Мог же ты на каком-то этапе понять, что структура таблиц не соответствует требованиям текущего момента?
Спустя 14 минут, 22 секунды (29.09.2009 - 19:16) Sylex написал(а):
анализ, поиск самых медленных участков
Спустя 10 минут, 54 секунды (29.09.2009 - 19:27) waldicom написал(а):
Цитата (Nikitian @ 29.09.2009 - 17:59) |
ачать с расстановки индексов - это не должно поломать уже работающее. Главное грамотно расставить, чтобы медленнее вставки, апдейты происходить не стали |
Про индексы я не подумал. База два раза в сутки получает очень большой апдейт. На время апдейта думал отключать индексы, чтобы легче было. А основная нагрузка - это чтение.
Цитата (sergeiss @ 29.09.2009 - 18:02) |
Мог же ты на каком-то этапе понять, что структура таблиц не соответствует требованиям текущего момента? |
Да, при принятии проекта там уже сложилась каша... Имена полей в базе на английском, немецком и даже транслите. При выборке полей выбираются все поля в независимости от того, нужны ли все поля или нет. Так со структурой можно поработать. Единственно что боюсь, если покромсать не нужные поля, не вылезет ли это потом в каком-либо труднодоступном месте боком (автоматические юнит-тесты не используются)
Спустя 7 минут, 32 секунды (29.09.2009 - 19:35) glock18 написал(а):
Цитата |
Начать с расстановки индексов - это не должно поломать уже работающее. Главное грамотно расставить, чтобы медленнее вставки, апдейты происходить не стали. Далее есть смысла отлавливать "медленные" запросы и оптимизировать их. При невозможности - кэшировать. Уже далее можно заняться кэшированием отдельных блоков или целых страниц. |
это определенно потенциально наиболее выигрышный вариант.
Цитата |
С одной стороны если взять простенькую систему кэширования, то скорее всего прирост будет. |
По моим наблюдениям, это зависит от размера озу, выделяемого на все эти дела. Кэш сервер требует памяти, либо будет писать в файлы при нехватке памяти, что может сказаться на производительности совершенно обратным образом. Правда следует отметить, что когда у меня была такая проблема с memcached, то возможно просто он не был достаточно хорошо отстроен.
Если до сих пор в проекте не используется zend optimizer или eac, то их конечно тоже надо подрубать, особенно, если проект достиг немалых размеров и в отношении исходного кода в том числе.
Если дело касается только дбмс, то, основное, думаю, уже сказано.
Спустя 1 минута, 27 секунд (29.09.2009 - 19:36) glock18 написал(а):
Цитата |
Единственно что боюсь, если покромсать не нужные поля, не вылезет ли это потом в каком-либо труднодоступном месте боком (автоматические юнит-тесты не используются) |
это скорее всего не стоит

Спустя 13 минут, 23 секунды (29.09.2009 - 19:49) kirik написал(а):
Если проект у тебя надолго, то лучше по уму сразу все делать. Лучше начать с оптимизации запросов/таблиц, а потом уже кэш успеешь прикрутить.
Спустя 11 часов, 3 минуты, 57 секунд (30.09.2009 - 06:53) Sylex написал(а):
Цитата (Nikitian @ 29.09.2009 - 21:59) |
Начать с расстановки индексов |
а иногда - с их удаления

полезные ссылочки:
http://www.xdebug.org/docs/profiler
http://sourceforge.net/projects/wincachegrind/
Спустя 6 часов, 28 минут, 15 секунд (30.09.2009 - 13:22) waldicom написал(а):
Мужики, спасибо всем за советы, составил из них себе примерный план, как и что делать.
Еще вопрос: чтобы увидеть, принесли ли все телодвижения желаемый результат, хотелось бы поиметь такую штуку, которая мерит время, затраченное на отработку запросов.
Если запросы единичные, то понятно, что можно использовать explain и query profiler.
Но что делать, если хочется смотреть все эти данные "on-fly"?
Время генерации я тоже вывожу, но время генерации страницы - это все же другое.
Еще вопрос: чтобы увидеть, принесли ли все телодвижения желаемый результат, хотелось бы поиметь такую штуку, которая мерит время, затраченное на отработку запросов.
Если запросы единичные, то понятно, что можно использовать explain и query profiler.
Но что делать, если хочется смотреть все эти данные "on-fly"?
Время генерации я тоже вывожу, но время генерации страницы - это все же другое.
Спустя 29 минут, 57 секунд (30.09.2009 - 13:52) glock18 написал(а):
Цитата |
Но что делать, если хочется смотреть все эти данные "on-fly"? |
ну, можно по аналогии с временем генерации страницы засекать время на отработку запроса. потом писать в файл или в бд. или еще куда.
Спустя 1 час, 4 минуты, 10 секунд (30.09.2009 - 14:56) PandoraBox2007 написал(а):
Спустя 1 час, 58 минут, 47 секунд (30.09.2009 - 16:55) waldicom написал(а):
Цитата (glock18 @ 30.09.2009 - 12:52) |
ну, можно по аналогии с временем генерации страницы засекать время на отработку запроса. потом писать в файл или в бд. или еще куда. |
Многовастенько че-то выходит... Но наверное последую совету.
Цитата (PandoraBox2007 @ 30.09.2009 - 13:56) |
http://habrahabr.ru/blogs/mysql/70435/ |
Хорошая штука... Вот только на хосте стоит MySQL 5.0.32, а профайлинг доступен только с 5.0.37... Редиски блин

Спустя 3 часа, 53 минуты, 22 секунды (30.09.2009 - 20:48) kirik написал(а):
Цитата (waldicom @ 30.09.2009 - 05:22) |
Но что делать, если хочется смотреть все эти данные "on-fly"? |
Если запросы делаются не на прямую через mysql_query (или что там у тебя), то можно в этот метод/функцию вставить счетчик (из старого движка выдернул):
PHP |
$_stat = array('queries_time' => 0, 'queries_num' => 0); |
Спустя 2 года, 10 месяцев, 11 дней, 3 часа, 53 минуты, 58 секунд (12.08.2012 - 00:42) VELIK505 написал(а):
Разбивать базу на несколько частей. Выносить базу на другой сервер. Оптизация sql запросов. Расстановка индексов. Кеширование sql запросов путём мемкеша например. Оптимизация самого mysql сервера путём перелопачивания my.cnf
Спустя 16 часов, 56 минут, 16 секунд (12.08.2012 - 17:38) Игорь_Vasinsky написал(а):
VELIK505
тема то древней некуда))
тема то древней некуда))
_____________
Свои мозги еще никто не отменял.
Телепатов нету.