Новая Opera 9.5 alpha, которая была выпущена во вторник получила множество хороших отзывов, во многих из них упоминалось об увеличение быстродействия и производительности.

Так действительно ли Opera 9.5 быстрее Opera 9.23, Firefox, Safari, и Internet Explorer?

Что же, спасибо NonTroppo — мы имеем первый независимый тест для Opera 9.5 alpha (кодовое имя Kestrel) сравнивающий Opera с другими браузерами.

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.

Привет подписчикам корпоративного хабраблога EPAM Systems Ukraine!

В четверг 1 ноября состоялась вторая встреча EPAM IT Share, на которой Михаил Петрук P0WERMIC и Юрий Шаповалов рассказывали нам о том, над чем работают и как решают проблемы, которые ложатся на их плечи.

В этом небольшом отчёте вы найдёте видео материалы встречи и файлы презентаций.

По счастливой случайности мне в попала в руки консоль от двух спарков МЦСТ — R500 и R1000. Я признаюсь довольно скептически отношусь к проектам Российских электронщиков, так что мне захотелось посмотреть на их производительность. Результатами чего спешу поделиться.

Навеяно постом уважаемого amarao о том, как надо измерять производительность дисков.

Цель:

Протестировать производительность имеющихся в наличии средств хранения информации и убедиться в верности выбранной методики, а также понять разницу в производительности между разными видами накопителей, а также enterprise-level и consumer-level жёсткими дисками.

Оборудование:

1. SD-карта Sandisk Class 10 UHS 1 Extreme Pro 8 GB (до 95 Мбайт/с чтение, до 90 Мбайт/с запись)
2. SD-карта Team Class 10 32 GB (до 20 Мбайт/с)
3. SD-карта Transcend 2GB без класса скорости
4. SSD-диск OCZ-AGILITY3 60 GB
5. SATA-диск consumer-level Hitachi Deskstar HDS723020BLA642 2 ТБ 7200 об/мин, 64 Мбайт
6. SATA-диск enterprise-level Western Digital RE3 WD2502ABYS-23B7A0 250 GB 7200 об/мин 16 Мбайт
7. SATA-диск consumer-level Seagate Barracuda 7200.11 ST3320613AS 320 GB 7200 об/мин 16 Mбайт
8. CD-ROM
9. RAM-диск /dev/ram в Linux

Методика тестирования:

Методика полностью описана в посте. Есть правда несколько не совсем понятных моментов:

Мы подбираем такую глубину параллельности операций, чтобы latency оставалось в разумных пределах.

Задача подобрать такой iodepth, чтобы avg.latency была меньше 10мс.

Так как в тестировании используется не СХД и не диски SAS, а различные накопители SATA, то параллельность нам измерять нету смысла.
Очищать диск перед каждым тестированием (dd if=/dev/zero of=/dev/sdz bs=2M oflag=direct) очень времязатратно, поэтому будем это делать перед тестированием один раз на каждый накопитель.
Тестировать весь диск полностью очень времязатратно, поэтому будем использовать тестирование в течении 30 секунд.
Итак, сформулируем методику тестирования для нашего случая:
Получить значение IOPS, выдаваемое накопителем при произвольном чтении и записи блоками по 4 Кбайт и задержке avg.latency не более 10 мс за время теста в 30 секунд. Также для полноты картины измерим скорость линейной записи.

[ english version ]

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

Поэтому было решено набросать свой, ведь это всего 3-5 классиков в данном случае. Основные требования: быстрота и динамическая генерация запросов. При этом быстрота это не просто тысячи RPS, а в идеале — когда стресс упирается только в пропускную способность сети и работает с любой свободной машины.

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

В синтаксисе T-SQL для выполнения подобного преобразования предусмотрена отдельная конструкция PIVOT. Стоит заметить, что в SQL Server 2000 поддержки конструкции PIVOT еще не было, поэтому аналогичные задачи решались через множественные CASE WHEN.

Собственно, почему я упомянул о CASE WHEN, если есть PIVOT? Ведь, по определению, PIVOT более элегантная конструкция и, соответственно, должна быть более эффективной.

