Человек-Хэмингуэй Голосов: 2 Адрес блога: http://kvisaz.ru Добавлен: 2007-12-13 21:24:07 блограйдером Luber

Самый быстрый в мире WordPress на shared хостинге

2012-06-29 18:25:05 (читать в оригинале)

Время работы скрипта 0.018 секунд
Памяти использовано 69.5 килобайт

Это - не самописный скрипт “Hello, World!”. Это современный Wordpress. На шаред хостинге за 10 баксов в месяц. Именно за столько секунд он выводит страницу, именно столько килобайт использует.

Ни одному плагину такое не снилось. Total Cache, Max Site Cache - сосать им, не пересосать. А всё почему? Об этом я уже писал в “13 мегабайт памяти WordPress жрет только при запуске wp-config.php”.

Любой плагин, как бы он там не выеживался и не старался, запускается ПОСЛЕ подключения базовых файлов WordPress, то есть после wp-config.php. Так что максимальный потолок экономии и скорости для всяких Total Cache и Max Site Cache - это те самые 13 мегабайт памяти и десятые доли секунды.

А тут - 18 тысячных секунды и 70 килобайт на вывод страницы. Правда, клево? А секрет очень прост - самое быстрое кэширование, которое превращает даже дряхлый зомби-сайт, ползущий по газону, в бодренького Супермена, рассекающего галактику на световой скорости.

Метод этот очень прост. Банален, я бы сказал. Кэширование надо ставить ДО каких-либо инклюдов. И для этого придется самому переписать index.php у WordPressa.

Как это делается - хорошо рассказано здесь.

Алгоритм нового index.php такой:
1. генерируем имя файла в кэше на основе урла
2. смотрим, есть ли этот файл в кэше
3. если есть - тупо его открываем и показываем (1 функция readfile)
4. если файла в кэше нет или если время кэширования истекло - запускаем буферизацию вывода через ob_start, затем подключаем исходные функции обычного index.php, а затем вывод сгенерированной в буфере страницы и её запись в кэш.

Конкретно по ссылке, которую я дал, есть несколько косяков. К примеру, я столкнулся с тем, что fwrite не генерит файл, если в его имени слэши. Пришлось дописать функцию, генерирующую папки в кэше по урлу.

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

Чтобы сделать сверхскоростной WordPress, я выполнил 2 шага:
1. создал в корневой директории сайта папку cache с нужными правами (777)
2. заменил обычный index.php Wordpress на то, что в архиве.

И все полетело!

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

Минусы самого быстрого WordPress в мире пока таковы:
1. динамические виджеты, комменты и т.д. на кэшированной странице не обновляются. Это можно в будущем вылечить переписыванием всех необходимых динамических элементов на JS и AJAX.

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

По сути, это даже не кэширование, а просто генерация статических HTML-страничек из WordPress. Быстро, дешево, сердито. На максимальной скорости, которая не снилась никаким плагинам.

Кто читает Смирнова также долго, как я, наверняка уже вспомнил статью Простое кэширование страниц. Патриарх давно уже обо всем написал, да :)

Самые простые вещи - самые быстрые.

---

Магия ?p

2012-06-29 09:09:58 (читать в оригинале)

Размышлял о том, как оптимизировать алгоритмы выборки поста по URL в альтернативном WordPress.

Подумал, что если в URL стоит переменная p (пример: http://kvisaz.ru/?p=4665) то можно игнорировать дальнейшие разбирательства и сразу использовать эту переменную (это iD поста в таблице).

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

Пример: http://kvisaz.ru/20120627/4668/ - вот обычный урл, выводит обычный пост 4668 с комиксом.

А вот с дописанным p - http://kvisaz.ru/20120627/4668/?p=4665 - выводит совсем другой пост.

Это я к чему пишу? К тому, что это оказалось дефолтным алгоритмом обработки URL в самом WordPress!!!!!!!

---

Новость

2012-06-27 19:50:04 (читать в оригинале)

Ссылка на новость: http://lenta.ru/news/2012/06/27/marathon/

Ссылка про фильм: Области Тьмы

---

13 мегабайт памяти WordPress жрет только при запуска wp-config.php

2012-06-27 17:58:04 (читать в оригинале)

Я тут снова начал копаться в WordPress (да, я не оставил мысли сделать публичный хак-фронт-енд для WP) и обнаружил, что 13 мегабайт памяти WP жрет только при запуске wp-config.php

На минуту, я просто подключил инклюдом этот сраный wp-config.php к своему скриптику из пары строчек. Получилось на домашнем Денвере:

Время выполнения 0.135069847107 секунд
Памяти использовано 13005.40625 Кб

Увидев такие цифры, сильно удивился. Но тот же понял, что проблема - в wp-config.php, который инклюдит по цепочке тонны других файлов.

Как раз недавно читал про оптимизацию WP силами программистов, там эксперт на полном серьезе как раз говорил, что сильно помогает выпиливание лишних инклюдов (и, привет Смирнову, замена функций, использующих регулярные выражения, на аналоги со строковыми функциями). Ключевые слова: Расмус Лердорф. Презентацию Расмуса можно почитать тут, прямо с графика инклюдинга для WP - http://talks.php.net/show/cp10/6
. Там просто картина Репина.

В общем, я удивился тогда и даже не поверил, что борьба с инклюдом решает. Приемы Расмуса показались не очень серьезными. А тут наглядно - подключил один wp-config.php и готово: время исполнения 100 миллисекунд, памяти 13 мегабайт.

Я написал альтернативную функцию инклюдинга, через вырезку нужных строк и eval. Имеет смысл только для загрузки куска с переменными из wp-config.php, конечно.

Итог такой:

Время выполнения 0.00185680389404 секунд - быстрее в 600 раз
Памяти использовано 346.09375 Кб - меньше в 50 раз.

Собственно, ради таких выигрышей и хочу сделать хаковый фронт-енд для WP для одного сайта. Я не хочу конвертировать БД или переходить на какой-то другой движок. Админка сохранится, авторы на сайте - вообще ничего не заметят. Хаковый фронт-енд будет тупо быстро хватать посты, формировать ленты и выводить их все по старым урлам. Тему, конечно, придется самому допилить, но это не сложно.

Пик релейтед:

---

Мгновенный список нужных файлов

2012-06-26 18:57:34 (читать в оригинале)

Банальная вещь, но часто выручала - и когда я работал с мобильными играми, и с мобильной графикой. Набираешь в командной строке Windows

dir *.swf /B list.txt

И появляется волшебный файлик list.txt, в котором перечислены все файлы с расширением SWF из текущей папки. Причем в столбик и без мусора (мне как раз так и надо).

Если нужно другое расширение - соответственно, меняем *.swf на *.расширение-которое-необходимо.

Работать в Far, Total Commander, голой командной строке Windows.