Как уменьшить нагрузку на сервер и ускорить WordPress с помощью Memcached. Ускоряем работу WordPress снижаем нагрузку на сервер

В этой статье я хочу рассказать о способах оптимизации блога WordPress для снижения его нагрузки на сервер . Рано или поздно всем приходится задумываться над этой проблемой. Так как движок WordPress основан на PHP и MySQL, то каждый раз при каждом обращении к страницам сайта он создает определенную нагрузку на сервер. И чем больше этих обращений, тем больше нагрузка. Так как большинство из нас использует обычный хостинг, то всем приходится подчиняться определенным правилам, одним из которых есть ограничение нагрузки на сервер. Исходя из этого, есть смысл оптимизации своего блога WordPress.

Итак, для начала давайте разберем принцип работы движка на основе PHP+MySQL.
Когда пользователь обращается к какой-то странице сайта, на сервере (при помощи специального серверного языка или просто PHP) идет обращение к так называемой базе данных, которая содержит в себе всю информацию. Затем нужная информация вытаскивается и формируется статическая HTML страница.

Все довольно просто и очень эффективно. Это позволяет нам избежать огромного количества статических HTML страниц, что значительно уменьшает объем занимаемого сайтом места. Также существует множество других плюсов, но есть и свои минуса, одним из которых есть нагрузка на сервер. Есть множество способов ее уменьшения. Я расскажу о трех из них, которыми пользуюсь сам. Они показали неплохие результаты, поэтому есть смысл в их использовании.

Оптимизация блога WordPress при помощи кэширования страниц. Плагин Hyper Cache и его настройка.

Оптимизация WordPress при помощи данного метода состоит в том, что при обращении к страницам сайта, как обычно, генерируется статическая html страница. Разница лишь в том, что она сохраняется в КЭШе. При следующем обращении к этой странице вместо того, чтобы генерироваться заново, она просто берется из КЭШа. Это позволяет значительно уменьшить число запросов к базе данных и как следствие уменьшить нагрузку на сервер.

Итак, первым делом нам нужно скачать и установить плагин Hyper Cache. Для этого переходим на официальный сайт WordPress и скачиваем последнюю версию плагина. Далее копируем файлы в папку \wp-content\plugins\ и активируем плагин через административную панель. Для этого переходим в административную панель — плагины и активируем Hyper Cache.

После установки и активации плагина, переходим к его настройке. Точнее для начала нам нужно активировать кэширование в самом WordPress. Для этого нам придется редактировать файл wp-config.php и вставить в него строку

Define("WP_CACHE", true);

Лучше это делать ближе к концу файла, но не дальше строк

If (!defined("ABSPATH")) define("ABSPATH", dirname(__FILE__) . "/");

Затем нам необходимо соединиться с сервером и выставить права доступа 777 для папки wp-content. В принципе можете поставить эти права на саму папку с КЭШем. После этого переходим в административную панель\параметры\Hyper Cache и активируем его. Затем переходим к самим настройкам кэширования.

• Время жизни кэшированных страниц – устанавливаете время, которое будет существовать страница в КЭШе. То есть после обращения к статье WordPress кэширует эту страницу и сохраняет ее. От значения, которое вы здесь установите, будет зависеть время существования этой страницы, до ее удаления или обновления. Можете ставить по своему усмотрению. Обычно чем дольше, тем лучше.
• Автоочистка – данная функция проводит проверку КЭШа на наличие записей с истекшим сроком. Если такие находятся, то они удаляются. Благодаря этому вы можете быть спокойны, что у вас не будет накапливаться мусор, который может весить довольно много, что в свою очередь приведет к уменьшению свободного пространства на диске. Значение можете подбирать индивидуально. Вполне подойдет 1440 минут.
• Как очищать кэш – ставим значение «Single pages». На мой взгляд, это оптимальный вариант. В этом случае при внесении изменений кэш будет обновляться только для тех страниц, которые были редактированы. Остальные же останутся нетронутыми. При большой посещаемости это имеет смысл, так как если бы каждый раз, когда вы редактировали статью, очищался бы весь кэш, то это бы создало огромную нагрузку на сервер.
• Не кэшировать домашнюю страницу – можете поставить галочку, если не хотите, чтобы сохранялась главная страница. Данная опция имеет смысл, если у вас очень часто обновляется главная страница вашего блога. В принципе ставим по желанию. Лично у меня эта опция включена.
• Исключить URI – сюда можно вписать адреса страниц, которые вы хотите исключить с КЭШа.

