Первая статья об экспериментальном определении характеристик кэш-памяти появилась на свет несколько необычным образом. Играясь с утилитами из lmbench, я получил те самые три графика, и задался вопросом, сколько же информации об исследуемой системе можно из них вытянуть. Определив некоторые характеристики кэша и TLB, я затем задал эти графики студентам как домашнее задание — предвкушая, что им удастся обнаружить что-то такое, что я проглядел. В целом, студенты меня разочаровали, и не заметили даже связь ассоциативности с наклоном ступенек на графике. В конце семестра я собираюсь рассказать им своё решение; а чтобы оно к тому времени не забылось, я написал на скорую руку ту статью.

Затем Yekver предложил мне идею простой программы для Windows, которая определяла бы характеристики кэша автоматически, не требуя ручного анализа графиков. (Тем более, что версии lmbench для Windows не существует.) Для замера времени будем использовать функцию __rdtsc, которая возвращает 64-битное количество тактов с момента последнего сброса процессора. Сначала определим тактовую частоту процессора, замерив на произвольной нагрузке время выполнения и количество потребовавшихся тактов. Затем для расчёта времени доступа к памяти будем делить количество потраченных тактов на тактовую частоту процессора.

Подобно прошлому эксперименту, мы будем брать данные различного объёма от 4КБ до 512МБ, и проходить по массиву миллионы раз с последующим усреднением результата. Чтобы минимизировать влияние дополнительных операций в цикле нагрузки, следуя примеру авторов lat_mem_rd, используем для тела нагрузки операцию p=(void**)*p;, которая компилируется в одну машинную команду, и развернём её 256 раз, чтобы возврат к началу цикла выполнялся относительно редко.

Все началось с этой темы на форуме, когда многие на полном серьезе стали рассуждать, мол, nginx совсем не быстрее Apache, и даже перевод документации с официального сайта был неубедителен. Как известно, нет ничего более приятного, чем провести тестирование и показать график для привлечения внимания. Вот например график по обще нагрузке на сервер, попробуйте угадать где тут этап тестирования Nginx, а где — Apache.

Ну а перед тем как узнать правильный ответ — немного про сервер и механизм тестирования.
Дабы исключить всякие подозрения на «подкручивание» своих VDS, тест проводился на стороннем сервере, любезно предоставленным мне для теста одним из участников форума вот в такой кнофигурации:
AMD Athlon X2 5600+ 4 GB DDR2 2×400 GB HDD с Linux Debian в минимальной установке. Весь софт устанавливался стандартным образом — через apt-get. И PHP и Apache ставились в минимальном режиме.
Для объекта тестирования я поставил очень легкий блог Moscquito, который работает без MySQL, написав туда пару постов и камменты.

Дамы и господа! Закончен бой между двумя бойцами — Squid и Varnish

Вывод — Varnish не подходит для VDS, слишком сильно расходует память. Squid в этом плане лучше да и отклик у него быстрее.

Я убираю все графики и подготавливаю VPS'ки для следующего бенчмарка — Squid vs Nginx.
Но мне еще надо подумать что именно ставить на бакэнде, так как с отдачей статики вообще нет никаких проблем.

Посоветуйте, на чем стоит протестировать?

Напоминаю конфигурацию эталонной VPS для тестирования:

• Использует 1 ядро
• Имеет 256Mb гарантированной памяти
• Имеет 256Mb boost памяти
• За основу взят шаблон gentoo-2008

zip vs izip или «ну кому ещё объяснить фишку итераторов?»

Любовь сравнивать все со всем у людей не отнимешь. Поэтому раздолье для пузомерок всегда хватает. Так и Google решил показать чего стоят наши сайты по сравнению с другими.

Компания FutureMark, известный производитель программного обеспечения для анализа производительности ПК, представила очень интересный продукт — веб-сервис VirtualMark для оценки производительности компьютера в тех самых «попугаях» за количеством которых так любят гонятся оверклокеры и геймеры.