Проверим это на практике…

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

Целью данной статьи помощь системным администраторам и системным интеграторам в понимании настроек и нюансов при тестировании СХД NetApp. Хочу также отметить, что в этой статье не было задачи в получении максимально возможной производительности контроллеров NetApp FAS 2240, так как на момент тестирования демо оборудования не было достаточного количества дисков (144 максимум) для СХД, а также в наличии был только один сервер. Т.е. максимальная производительность здесь рассматривается в контексте конкретной конфигурации демо стенда, другими словами при большем количестве дисков, серверов и подключений по сети возможно получить результаты ещё лучше с теми же контроллерами 2240. Хотя все графики с результатами производительности взяты с реальных конфигураций конечных заказчиков, использующих в тестах контроллеры 2240, в некоторых тестах использовались четыре SSD 100GB MLC диска.

Ниже приведено комплексное описание нагрузочного тестирования СХД: настройки симулятора нагрузки IOMeter, методика настройка хоста и СХД NetApp FAS, снятие статистики нагрузки, а также интерпретация полученных результатов. На примере существующего демо стенда будет рассмотрены методы настройки всех его компонент, а также других возможных вариантов конфигураций с использованием NetApp FAS.

Речь пойдёт о Astrobench, библиотеке, которая поможет сделать ваш код лучше.

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

В этой статье мы опишем, как за несколько простых шагов превратить существующий нагрузочный тест, созданный при помощи Apache JMeter, в тестовый сценарий для HP StormRunner Load. Предположим, что вы создали и отладили библиотеку JMeter-тестов, и теперь хотите сымитировать большую нагрузку на ваш сервер, скажем, 10 тысяч пользователей. Сервера банков, страховых компаний, электронных магазинов и так далее сталкиваются с подобной нагрузкой ежедневно, но чтобы создать нечто подобное, пользуясь JMeter, вам, скорее всего, придется вручную устанавливать и конфигурировать десятки, если не сотни, удаленных машин. Это означает много часов работы, большие затраты на оборудование и постоянные усилия по сохранению тестовой среды для повторных запусков.

Мы предлагаем вам другое решение – запуск готовых JMeter-тестов с помощью HP StormRunner Load. StormRunner позволяет достичь нагрузки в десятки (и даже сотни) тысяч виртуальных пользователей без траты времени, денег и сил на создание собственной лаборатории. StormRunner – 100% облачный продукт, действующий по модели SaaS, так что создание удаленных машин, внедрение на них тестового программного обеспечения и сбор данных происходят автоматически, без какого-либо вмешательства пользователя.

Уважаемые читатели! Представляю вашему вниманию перевод статьи Скота Ханселмана под названием "Proper benchmarking to diagnose and solve a .NET serialization bottleneck".

Для начала, несколько оговорок и комментариев. Во-первых, процесс оценки производительности сложен. Трудно выполнять измерения. Но настоящая проблема состоит в том, что часто мы забываем, ДЛЯ ЧЕГО мы оцениваем производительность чего-либо. Мы берем сложную многомашинную финансовую систему и внезапно чрезвычайно фокусируемся на куске кода, выполняющем сериализацию, который, по нашему убеждению, и ЕСТЬ проблема. «Если я смогу оптимизировать эту сериализацию, написав for-цикл из 10000 итерации и сократив время его выполнения на x миллисекунд, все будет путем».

Автор: Роман Денисенко, старший инженер по тестированию DataArt.

Введение

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

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

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

Плохой пример хорошего теста

В последнее время в курилках часто возникали дискуссии на тему сравнения производительности различных форматов хранения данных в Apache Hadoop — включая CSV, JSON, Apache Avro и Apache Parquet. Большинство участников сразу отметают текстовые форматы как очевидных аутсайдеров, оставляя главную интригу состязанию между Avro и Parquet.

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

Как любой уважающий себя инженер, я подумал, что было бы неплохо провести полноценные performance-тесты, чтобы наконец проверить, на чьей стороне правда. Результат сравнения — под катом.