Это были основные настройки плагина Hyper Cache. Для того, чтобы проверить его работоспособность, заходим на наш сайт как незарегистрированный пользователь и смотрим исходный код страницы. В конце должна присутствовать такая строка.

Если она есть, то плагин работает нормально.

Снижение нагрузки на сервер за счет кэширования запросов к базе данных.

Для этого можно использовать специальный плагин DB Cache Reloaded . Он кэширует запросы и направляет их не в базу данных, а в кэш, доступ к которому более быстрый. За счет этого уменьшается нагрузка на сервер и увеличивается скорость генерации страниц, что, в свою очередь, увеличивает скорость загрузки самого блога.

Настройки этого плагина очень просты и приводиться не будут. Там все интуитивно понятно. Единственное, что могу предложить, это добавить в footer.php код, который будет выводить информацию о количестве запросов к базе и время загрузки страницы.

Для этого открываем на редактирование файл footer.php и где-то в конце добавляем код

queries in seconds.

Приведенный выше вариант будет выводить информацию о количестве обращений к БД и времени загрузки страницы. Замечу, что информация будет видна только вам. То есть будет выводиться только тогда, когда вы авторизированны на сайте. Выглядеть это будет примерно так:

Естественно можно поиграть со стилями, перевести «queries in» и «seconds», но это по желанию. Лично меня и так все устраивает.

Оптимизация шаблона WordPress

Оптимизация шаблона или темы сводится до уменьшения количества обращений к базе данных. Так как шаблоны создаются универсальными, то разработчики стараются все автоматизировать. Все это делается для удобства пользователей. Но если вы уже разобрались с темой, которую будете использовать, то можно уже начинать ее оптимизировать. Весь смысл состоит в том, чтобы заменить стандартные PHP кода с обращениями к базе на статичные. Проделывать такое мы будем в двух файлах – шапке сайта и футере. Начнем с первого.

Оптимизация header.php

1. Находим код

и меняем его на название своего блога. У меня это

Сайт - создание и продвижение сайтов, блогов, заработок на сайте.

2. Код, отвечающий за вывод описания, заменяем на статический.

3. Строка, отвечающая за вывод кодировки.

; charset=" />

Поскольку мы знаем, что кодировка WordPress UTF8, то можем видоизменить данный код и сделать его таким:

4. Удаляем строку, которая отвечает за вывод информации о вашей версии WordPress.

" />

Это нужно сделать для улучшения безопасности блога, так как именно эта информация является опасной и может сообщить злоумышленникам то, что им знать не нужно. Тем более если вы используете более раннюю версию движка, то данное изменение вам необходимо.

5. Заменяем путь к таблице стилей вашего шаблона на статичный.

" type="text/css" media="screen" />

После модификации будет иметь примерно такой вид:

6. Меняем путь к RSS ленте на статический.

RSS Feed" href="" />

После изменения будет выглядеть вот так:

7. Также можно изменить путь до Pingback (рассылка, которая отправляет сведенья по всем адресам, упомянутым в этой заметке).

" />

Заменяем на

Оптимизация файла footer.php

В принципе здесь, по большому счету, можно оптимизировать только вывод копирайта. Для этого код

заменяем на свой текст. У меня это

• «Оптимизация WordPress за счет уменьшения количества обращений к данным »

На этом я заканчиваю данную статью. Если у вас остались какие-то вопросы, вы всегда сможете задать их в комментариях.

На этом все. Удачи вам и успехов в оптимизации сайтов.

В этой статье мы рассмотрим несколько распространенных вариантов, когда сайт под управлением WordPress становится источником высокой нагрузки на сервер. В таких случаях техподдержка хостинга обычно извещает пользователей с просьбой провести работы по оптимизации сайта. Как же бороться с этой нагрузкой и что ее вызывает?

