Во время перекомпиляции или рестарта ASP.NET-приложения я регулярно наблюдал картину, когда процесс firefox использовал процессор не меньше, а то и больше, чем aspnet_wp. С какой, спрашивается, радости он это делает, если он просто ждет ответа от сервера? На что тратится ресурс процессора?

Ответ на этот вопрос был заметен, оказывается, невооруженным взглядом, но он настолько дурацкий, что подумать его было сложно. Процессор кушает… анимация (APNG) крутящегося индикатора загрузки! Достаточно заменить его статическим png (или анимированным gif), чтобы проблема ушла.

Злополучный файл называется loading_16.png. Я нашел его здесь: Mozilla Firefox\chrome\classic.jar\skin\classic\global\icons\, — и заменил на статическую картинку. Также он лежит в skin\classic\aero\global\icons\loading_16.png, но это, видимо, для Висты, а у меня XP. Там я его оставил.

Ура, теперь не надо обдумывать переход на другой браузер! :) Надеюсь, в 3.5 это все-таки исправят, как-то неохота повторять операцию после апдейта.

Другой вариант решения — скопировать вот это в userChrome.css (не пробовал, это информация с баг-трекера Мозиллы).

Ссылки с подробностями:
https://bugzilla.mozilla.org/show_bug.cgi?id=437829
forum.mozilla-russia.org/viewtopic.php?pid=315838#p315838

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

Удивительно, что так мало внимания уделяется другим, более соответствующим аспектам производительности современных страниц, либо вообще не уделяется. Например, как быстро работают браузеры с динамично меняющимся стилем страницы (CSS)?

На Velocity 2009 Линдси Симон из компании Google говорил именно об этом. И на слайдах из презентации есть пара итересных графиков.

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

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

Кроме того Опера очищает кэш от неиспользуемых элементов каждые 10 минут, но не видно что бы это было отражено в отчёте испытания. Мы могли бы очищать кеш все время, но тогда нам пришлось бы пожертвовать производительностью, как по всей видимости, делает Firefox.

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

Основные изменения по сравнению с 0.4.x: (http://code.google.com/p/quicky/)
[~] {math} теперь компилируется в нативный PHP-код.
[~] Отображаются номера строк при ошибках компиляции, ошибки компиляции выдаются сразу все, а не по одной, показывается тег, в котором ошибка.
[+] Добавлена функция {debug} отображающая debug-консоль (о том почему у Quicky наиболее совершенный дебагер читайте под катом).

Бытует мнение, что накладные расходы на вызов методов и организацию процесса выполнения не должны превышать 15% времени выполнения приложения, иначе стоит серьезно задуматься над вопросом рефакторинга приложения и оптимизации его логики. Вооружившись такими мыслями я наткнулся на метод QuickSort из стандартного класса ArraySortHelper<T> использующийся для сортировки массивов в .Net.

Интересным моментом здесь является сравнение элементов — для обеспечения гибкости его вынеслив отдельный класс реализующий интерфейс IComparer<T>. Вооружившись разнообразными мыслями и студией было решено оценить сколько же такая гибкость стоит и что с этим можно было бы сделать — под катом анализ затрат на сравнение элементов во временя работы QuickSort.

Думаю, что многие Java-разработчики знают или хотя бы слышали о методе String.intern(). Но далеко не каждый использует его в своих приложениях или представляет в каких случаях он полезен и полезен ли вообще. Так было и со мной до тех пор пока я не столкнулся с этим методом в одном из проектов. В тот момент я захотел узнать смысл и особенности его использования и набрел на одну весьма интересную статью ведущего разработчика Yahoo! по имени Ethan Nicholas, переводом которой теперь хочу поделиться с той частью Хабра-сообщества, которая не безразлична к языку Java.

Тем, кто знает об этом методе лишь понаслышке, добро пожаловать под кат.

Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

Хочу представить вашему вниманию фичу MySQL — профайлинг.
Появилась она начиная с версии 5.0.37.

Всего парой запросов можно узнать, какими запросами формируется страница (для веб-девелоперов)
и почему она тормозит.

И раньше подобный функционал был доступен, но пользоваться журналом запросов не в пример сложнее.

Итак, как пользоваться:

Недавно меня попросили сравнить провести тесты шаблонизатора для используемого нами фреймворка Grails. Зачем такие тесты нужны и что они, собственно, скажут о производительности приложения — не знаю. Однако это весело и народ такие тесты очень любит.

Собственно, у Grails никакого шаблонизатора нет, а есть язык Groovy, который можно использовать внутри серверных страничек (GSP — Groovy Server Pages). Итак, хотим измерить производительность языка Groovy. В качестве базовой точки отсчета используется язык PHP.

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

26 октября 2009 года состоялась SpeedGeeks L.A. в Южной Калифорнии.
Тематика — достижение высокой производительности веб-сайтов.

Вашему вниманию хотелось бы представить видео и презентации. Которые недавно были опубликованы.

Videos All

Часто при обсуждении различных способов виртуализации, сторонники Virtuozzo (обычно, хостеры на OpenVZ) вспоминают про услышенное когда-то и где-то утверждение типа «Xen тормозит при работе с диском». Заблуждение это имеет корни, связанные с радикально отличающимися механизмами кэширования диска у виртуальных машин Xen и контейнеров Виртуоззо. Как следствие, сильно отличаются при различных условиях характеристики производительности дисковой системы. Но заблуждение оседает в сознании крепко и надолго.

Чтобы закрыть тему «тормозов диска у Xen» и показать с цифрами, что тормозов нет, вот результаты unixbench, bonnie++ и упаковки исходников линуксовского ядра на одной и той же машине, на одном и том же разделе диска.

В nosql-базе MongoDB есть аналог mysql'ного INSERT… ON DUPLICATE KEY UPDATE — upsert'ы (UPdate or inSERT).

Насколько быстро это делает mongodb?

Вопрос не праздный, так как при upsert'ах выполняются две операции — чтение и запись. Наличие индексов ускоряет чтение, но замедляет запись. Кто из них сильнее ускоряет, а кто круче замедляет?

upd: добавлен еще один график

Сейчас многие сайты насыщены графикой в разных видах: аватары, иллюстрации к постам, галереи и тп.

Читатели блога «Клиентская оптимизация» как никто другой знают цену лишних запросов к серверу.

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

3 доклада по MySQL на DEVCONF 2010 17 мая Москва

— Мониторинг производительности MySQL с использованием performance
Алексей Копытов, Senior Software Developer, Sun Microsystems.
— Решения высокой надежности на базе MySQL
Алик Рубин, MySQL, Норвегия
— MariaDB — ветка MySQL с большими возможностями
Сергей Петруня (Monty Program Ab)

Голосуем — поддерживаем наших :-)
devconf.ru/offers