Предлагаю вашему вниманию перевод статьи Spryker Performance and Scalability Concepts.

Spryker это e‑commerce фреймворк, является результатом реализации более чем 100 индивидуальных e‑commerce проектов. Он предоставляет из коробки два важнейших архитектурных качества — высокую производительность и масштабируемость. В этой статье описываются основные концепции для их достижения.

Доброго времени суток, Хабр. Речь пойдёт об инструменте тестирования производительности СХД (систем хранения данных), изначально разработанного в недрах компании EMC для внутренних нужд, но имеющем свойство плавно разрастаться. Кстати, буквально «вчера» мангуст получил статус OpenSource проекта. А это значит, что пришло время немножко рассказать о нём. Итак, что же это за зверь?

Много ядер не бывает

Атомарные операции (atomics), например, Compare-and-Swap (CAS) или Fetch-and-Add (FAA) широко распространены в параллельном программировании.

Мульти- или многоядерные архитектуры установлены одинаково как в продуктах настольных и серверных компьютеров, так и в крупных центрах обработки данных и суперкомпьютерах. Примеры конструкций включают Intel Xeon Phi с 61 ядрами на чипе, который установлен в Tianhe-2, или AMD Bulldozer с 32 ядрами на узле, развернутых в Cray XE6. Кроме того, количество ядер на кристалле неуклонно растет и процессоры с сотнями ядер, по прогнозам, будут изготовлены в обозримом будущем. Общей чертой всех этих архитектур является растущая сложность подсистем памяти, характеризующаяся несколькими уровнями кэш-памяти с разными политиками включения, различными протоколами когерентности кэш-памяти, а также различными сетевыми топологиями на чипе, соединяющими ядра и кэш-память.

Практически все такие архитектуры обеспечивают атомарные операции, которые имеют многочисленные применения в параллельном коде. Многие из них (например, Test-and-Set) могут быть использованы для реализации блокировок и других механизмов синхронизации. Другие, например, Fetch-and-Add и Compare-and-Swap позволяют строить разные lock-free и wait-free алгоритмы и структуры данных, которые имеют более прочные гарантии прогресса, чем блокировки на основе кода. Несмотря на их важность и повсеместное употребление, выполнение атомарных операций полностью не проанализировано до сих пор. Например, по общему мнению, Compare-and-Swap идет медленнее, чем Fetch-and-Add. Тем не менее, это всего лишь показывает, что семантика Compare-and-Swap вводит понятие «wasted work», в результате – более низкая производительность некоторого кода.

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

Задача

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

2016 год провозгласили началом эпохи Flash-накопителей: флеш становится дешевле и доступнее. А вслед за снижением стоимости ssd-накопителей производители выпускают массивы, логика которых изначально создана для работы только с быстрыми флешами.  Стоимость таких решений все равно выводит их в корпоративный сегмент рынка, не позволяя небольшим компаниям познать все «прелести» ssd-эпохи. И вот, компания Synology сделала свой ход: встречайте бюджетный full-flash массив Synology FS3017. Что это – маркетинговый ход, или первый бюджетный флеш-массив?

Мотивация

Микросервисная архитектура позволяет выбирать между технологиями и языками программирования при написании REST api сервисов. Какой язык лучше выбрать, для написании REST api приложения, чтобы обеспечить большее количество одновременных пользователей быстрым и стабильным ответом на одном и том же железе? Чтобы ответить на этот вопрос было бы хорошо увидеть разницу в производительности одного и того же приложения написанного на Java и GO.

Дисклеймер

Все результаты представленные в данном эксперименте являются частным примером использования Java и GO и не должны использоваться для описания производительности этих языков в других условиях.

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

Когда речь заходить о тестировании производительности — в первую очередь все думают о JMeter’е — он бесспорно остается самым известным инструментом с самым большим количеством плагинов. Мне же JMeter никогда не нравился из-за неочевидного интерфейса и высокого порога вхождения, как только возникает необходимость протестировать не Hello World приложение.

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

Для тех, кому лень идти под кат, записал видео: