Оптимизация байт-кода в PHP

Я давно задавался вопросом, насколько «умным» является интерпретатор в том, что касается оптимизации. В частности, меня всегда интересовала поддержка исключения неиспользуемого кода (известная как dead code elimination) и распространение константных значений (constant propagation). И теперь, когда я вплотную занялся изучением внутренностей , у меня такая возможность появилась. Далее »

Автор: , опубликовано в: PHP, комментариев: 2
15
Сен
2009

WP Super Cache и высокая нагрузка: часть 2

Вчера я наконец-то поднял munin и новый monit на сервере, а сегодня посмотрел на результаты мониторинга. Самое первое, что бросилось в глаза: iostat показывает очень большое количество записей (превышавшее количество чтений почти в тысячу раз).

На сервере живут четыре сайта на , два из которых (littlefox.ru и cat-tv.ru) находятся в Alexa Top 100,000 (они создают основную нагрузку на сервер).

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

С целью поэкспериментировать мы отключили WP Super Cache. В результате получилась такая картина. Далее »

Автор: , опубликовано в: WordPress, комментариев: 17
29
Июл
2009

Ужасы таксономии в WordPress

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

Я взял свежую дефолтную инсталляцию  2.8-bleeding, сгенерировал тестовый контент и пошел искать недоработки и проблемы с производительностью. Одну из них я нашел очень быстро: при попытке удалить категорию, в которой была 1,001 ночь запись.

На неслабом сервере это заняло около 20 секунд и… более 12,000 запросов (да-да, двенадцати тысяч, я количеством ноликов, увы, не ошибся). Далее »

Автор: , опубликовано в: WordPress, комментариев: 16
9
Июн
2009

Увеличение производительности плагина NextGen Gallery

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

Автор: , опубликовано в: WordPress, комментариев: 2
6
Июн
2009

OpenMP на многоядерном процессоре и криптография

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

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

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

Я решил проверить, каким будет прирост производительности параллельного шифрования в режиме ECB у алгоритма шифрования ГОСТ 28147—89 на четырёхядерном процессоре. Далее »

Автор: , опубликовано в: OpenMP, комментариев: 13
4
Апр
2009

Практическая польза fast-типов

В данной статье речь пойдёт о типах int_fastXX_t/uint_fastXX_t из stdint.h.

Мне было интересно потестировать параллельную реализацию шифрования алгоритмом ГОСТ 28147–89 на многоядерных процессорах (с использованием , но это тема для отдельной статьи).

Как известно, ГОСТ 28147–89 — блочный , оперирующий 64-битными (uint64_t) блоками. При выполнении зашифрования в режиме простой замены открытый текст разбивается на две половины (uint32_t). В принципе, это всё, что пока нужно знать :-)

Те, кто знакомы с особенностями архитектур 32- и 64-битных процессоров, знают, что 32-битные процессоры быстрее обрабатывают 32-битные числа, а 64-битные — соответственно, 64-битные.

В стандарте C99 языка C в файле <stdint .h></stdint> определены так называемые "быстрые типы": int_fast8_t, int_fast16_t, int_fast32_t, int_fast64_t, uint_fast8_t, uint_fast16_t, uint_fast32_t и uint_fast64_t. Далее »

Автор: , опубликовано в: C/C++, комментариев: 4
20
Мар
2009

WP File Cache 1.0

Появилась новая версия плагина WP File Cache.

В данной версии у плагина появился интерфейс для администратора и, как следствие, возможность «тонкой настройки».

Функциональность плагина:

  • реализация долговременного кэширования на уровне запросов;
  • полная совместимость с интерфейсом класса WP_Object_Cache ;
  • использование памяти под сессионный для увеличения производительности;
  • сессионное кэширование часто изменяющихся объектов;
  • хранение настроек в коде плагина.

Особенности плагина:

  • возможность отключения кэширования (в том числе и встроенного в WordPress);
  • возможность отключения межсессионного кэширования;
  • возможность задания групп, не подлежащих межсессионному кэшированию (полезно только разработчикам, которые знают, о чём идёт речь);
  • хранит свои настройки непосредственно в коде (в файле wp-content/object-cache.). Это связано с проблемой курицы и яйца, а также с архитектурными особенностями WordPress.

Плагин существует в двух локализациях: русской и английской. Если у Вас есть желание перевести плагин на другой язык, пишите.