А давайте сегодня взглянем на PHP немного с другой точки зрения, и напишем к нему расширение. Так как на эту тему уже были публикации на Хабре (здесь и здесь), то не будем углубляться в причины того, для чего это может оказаться полезным и для чего может быть использовано на практике. Эта статья расскажет, как собирать простые расширения под Windows с использованием Visual C++ и под Debian с использованием GCC. Также я постараюсь немного осветить работу с PHP-массивами внутри расширений и провести сравнение производительности алгоритма, написанного на native PHP и использующего код, написанный на C.

Оптимизация явно не является коньком MySQL сервера. Цель данной статьи объяснить разработчикам, которые плотно не работают с базами данных и иногда не понимают, по какой причине запрос, который успешно отрабатывает в других СУБД, в MySQL безбожно тормозит, каким образом оптимизируется конструкция between в MySQL.
MySQL использует rule based оптимизатор. Зачатки cost based оптимизации в нем конечно присутствуют, но не в должной мере, в какой их хотелось бы видеть. По этой причине часто мощности получаемых после применения фильтров множеств вычисляются неверно. Это приводит к ошибкам оптимизатора и выбору неверного плана выполнения. При чем полученные between оптимизации невозможно изменить явным указанием: индексов для выполнения запроса и порядка соединения таблиц.

Как известно в Perl не очень удобная поддержка объектно-ориентированного программирования. Если хочется программировать с классами, то многое приходится делать вручную. Однако у Perl'а есть очень богатые возможности расширения, поэтому со временем появилось много библиотек (пакетов) обеспечивающих поддержку классов, методов и свойств с синтаксисом различной степени удобности. Но как оказалось, эти пакеты проигрывают в производительности по сравнению с ручной реализацией конструкций ООП. Т.е. с одной стороны, их приятно использовать, а с другой, они делают код медленнее. Мне всегда хотелось узнать насколько медленее становится код, и какие из этих пакетов стоит применять, а какие нет. Поэтому я решил провести небольшое исследование.

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

Всех кого заинтересовала тема, добро пожаловать под кат…

Введение

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

Интересно, что, как правило, даже тяжелые фреймворки (вроде Symfony или RoR) на «медленных» языках, в production-окружении работают достаточно сносно по скорости, а основные «тормоза» вызываются SQL-запросами и неграмотным кешированием (к примеру, инициализация достаточно сложной и большой конфигурации проекта на Symfony занимает около 80 мс, а времена исполнения страницы, при этом, иногда достигают секунды и более).

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

Tsung — это распределенная система нагрузочного тестирования, написанная на Erlang'е. Заявлена поддержка HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP and XMPP/Jabber. В этой статье я опишу как протестировать обычный web сайт на нагрузку.