как ускорить Mysql и PHP?
Вот выражение, которое будет использовать тот меньше вызова метода, чем пример quackingduck.
'%011d' % rand(1e10)
Один протест, 1e10 Float, и Kernel#rand заканчивает тем, что звонил to_i на нем, таким образом, для некоторых более высоких значений у Вас могли бы быть некоторые несоответствия. Чтобы быть более точными с литералом, Вы могли также сделать:
'%011d' % rand(10_000_000_000) # Note that underscores are ignored in integer literals
6 ответов
First of all, to be able to optimize efficiently, you need to know what it taking time :
- is PHP doing too much calculations ?
- do you have too many SQL queries ?
- do you have SQL queries that take too much time ?
- если да, то какие?
- где ваш сценарий тратит время?
С этой информацией вы можете попытаться выяснить:
- если вы можете уменьшить количество SQL-запросов
- например, если вы выполняете один и тот же запрос снова и снова, вы явно теряете время
- , другая идея - «перегруппировать» запросы, если это возможно; например, используйте только один запрос, чтобы получить 10 строк, вместо 10 запросов, которые все возвращают одну строку назад.
- если вы можете оптимизировать запросы, которые занимают слишком много времени
- либо с использованием индексов - те, которые полезны, обычно зависят от соединений и условий, которые вы используете
- , либо переписывание запросов, если они «плохие»
- Об оптимизации операторов выбора вы можете взять посмотрите на: 7.2. Оптимизация операторов SELECT и других операторов
- : если PHP выполняет слишком много вычислений, можно ли заставить его производить меньше вычислений?
- Может быть, не пересчитывать подобные вещи снова и снова?
- Или использовать более эффективные запросы?
- если PHP требует времени и SQL-сервер не перегружен, используя параллелизм (запуск нескольких вычислений одновременно ) также может помочь ускорить все это.
Тем не менее: это вполне конкретный вопрос, и ответы, вероятно, будут также довольно конкретными - а это значит, что может потребоваться дополнительная информация, если вы хотите большего, чем общий ответ .. .
Редактировать после ваших правок
Поскольку у вас есть только простые запросы, все может быть немного проще ... Может быть.
- Прежде всего: вам нужно определить, какие запросы вы выполняете.
- Я предполагаю, что из всех ваших запросов вы можете определить некоторые «типы» запросов.
- например: «
select * from a where x = 12» и «select * from a, где x = 14"имеют один и тот же тип: тот же выбор, та же таблица, то же предложение where - изменяется только значение
- , когда вы узнаете, какие запросы используются чаще всего, вы необходимо проверить, оптимизированы ли они: использование
EXPLAINпоможет- (if needed, I'm sure some people will be able to help you understand its output, if you provider it alongside the schema of you DB (tables + indexes))
- If needed : create the right indexes -- that's kind of the hard/specific part ^^
- it is also for those queries that reducing the number of queries might prove useful...
- when you're done with queries often used, it's time to go with queries that take too long ; using
microtimefrom PHP will help you find out which ones those are- другое решение - использовать 5.2.4. Журнал медленных запросов
- , когда вы идентифицировали эти запросы, как и раньше: optimize.
Перед этим, чтобы узнать, работает ли PHP слишком много или это MySQL, простой способ - использовать "верхний "команда в Linux или" диспетчер процессов " (я не использую Windows и не использую ее на английском языке - настоящее имя может быть другим) .
Если PHP является съедая 100% CPU, у вас есть виноват. Если MySQL съедает весь процессор, у вас тоже есть виноват.
Когда вы знаете, какой из них работает слишком много, это первый шаг: вы знаете, что оптимизировать в первую очередь.
Я вижу из вашей части кода что вы:
- просматриваете 10 000 элементов один за другим - их должно быть легко разделить на 2 или более фрагментов
- с помощью DOM и XPath,
- SQL-запрос для этого будет иметь вид «
select * from urls where id <5000»
- SQL-запрос для этого будет иметь вид «
- , а другой будет обрабатывать вторую половину URL-адресов.
- его запрос будет иметь вид «
select * from urls where id> = 5000»
- его запрос будет иметь вид «
Вы получите немного больше параллелизма в сети (вероятно, не проблема) и в базе данных (база данных знает, как работать с параллелизмом, и 2 сценария, использующих ее, обычно не будет слишком много) , но вы сможете обрабатывать почти вдвое больше документов за одно и то же время.
Если у вас 4 ЦП, подойдет и разделение списка URL-адресов на 4 (или даже больше; выясняется методом проб и ошибок) .
Поскольку ваш запрос находится в одной таблице и не имеет группировки или упорядочивания, маловероятно, что запрос будет медленным. Я полагаю, проблема заключается в размере и количестве полей содержимого. Похоже, что вы храните весь HTML-код веб-страницы в своей базе данных, а затем извлекаете его каждый раз, когда хотите изменить пару значений на странице. Этой ситуации следует избегать, если это вообще возможно.
Большинство научных веб-приложений (например, BLAST) имеют возможность экспортировать данные в виде текстового файла с разделителями, такого как csv. Если это так для вас, вы можете подумать о реструктуризации своей таблицы URL-адресов, чтобы у вас был один столбец на поле данных в CSV. Тогда ваши запросы на обновление будут значительно быстрее, так как вы сможете выполнять их полностью на SQL, а не загружать всю таблицу URL-адресов в PHP, доступ и извлечение одной или нескольких других записей для каждой записи URL и последующее обновление таблицы.
Предположительно, вы сохранили свои данные в виде веб-страниц, чтобы вы могли легко выгружать контент в браузер. Если вы измените схему своей базы данных, как я предложил, вам нужно будет написать шаблон веб-страницы, в который вы сможете вставить данные, когда захотите вывести их.
Knowing queries and table structures it would be easier.
If you cant give them out check if you have IN operator. MySQL tends to slow too much in there. Also try to run
EXPLAIN yourquery;
and see how it is executed. Sometimes sorting takes too much time. Try to avoid sorting on non-index columns.
внутренние соединения выполняются быстрее, чем левые или правые соединения.
Всегда ускорял выполнение моих запросов и размышлял конкретно о соединениях.
посмотрите настройки mysql в конфигурации можно отключить и т. д.
Если вы не используете индексы, это может быть основной проблемой. Есть еще много советов и приемов оптимизации. Лучше будет показать, т.е. ваш самый медленный запрос. Без входных данных помочь невозможно. Индексы и правильные соединения могут значительно ускорить это.
Если запросы будут возвращать одни и те же данные, вы можете сохранить их в файле или в памяти и выполнять их только один раз.
2 миллиона записей - это немного.
Прежде чем приступить к оптимизации, необходимо выяснить, где находится узкое место. Можете ли вы запустить сценарий на меньшем наборе данных в целях тестирования?
В этом случае вам следует настроить такой тест, а затем профилировать код. Вы можете использовать специальный профилировщик, такой как Xdebug , или, если вы сочтете его слишком сложным для настройки (на самом деле это не так сложно, но, похоже, вы уже немного углубились), вы можете чувствовать себя более комфортно с ручным подходом. Это означает запуск таймера перед частями вашего кода и его остановку после, а затем вывод результата. Затем вы можете сузить область, которая является самой медленной.
Как только вы это получите, мы сможем дать более конкретные ответы, или, возможно, вам будет очевидно, что делать.