У ядра WP без плагинов я вижу 10-11 запросов. Версия WP 2.7, кастомизированная собственноручно, на более новых версиях запросов может быть больше.
В идеале чем меньше тем лучше. Пока минимум что я выжимал это 7.6 МБ без акселератора, но там серьезно "пострадали" исходники, т.к. я кастомизировал одну из версий WP и теперь работаю только с ней.
На мой взгляд, проще всего поставить акселератор на сервер, т.к. это избавляет от нужны ковыряться в коде WP. По опыту могу сказать что расход памяти у меня до его использования на WP был около 10МБ на 1 страницу, теперь не более 2-3 МБ.
Как правило, WP тормозит из за большой избыточности в переменных. Так сказать обратная сторона удобства. Чтобы примерно представлять сколько "всего интересного" WP держит в себе, распечатайте глобальные переменные в ознакомительных целях:
<? print_r ($GLOBALS); ?>
Сам по себе WP без плагинов не создает много запросов - не больше десятка. В WP есть функция, выводящая число запросов к базе, вставьте в footer.php Вашей темы для контроля:
<?php echo 'MySQL: '. get_num_queries(); ?>
Последние версии WP с плагинами у меня завешивали на 30МБ оперативы при загрузке 1 страницы.
Чтобы посмотреть что грузит систему, лично я использую вот что:
<? echo 'RAM: '.round(memory_get_usage()/1024/1024, 3).'MB'; ?>
Функция выводит текущее потребление памяти. Пробуйте отключать плагины и следить за цифрами.
А вообще, если есть возможность, попробуйте поставьте себе на VPS E-accelerator. Вещь хорошая, ставится не сложно, обеспечивает кеширование на уровне сервака, может снизить потребление RAM в 20 раз.
ТС, а Вы wp-config.php случайно в Блокноте не правили? У меня такое вылазило аккурат после правки конфига Блокнотом.
ТС, а Вам не кажется, что все дело в некорректности запроса?
Вы попробуйте в PHPMyAdmin выбрать:
и посмотрите на результат.
У меня при похожем запросе выбралась только 1 строка со значением выбираемого поля (в Вашем случае search) и числом полей. Если убрать COUNT, то запрос проходит нормально.
Видимо MySQL функция COUNT корректно работает только при выборке 1 строки, если же, априоре, число строк может быть больше, чем 1, такой запрос не совсем корректен.
В 10-й опере на Странице 2, а в ИЕ косяк в меню сверху виден на всех страницах, кроме "Взрывные клапаны".
ТС, Вы бы код меню сравнили на разных страницах... Начало кода - 42 строка.
Это отображается красиво в ИЕ, Файрфоксе и Опере:
А вот это нет:
ТС - а Вы верстаете руками или программой? Если программой, то советую попробовать сверстать пару страниц вручную, так проще находить ошибки. Если руками - тогда непонятно, почему Вы не обнаружили это сами.
И еще. У Вас часть кода, которая по идее должна быть одинаковой на всех страницах, отличается. Может стоит выделить шапку и подвал, вынести в отдельный файл и через php подключать ко всем файлам?
admak - мой вариант это общий случай. Принудительное завершение цикла - это уже уточнение условия задачи ;)
Ваш вариант считаю замечательным, поскольку занимает всего 2 строки, но сам привык работать с массивами, поэтому такая реализация и пришла первой в голову.
Orangesoda - предложите Ваш вариант :)
Моя логика: как правило в $_SERVER['HTTP_USER_AGENT'] содержится текст вида:
Проверка производится по совпадению с названием броузера (в данном случае Opera). Совпадение может быть лишь с одним из браузеров в списке, либо ни с каким из браузеров, поэтому цикл в данном случае наиболее удобен, нежели многократные конструкции if (...).
Я так понял идея такая: если в $_SERVER['HTTP_USER_AGENT'] есть название какого-то броузера, то должен выводиться или инклюдится текст.
Самое простое что приходит на ум это сделать массив где ключ - название броузера, а значение - либо переменная, либо файл который надо инклюдить.
Пример:
Дальше проверяем через цикл какой броузер у пользователя и в зависимости от этого инклюдим то что нужно:
Функция substr_count вычисляет количество появлений подстроки, т.е. число появлений значения $key в $_SERVER['HTTP_USER_AGENT']. Если совпадения есть, значит инклюдим нужный файл или просто через echo выводим переменную.
Основное неудобство сайта на html заключается в том, чо при мало-мальском изменении в навигации, добавлении новых важных страниц или, скажем, смене контактов, висящих в футере каждой страницы придется перелопатить все 400 страниц. CMS или просто шаблонная система на рнр позволит это сделать путем редактирования 1 файла.
Перенести с html на cms можно очень легко, сохранив структуру урлов. Я в свое время именно по этой причине и начал изучать рнр.
Неужели сам Садовский темы палит )))