Замечания по установке: после активации плагин для хранения кэша будет использовать каталог wp-content/plugins/file-cache/cache. Поэтому перед активацией каталог должен быть доступен на запись. Каталог для хранения кэша можно изменить в настройках (для увеличения производительности имеет смысл размещать кэш на RAM-диске); каталог также должен быть доступен на запись. Плагину при активации/сохранении настроек должен быть доступен на запись каталог wp-content: в него копируется файл object-cache.php. После того, как плагин активирован и сконфигурирован, права на запись можно убрать.

По производительности плагин бьет как «голый» WordPress 2.7rc1, так и WordPress, «нагруженный» плагинами. Причем выигрыш в производительности становится всё более заметным при увеличении нагрузки на сайт (когда обмен данными с становится всё более интенсивным).

Плагин скоро появится на wordpress.org (да, у меня наконец-то дошли руки), и его можно будет скачивать прямо оттуда :-) Как следствие, у плагина появилась домашняя страница.

Скачать последнюю версию плагина WP File Cache.

Большое спасибо Максиму Покровскому за тестирование плагина под Windows.

Свежая версия плагина, а также вопросы/комментарии находятся на странице WP File Cache: долговременное кэширование в WordPress.

Автор: , опубликовано в: Плагины WordPress, комментариев: 24
2
Дек
2008

WordPress под микроскопом

Навеяло комментариями к статье «Трудности веб-разработки» и недавним копанием во внутренностях …

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

Если хочется кучу всякой гадости, вроде плагинов, редактирования страниц, темплейтов, интегрирования чего попало куда попало — естественно, за это приходится платить. Платить очень дорого.

А какое можно сделать «элегантное решение»? Чтобы оно обладало тем же функционалом? Можно только повторить монстра.

Доля истины в этом высказывании, разумеется, есть: чем универсальнее решение, тем оно монстроидальнее. Задача состоит в том, как этого монстра оптимизировать и минимизировать. Есть программисты, а есть быдлокодеры (у меня сегодня два цвета: чёрный и белый). Разница между первыми и вторыми заключается только лишь в умении использовать ресурсы серого вещества, именуемого мозгом. В результате у первых получается элегантное решение, а у вторых — Некрософт Виндовс Нерабочий Труп.

Это я всё к чему? Берём WordPress и смотрим:

MySQL: 45 запросов / 0.550 Потребление памяти: 10.1MB…

У меня немного другая статистика (наверное, сервер мощнее): 50 запросов, 0.05 сек.

Пятьдесят плюс-минус пять запросов: много ли это? Фиг его знает, может и не много, ибо всё познаётся в сравнении. Ну так давайте сравним. Я «надругался» над несчастным WordPress и просто отрубил ему . Готовы?

1462 запроса и 2.02 секунды (лог запросов превышает мегабайт). Те, кто знаком с оптимизацией запросов в , ужасайтесь вместе со мной.

Можно долго спорить о том, что кэш нельзя выключать, разработчики его не зря включили и всё в том же духе. Ответ: а почему нельзя было сразу спроектировать нормально, чтобы не требовались костыли в виде кэша? По-хорошему, кэш должен использоваться как средство, дающее дополнительное ускорение приложению, но не как средство, обеспечивающее нормальную жизнедеятельность приложения. Скажем так: стимуляторы при умеренном применении могут оказать положительный эффект на человека. Но когда стимуляторы используются только для поддержания жизнедеятельности человека — это уже другая песня.

Вот так.

Но, возможно, в следующей версии…

Автор: , опубликовано в: WordPress, комментариев: 20
27
Ноя
2008

Можно ли написать серьёзное web-приложение с использованием MySQL, но без знания принципов работы MySQL?

Хотя я люблю , но то, что я увидел сегодня в коде, меня сильно потрясло.

Речь пойдёт о виджетах, а именно, о календаре и архиве. Я вкратце опишу реализацию каждого из них, а затем расскажу, почему так делать нельзя. Далее »

Автор: , опубликовано в: MySQL, Патчи, комментариев: 32
24
Ноя
2008

Секреты update_postmeta_cache()

Если плагину приходится в цикле читать метаданные для большого количества записей, можно увеличить путём использования функции update_postmeta_cache(). Далее »

Автор: , опубликовано в: Советы, комментариев: 6
1
Окт
2008
«
»