Начну с того, что ситуации бывают весьма специфические, но мы рассмотрим наиболее распространенные. Не исключено, что среди этих рассмотренных ситуаций, окажется и Ваша и Вы с легкостью ликвидируете проблемы. Также мы обусловимся, что Вы умеете найти причину нагрузки в WordPress самостоятельно, изучив логи посещений своего сайта.

Проблема в wp-cron.php

wp-cron.php периодически запускает на сайте различные задачи: проверяет обновления WordPress и установленных плагинов, публикует запланированные посты, рассылает уведомления о новых комментариях и прочих событиях и т.д. Проблемы с wp-cron начинаются зачастую на виртуальных серверах, которые имеют ограничение на количество используемых системных ресурсов. В итоге создается экстремальная нагрузка на сервер.

Определив, что источником нагрузки является wp-cron.php, его можно отключить, добавив в файл wp-config.php строчку:

Define("DISABLE_WP_CRON", true);

Но без wp-cron сайт не будет полноценно функционировать. Тогда мы сами должны управлять его работой, это можно сделать через cPanel, создав cron-задачу (с необходимым интервалом на исполнение), например:

Wget http://ваш_сайт.ру/wp-cron.php?doing_wp_cron > /dev/null

Проблема в xmlrpc.php

В WordPress есть скрипт xmlrpc.php, он отвечает за вызов удаленных процедур и поддерживает известные API - WordPress API, Blogger API, MetaWeblog API и MovableType API. С помощью этого файла можно удаленно публиковать посты на своем сайте или полностью им управлять, не обязательно через административную панель. И как раз таки частые запросы к XMLRPC могут вызывать чудовищную нагрузку, что очень эксплуатируется на практике.

Если Вы вообще не используете в своей работе XMLRPC (а этого наверняка Вы не делаете), то можно просто удалить из корня своего сайта файл xmlrpc.php. А чтобы боты не грузили 404 страницу, в.htaccess добавляем редирект на microsoft.com (сервера у них хорошие):

Redirect /xmlrpc.php http://www.microsoft.com

Проблема в wp-login.php

wp-login отвечает за авторизацию на сайте WordPress. Слишком частое к нему обращение, например, в целью подобрать пароль администратора, что осуществляется программно, вызывает сильную нагрузку. Избежать нагрузок можно, заменив это стандартное имя. Сделать это можно множеством способов, вот пример с плагином и без плагина.

Защита wp-login.php без плагина

в.htaccess добавляем:

Order Deny,Allow Deny from all

Файл wp-login.php, переименовываем в секретное имя, например cudanelza.php и внутри файла меняем все надписи wp-login.php на cudanelza.php.

Теперь у нас wp-login.php стал cudanelza.php

Защита wp-login.php с помощью плагина Lockdown WP Admin

Плагины - Добавить новый - ищем "Lockdown WP Admin". Ставим, активируем, переходим в настройки. Напротив "Yes, please hide WP Admin from the user when they aren"t logged in" ставим галочку. В разделе WordPress Login URL прописываем новый адрес админки, например, "parapara". Сохраняем настройки. Теперь наша админка доступна по адресу http://сайт.ру/parapara

Проблема в sitemap

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

Вот как выглядят дефолтные (по умолчанию) настройки XML карты сайта в плагине All in One SEO. В XML карту попадают все типы записей, которые там вообще не нужны:

Дефолтные настройки XML карты сайта в плагине All in One SEO

Именно дефолтные настройки XML карты сайта были частой причиной нагрузки на сервер, вызываемой поисковыми ботами и пауками.

Данная проблема решается в несколько этапов:

1. Настройте sitemap.xml таким образом, чтобы сюда попадали исключительно ссылки на страницы/записи вашего сайта

2. В robots.txt пропишите директиву

Crawl-delay: 10

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

3. Блокируйте ненужных Вам роботов. В статье вы найдете действенные методы блокировки ненужных ботов и пауков

Это не все, но тем не менее, наиболее распространенные ситуации в моей практике, когда WordPress создавал нагрузку на сервер. Как мы видели выше, не сам WordPress может создавать нагрузку, но и недоброжелатели, пытающиеся взломать, либо просто "повесить" Ваш сайт. Данные рекомендации будут актуальны в любом случае, не важно, у вас виртуальный или выделенный сервер. Естественно, большие проекты на WordPress требуют серьезных мощностей, развернуть серьезный сайт, не вызывающий нагрузок на виртуальном сервере - проблематично. Тут проще купить сервер или арендовать. Но и там без оптимизации WordPress не обойтись, особенно, если речь идет о высокопосещаемом сайте.

