FLEXible блог

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

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

А вот так (под катом) выглядит Perfect Registry 2.0:

Продолжить чтение "Оптимизаторы реестра: Perfect Registry, go-go-go"

Производительность Grails

Рано или поздно, любой программист слышит, что производительность инструмента, который он использует или инструмента, который он сделал — невысока. Будь то какой-нибудь синтетический бенчмарк, или сложные распределённые вычисления. Будь то работа с базой данных или с файлами.

Все хотят максимальной производительности! Всегда! Немедленно!

Как известно, часто максимальная производительность достигается путём жертв. Пожертвовать удобством, настраиваемостью, масштабируемостью, поддерживаемостью — то и другое, и третье и четвёртое — можно принести на алтарь производительности.

Но насколько серьёзны потери? Насколько их можно избежать? Как можно выжать из проекта побольше производительности? Давайте посмотрим на примере Grails.

Продолжить чтение "Оптимизируем производительность фреймворка Grails"

Иной раз казалось бы, вполне себе невинный и очень даже простой метод count() может стать серьёзной проблемой для производительности.

Предположим, что у нас есть два доменных класса: Игрок и Предмет. Имеем реляцию: Игрок hasMany Предмет. Классы будут называться: Player, Item. Поле с коллекцией предметов — items. Коллекция предметов нужна нечасто, поэтому для её подгрузки используется lazy-loading.

В случае, если нам необходимо просто подсчитать количество предметов, мы могли бы использовать такой код:

player.items.count()

Но гораздо быстрее будет работать код

Item.countByPlayer(player)

Попробуем разобраться, что же происходит?

Продолжить чтение "Grails и коварный метод count()"

В одном из комментариев у меня спросили, почему не использовать обычный gzip вместо gzip_static. Давайте попробую объяснить, за что я люблю именно gzip_static, и почему его использование - это очень хорошо.
По сути, у серверов есть четыре основных ресурса: память, процессор, жесткий диск и полоса пропускания канала.

Для тестирования возьмем синтетический достаточно большой файл в 301.26 КБайт. Сделаем мы его, объединив все файлы из каталога JQuery в WordPress. Экономией памяти при отдаче небольшого файла можно пренебречь: память все равно будет мгновенно освобождена. Лишним потреблением места на диске – думаю, тоже. Лог-файлы куда больше места занимают :). А вот на расходование ресурсов процесора и экономию канала – посмотрим ниже.

Продолжить чтение "Почему gzip_static лучше gzip?"

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

Наткнулся на рекламу софтинки Paragon Alignment Tool, пошарил по интернету и выяснил, что до конца июля ключики для нее раздают бесплатно.

Продолжить чтение "Ускорение винчестера, продление срока службы SSD"

В этих Интернетах почему-то бытует мнение, что включение gzip означает большую нагрузку на процессор, как явление, сопутствующее пониженному потреблению интернет-трафика. Скажу честно, это утверждение не является справедливым. Даже для apache, хотя в nginx это делается куда проще. Есть рекомендации снижать степень сжатия, чтобы разгрузить ваш процессор. Бред!

Давайте сделаем самый эффективный gzip.

Продолжить чтение "Пожалейте ваш процессор! Быстрый gzip для nginx и apache"

Прочитав у slaFFik'а статью про потребление памяти WordPress MU 2.8.2 и BuddyPress, заинтересовался, насколько эффективно у нас на Берсерках.Ру экономит расход памяти акселератор. В то время использовался eAccelerator, кэш опкода составлял 64 Мб. После экспериментов выяснилось, что увеличение кэша опкодов до 128 Мбайт действительно привело к радикальному снижению расходования памяти, с 35-36 Мбайт до 18 на процесс.
Поскольку количество одновременных доступов к сервису может превышать 4, - мы решили увеличить кэш опкода, чем вызвали существенное снижение потребления памяти.
Однако, не прошло и суток, как стала наблюдаться крайне неприятная ситуация - при простых операциях с сервером, иногда результатом действия была белая страница, а в логе ошибок сервера появлялось сообщение о том, что процесс apache был убит в результате ошибки.
Было принято решение сменить акселератор - я попробовал xcache и APC (из PECL). И вот что получилось: Продолжить чтение "PHP-акселераторы при работе с WordPress MU и BuddyPress"

Введение

Когда-то тому назад, я писал про невозможность задания query plan в MySQL. Посыпаю главу пеплом, был неправ. В ряде случаев, ограниченные функции планирования запроса, могут позволить значительно ускорить его выполнение.

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

Продолжить чтение "Производительность mysql, задание query plan"