P.S. В WordPress имеются недостатки, которые рано или поздно могут привести к нагрузке на вашем сервере. Этими недостатками могут воспользоваться недоброжелатели, что чревато выходом за предоставленные хостингом лимиты. Надо быть готовыми к их устранению. Наиболее частые проблемы мы только что рассмотрели. Также в связи с этим напрашивается закономерный вопрос: почему озвученным аспектам так мало уделяют внимания разработчики WordPress? Это не проблема последних версий, а наиболее уязвимые места, которые передаются по наследству, от версии к версии! Разумеется, с помощью плагинов и обширного кодекса, WordPress можно адаптировать под практически любые нужды вебмастера, но вебмастерами зачастую выступают новички, поэтому хотелось бы видеть механизмы защиты обозначенных в этой статье проблем в дефолтных сборках WP. Тогда и взломов сайтов было бы меньше и нагрузок на серверах поубавилось!

Вконтакте

Как уменьшить нагрузку сайта на вордпрессе на хостинг и оптимизировать базу данных?

Начал задаваться этим вопросом после того, как служба поддержки хостинга Таймвеб написала мне, что мои сайты (их на этом хостинге размещено 10 штук) оказывают чрезмерную нагрузку на центральные процессы хостинга и на базу данных. Повышенная нагрузка была связана частично с ddos-атакой на один мой сайт, ну и в дополнении с тем, что я размещаю сайты на этом хостинге давно уже (более 1,5 года), а никакие работы по очистке мусора с и по оптимизации баз данных не проводил. А ведь сайт можно в некоторой степени сравнить с компьютером. Если не очищать его от ненужных файлов, кряков и прочей лабуды, то компьютер будет со временем поедать и требовать больше ресурсов, что приведет к замедлениям в его работы, частому зависанию. Поэтому нужно заботливо относиться к своим сайтам и периодически проводить действия по оптимизации их работы.

Как снизить нагрузку вордпресса на хостинг и оптимизировать базу данных (MySQL)?

Я провел небольшие действия (о которых расскажу далее), которые позволили мне в результате существенно уменьшить нагрузку на CPU хостинга. Если говорить обобщенно, то удалось снизить нагрузку на CPU с 30-40 до 0,34 – 0,50, а нагрузка на базу данных уменьшить с 90 до 64-70.

В результате проведенных действий по оптимизации базы данных (MySQL) – ее размер удалось уменьшить с 227 мб до 41 мб. Как видим – удалось добиться существенных показателей. А что для этого было сделано?

Оказывает, что любые действия, проводимые в вордпрессе (будь то публикация новой статьи, будь то просто добавление нового плагина и прочее), оказывают какое-то воздействие на базу данных, увеличивая ее в размерах. А чем больше ее размеры, больше различных файлов в ней, находящихся в беспорядочном порядке – тем больше идет нагрузка на процессы хостинга. Поэтому проведя работу по оптимизации базы данных можно существенно сократить эти нагрузки.

Для оптимизации базы данных понадобиться установить и активировать плагин — Optimize DB (о том, как устанавливать плагины читать ). Далее идете в раздел «Инструменты» — находите строчку «Optimize DB» и переходите по ней. Теперь для оптимизации базы данных на вашем сайте остается только нажать на кнопку «Optimize Now».

Вот такие простые действия оптимизируют вашу базу данных на вордпрессе (так сказать упорядочивают в ней хаос и раскладывают все по полочкам).Чтобы работа этого плагина в дальнейшем не создавала дополнительную нагрузку – нужно его просто выключить. Для оптимизации базы данных на вордпрессе раз в неделю или раз в месяц заходите в раздел с плагинами, активизируйте плагин Optimize DB и проводите оптимизацию MySQL (это и есть база данных). А после снова отключайте его.

Но я не ограничился для снижения нагрузки на хостинг только работой с плагином Optimize DB. Была проведена существенная работа по борьбе со спамом. Особенно много спама накопилось на нескольких сайтах (в сумме свыше 6 тыс. штук). Говоря про спам – я имею в виду комментарии спамного характера, большое количество которых также нагружает хостинг. Удалил много комментариев ожидающих проверки (точнее, чтобы полностью их удалить – отправлял их первоначально в корзину, а потом корзину очищал), также очищал папку со спамом. В в последнее время мне существенно помогает плагин «Invisible Captcha». Благодаря нему спам мгновенно отправляется в папку со спамом, а оттуда все спамные комментарии можно мгновенно удалить, очистив эту папку.

Посоветовал бы установить еще плагин «WP Super Cache» (если он не установлен), активировать, и включить кэширование. Особенно полезен он будет, если на ваши сайты уже стало заходить много посетителей. В процессе работы я установил его еще на парочку сайтов. Благодаря кэшированию нагрузка на хостинг также уменьшается.

Вот такая была проведена работа над 10 сайтами, которая заняла у меня около 2 часов. Но своего я добился – удалось существенно снизить нагрузку вордпресс на хостинг.

Также стоит отметить, что чем больше на сайте на вордпрессе активировано разных – тем больше нагрузка. Поэтому используйте только те плагины, которые вам необходимы и выключайте те, которые не используете.

Для WordPress, то практически каждый день получаю письма с просьбой умерить аппетиты этого монстра. Как правило блогеры не задумываются об этой проблеме в начале создания сайта, и остро она стоит уже когда хостер присылает уведомления с угрозой отключить сайт.

Как правило, первое, что делает блогер - это устанавливает кэширующие плагины. Нагрузка, если и уменьшается, то незначительно. Далее, начитавшись «якобы гуру», начинают самостоятельно «оптимизировать» шаблон или даже сам WordPress. Тут можно только посочувствовать, особенно умиляют советы о включении например gzip-сжатия в самом шаблоне. Стоит ли говорить, что подобные действия в самом лучшем случае не приводят к результату вовсе, либо, наоборот нагрузка на сервер ещё больше увеличиватся.

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

MaxCache и другие кэши

Самый простой и радикальный способ снизить нагрузку WordPress - это установить мой MaxCache. Мой кэш принципиально отличается от любых других кэширующих плагинов, потому что он не плагин и работает вне WordPress. Если другие плагины загружаются в рамках WordPress, то мой - работает вне, тем самым и достигаются столь высокие характеристики.

Поэтому первая причина, по которой существующие плагины-кэши работают неэффективно - это то, что они сами по себе ресурсоёмкие и для своей работы требуют наличия WordPress. То есть вместо снижения нагрузки, получается с точностью наоборот - нагрузка увеличивается.

«Кэширование» в.htaccess

Некоторые плагины для «ускорения» WordPress меняют файл .htaccess , прописывая в нем инструкции для принудительного кэширования файлов для браузеров на длительное время. Технически браузер не загружает файл с сервера сразу, а вначале проверяет его наличие в своём кэше (на компьютере). Для этого он посылает короткий запрос серверу и сервер может возвратить ответ «Файл не изменился». То есть браузер уже не тянет его с сервера, а берёт из своего кэша. Понятно, что скорость загрузки страницы в этом случае возрастает многократно.

Указание «принудительного кэширования» в .htaccess практически не имеет смысла поскольку не зависимо от этих инструкций, первоначально все файлы должны быть загружены пользователем. Поскольку повторных посетителей (раз-два в неделю) гораздо меньше новых, то эффективность такого кэширования небольшая. Кроме того, следует учитывать тот факт, что браузеры достаточно умны и самостоятельно определят нужно ли загружать старые файлы.

Таким образом «кеширование» в .htaccess можно использовать, но это только лишь может сказаться на трафике для повторных посетителей.

Сжатие с помощью gzip

Другой частой ошибкой является включение gzip-сжатия. Само по себе сжатие позволяет сократить трафик примерно на 30%, но только для текстовых файлов. Как правило файлы изображений плохо сжимаются и выигрыш будет очень маленький.

Проблема здесь в том, что сжатие требует дополнительных ресурсов сервера, что приводит к ещё большей нагрузке. То есть включать сжатие имеет смысл только выборочно и только при наличии свободных ресурсов сервера .

Само сжатие должно быть включено на уровне сервера. Обычно эту инструкци прописывают в .htaccess .

Не путаем трафик и нагрузку на сервер!

Неопытные блогеры иногда мне присылают скриншоты разных онлайн-сервисов о том, что мой кэш якобы не уменьшает «нагрузку». Приходится объяснять, что загрузка сайта пользователем и нагрузка на сервере - совершенно разные вещи.

Нагрузка на сервере характеризуется несколькими основными показателями. В первую очередь - это загрузка процессора (CPU). Обычно измеряется от 0 до 100% (или от 0 до 1). 100% - это значит, что процессор полностью загружен в заданный промежуток времени, например за 1 минуту.

Хостеры как правило учитывают этот показатель и закладывают лимиты в тарифные планы. Например для дешёвых тарифов CPU может ограничиваться 2-3%, а дорогих 10%. При этом предполагается учёт пиков: например в течение 30 секунд сайт может потреблять 70% CPU.

Виртуальный хостинг - это одна большая комунальная квартира. Ресурсы у неё ограничены, а жильцов много. Поэтому, когда один жилец (сайт) засел в туалете на полчаса, другие вынуждены его ждать. Вот поэтому хостеры и лимитируют использование туалета ресурсов.

Проверить использование CPU на сервере можно только, если хостер предоставляет такую возможность. На странице кэша в отзывах есть примеры скриншотов. Возможно ваш хостер предлагает похожую статистику.

Нагрузка в виде «процессорного времени»

Когда-то давно хостеры использовали только ограничение на трафик. То есть нужно было платить только за объем скачанной информации. После, сделали трафик безлимитным (точнее очень большим), но ввели ограничение на использование CPU. То есть те же самые сайты, которые раньше спокойно работали на сервере, вдруг стали не укладываться в отведенные лимиты CPU.

Сейчас хостеры придумали очередную «забаву» в виде «процессорного времени». Если раньше был лимит на CPU, который просто не стоит превышать, то процессорные минуты «капают» всегда. Например хостер выделил на аккаунт 100 минут в сутки. Не засисимо от того, превысили ли вы лимиты процессора или нет, берется его загрузка и вся суммируется. То есть даже если за вами очереди в туалет нет, хостер учтёт всё время посещения.

Плохая новость для WordPress-блогеров в том, что, как правило выделенных процессорных минут (обычно 100 минут) хватит примерно для 2 тысяч хостов в сутки. Если посещаемость превышает 2000 посетителей, то для сайта на WordPress превышение процессорного времени будет 10-100% (110-200). То есть хостер вышлет уведомление с просьбой уменьшить нагрузку либо перейти на более высокий тариф.

Потребляемая php-память и MySQL

Давно известно, что WordPress-разработчики давно «забили» на оптимизацию своего «движка». Вместо этого тупо увеличили минимальные требования к серверу. Именно поэтому WordPress требует для работы как минимум 32Мб памяти, а для админки 256МБ.

На серверах как правило нет большой проблемы с выделением памяти, поэтому сам по себе этот показатель лишь косвенно показывает качество используемого кода.

Если потребление памяти большое, то это говорит о том, что были загружены множество файлов, было получено много данных, и, скорее всего, нет оптимизации алгоритмов выполнения скриптов/функций: там где можно было ограничиться небольшой выборкой, используются большие массивы данных и ресурсоемкие функции.

Что касается MySQL - запросов к базе данных, то тут более сложная ситуация. Запросы бывают разные. Существую короткие, но затратные по ресурсам sql-запросы, а бывают длинные, но быстрые. То есть в целом, если хостер жалуется на превышение лимитов MySQL, следует провести анализ запросов и выявить медленные. Это задачка для опытного вебмастера, а для рядового блогера решается путем отключения плагинов и/или смены шаблона. Но, в любом случае, использование базы данных достаточно затратно для сервера, поэтому всегда следует стремиться к уменьшению количества запросов MySQL.

Чтобы получить статистику своего сайта добавьте в подвал (как правило файл footer.php ) сайта следующий код:

WordPress: " . round(memory_get_usage()/1024/1024, 2) . "MB " ." | MySQL:" . get_num_queries() . " | "; timer_stop(1); echo "sec