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

Что же представляет собой сервер баз данных? Это высокопроизводительная машина, которой всегда мало (немного утрируя):

• Процессоров
• Памяти
• Дискового пространства

То есть сервер баз данных (учитываем, что эта машина обслуживает не пару десятков человек) — это многопроцессорная (2, 4, 8 процессоров) машина, обслуживающая несколько сотен человек и хранящая довольно большой объем информации в своей базе. Поэтому дисковая подсистема является тоже критичным местом. К тому же от нее требуется безотказность работы и часто возможность горячей замены поврежденных винчестеров. Поэтому в подобных серверах обычно используются дисковые массивы RAID пятого уровня и жесткие диски на SCSI шине. Оперативная память тоже никогда не бывает лишней (она используется и операционной системой и самой базой данных). Используется память с коррекцией ошибок и ее объем начинается от полутора гигабайт и выше.

В общем, вы уже поняли, что это далеко не домашняя машина на p4 3 ГГц, 160 Гб SATA HDD, 512 Мб DDR памяти и GeForce FX 5900. Кстати говоря, вышеописанному серверу видеокарта не нужна совсем.

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

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

• Уменьшить количество денег на счету первого клиента.
• Записать результат.
• Увеличить количество денег на счету второго клиента.
• Записать результат.

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

В качестве тестирования производительности было выбрано решение от — набор тестов . Все тесты распространяются на правах открытого кода и в качестве базы данных используют , распространяемую на правах GPL/LGPL лицензии. Набор разрабатывается под Linux платформу и включает в себя три теста.

OSDL Database Test 1 (OSDL-DBT-1) представляет собой Интернет-тест производительности транзакций. Он имитирует активность пользователей, просматривающих и покупающих товары в интерактивном книжном магазине. OSDL-DBT-1 - реализация спецификаций теста . Результаты теста включают количество транзакций в секунду, степень загрузки ЦП, активности ввода-вывода и использования памяти. Основным является показатель BT — количество bogotransactions (синтетических транзакций) в секунду.

OSDL Database Test 2 — это тест производительности оперативной обработки транзакций. Он имитирует работу оптовой фирмы по продаже запасных деталей, в которой несколько пользователей работают с БД, обновляют информацию о клиентах и проверяют наличие товара на складе. OSDL-DBT-2 — реализация спецификаций теста . Результаты теста включают количество транзакций в секунду, степень загрузки ЦП, активности ввода-вывода и использования памяти.

OSDL Database Test 3 (OSDL-DBT-3) — этот тест имитирует средства поддержки принятия решений. Он включает нерегламентированные запросы и параллельное изменение данных. OSDL-DBT-3 — реализация спецификаций теста .

В этой статье подробно остановлюсь на тесте OSDL-DBT-1.

Проект OSDL Database Test 1 (OSDL-DBT-1) нацелен на разработку легкого в использовании теста обработки транзакций для ОС Linux и ПО с открытым исходным кодом с возможностью удобного обмена результатами с другим разработчиками. Данный тест является упрощенной производной спецификации TPC-W (tm) от TPC. TPC-W используется в данном случае как шаблон, так как считается, что он имитирует нагрузку, достаточную для оптимизации производительности.

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

Необходимо помнить, что результаты OSDL-DBT-1 нельзя сравнивать с результатами теста TPC-W. TPC требует, чтобы все опубликованные результаты удовлетворяли строгим правилам публикации и аудита, гарантирующих честное сравнение с конкурирующими тестами. Правила TPC также требуют указания стоимостей и доступности продуктов, использованных для тестирования. Следовать этим правилам в открытых разработках непрактично, поэтому результаты теста OSDL-DBT-1 не имеют никакого отношения к результатам теста TPC-W Benchmark.

Что такое TPC-W?

TPC-W определяет коммерческую деятельность интерактивного книжного магазина. Типичный комплект TPC-W включает эмуляторы удаленных браузеров (RBE), веб-серверы и базу данных. Подробное описание теста TPC-W есть на .

Рабочая нагрузка создается RBE, которые эмулируют активность пользователей, открывающих в браузере множество интерактивных сессий для просмотра и заказа продуктов в магазине. Эмулируется 14 веб-страниц:

• Главная;
• Корзина;
• Регистрация покупателей;
• Заказ;
• Подтверждение заказа;
• Запрос о заказе;
• Выведенные данные о заказе;
• Поисковый запрос;
• Результаты поиска;
• Новые продукты;
• Лидеры продаж;
• Подробное описание продукта;
• Запросы администратора;
• Подтверждение запросов администратора;

Одна веб-страница представляет одно взаимодействие. Каждое взаимодействие может включать в себя один или более обмен между тестируемой системой и эмулированным браузером. Обмены могут включать в себя запросы и передачу файлов cookie, HTML-страниц, изображений и т.д. Эмулированные браузеры работают в соответствии с определенными правилами перехода между страницами, которые имитируют поведение реального пользователя и гарантируют, что доступ к 14 страницам удовлетворяет требованиям TPC-W «Web Interaction Mix», определяющим процентный диапазон каждой транзакции.

При получении запроса от RBE, веб-серверы обращаются к веб-страницам, динамически их обновляют и отсылают обратно. Серверы коммерческого веб-сайта обычно разделены на группы по назначению. Например, сервер изображений обслуживает файлы «.gif» и «.jpg», HTTP-сервер и сервер приложений исполняет бизнес-логику и работает с базой данных, а кэширующий сервер работает с кэшируемыми объектами. Для имитации поиска по сайту спецификация TPC-W предоставляет коммерчески доступную подсистему текстового поиска, которая создает и управляет статическими индексами вне базы данных. TPC-W также требует наличие эмулятора платежного шлюза, имитирующего работу с кредитными картами.

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

На Рис.1 приведена типичная архитектура TPC-W.

Что такое OSDL-DBT-1?

OSDL-DBT-1 представляет собой набор тестов на основе транзакций. Он нагружает базу данных в соответствии со спецификацией TPC-W. Тест включает в себя базу данных, сервер управления транзакциями и драйвер.

На Рис.2 показаны компоненты OSDL-DBT-1.

Драйвер OSDL-DBT-1 выполняет задачи, сходные с задачами RBE в TPC-W. Он создает и управляет эмулированными пользователями, которые следуют логике, сходной с логикой браузера в тесте TPC-W, но создают вместо HTTP-запросов структуры данных.

В отличие от теста TPC-WTM, использующего веб-серверы для сетевых объектов, тест OSDL-DBT-1 работает с сервером управления транзакциями, который упрощает тестирование и полностью исключает уровень веб-серверов.

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

Базы данных в тестах OSDL-DBT-1 и TPC-W имеют, по существу, одинаковые таблицы с одинаковыми описаниями и следуют одним и тем же правилам заполнения. Хранимые процедуры исполняют одну и ту же бизнес-логику. Некоторые из хранимых процедур OSDL-DBT-1 возвращают меньше данных, чем определено для TPC-W.

Архитектура OSDL-DBT-1

Тест OSDL-DBT-1 состоит из трех компонентов: драйвер (driver), сервер управления транзакциями (transaction management server) и база данных. Первые два компонента написаны на языке C и используют интерфейс ODBC для работы. В качестве базы данных был взять сторонний продукт — SAP DB (версии 7.3). Тест разрабатывался под RedHat Linux 7.2, но может использоваться на всех стандартных Linux ОС.

Драйвер непосредственно нагружает базу данных. Он представляет собой многопоточную программу, в которой каждый поток выполняет действия одного пользователя. Драйвер скомпилирован в два отдельных двоичных файла. Первый из них (dbdriver_p1) связан с интерфейсом ODBC и взаимодействует с базой данных напрямую, в обход менеджера транзакций. Этот драйвер можно использовать для простого функционального тестирования хранимых процедур. Второй двоичный файл (dbdriver_p2) связан с сокет-интерфейсом и взаимодействует с сервером управления транзакциями. Данный драйвер играет главную роль в тестировании производительности.

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

На Рис.3 показан сервер управления транзакциями и его связь с драйвером и базой данных:

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

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

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

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

База данных

База данных состоит из таблиц, индексов и хранимых процедур. Таблицы содержат информацию о товарах интерактивного книжного магазина. Хранимые процедуры выполняют запросы. Индексы создаются для ускорения выполнения запросов. С помощью базы данных эмулированные пользователи могут создавать запросы о лидерах продаж, новых книгах, книгах конкретных авторов и т.д.

Методика тестирования тестом OSDL-DBT-1

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

• Dual Pentium 4 XEON 2,4 ГГц с технологией HT;
• 2 Гб DDR266 ECC ОЗУ;
• Материнская плата — ASUS PP-DLW на чипсете Intel E7505;
• Dual Ultra160 SCSI RAID контроллер Intel SRC32U cо 128 МБ ECC SDRAM кеша;
• 74 Гб общий объем дискового пространства — 3× Cheetah 15K.3 (ST336753LC с интерфейсом Ultra320 SCSI объемом 37 Гб) в RAID5;
• Сетевой контроллер — Intel 82540 Gigabit Ethernet (интегрированный);
• ATI Radeon 9800Pro;
• TDK 440N DVD-R/RW для бекапов;
• Asus 52× CD-ROM

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

Дисковое пространство делится на четыре раздела

• Linux SWAP размером 5 Гб;
• Два Linux раздела, каждый по 10 Гб
• Корневой раздел в формате EXT3 — все остальное доступное пространство

На сервер устанавливается RedHat Linux 7.3 (с версией 9.0 используемая версия SAP DB базы, рекомендуемая разработчиками OSDL тестов, работает некорректно).

Собирается ядро 2.4.21 (полный конфиг ядра) с активированными опциями в Processor type and features

• (Pentium-4) Processor family
• (4GB) High Memory Support
• [*] HIGHMEM I/O support
• [*] MTRR (Memory Type Range Register) support
• [*] Symmetric multi-processing support

Из RPM-пакетов устанавливается SAP DB версии 7.3.0.25, все ее настройки остаются по умолчанию.

• Количество эмулируемых пользователей (UEs, number of emulated users) — 500;
• Количество вещей в базе (number of items) — 10000 (значение по умолчанию)

Общий размер базы данных при вышезаданных параметрах получается около 2,4 гигабайт.

Так же задаются параметры для ядра SAP DB, такие как

• DATA_CACHE 235930

  Максимальный размер shared памяти в 8 Кб страницах, используемый при запросах к данной базе и для ядра SAP DB. Необходимо выделять как можно больший объем памяти, но не более, чем доступный размер ОЗУ на тестируемом компьютере. В данном случае использовано значение 90 процентов от объема ОЗУ.

• MAXUSERTASKS 50

  Количество одновременных соединений с БД. Значение по умолчанию.

• MAXCPU 4

  Максимальное количество процессоров, которое может задействовать ядро БД при обработке запросов.

Для ускорения доступа, создаются два RAW устройства
/usr/bin/raw /dev/raw/rawX /dev/sdaX
Устройства используются для хранения логов и данных текущей базы.

Строка запуска скрипта на генерацию базы:
./build_db.sh -g -i 10000 -u 1000 -p /home/sapdb/dbt1/tmp/

После создания исходных данных, модифицируется конфигурационный файл dbt1.config тестирующего скрипта. В нем устанавливается запуск всех частей теста на одном (тестируемом) компьютере, а так же задаются следующие параметры

• • dbconnection = 100
    количество соединений, открываемых к БД из программ appServer и appCache;
  • transaction_queue_size = 400 (по умолчанию)
    максимально количество транзакций в очереди AppServer;
  • transaction_array_size = 400 (по умолчанию)
    максимально количество транзакций в очереди на одного клиента;
  • items = 10000
    количество вещей в базе
  • • items = 10000;
    • eu = 400
      количество эмулируемых пользователей;
    • eu/min = 50 (по умолчанию)
      количество пользователей, появляющихся за минуту;
    • mean think_time = 7.2 (по умолчанию)
      время ожидания между действиями пользователя (в сек);
    • run_duration = 4100 (по умолчанию)
      время выполнения теста (в сек);

  После чего тест запускается на выполнение (примерно на час). Строка запуска скрипта:
  ./run_dbt1.sh /home/sapdb/dbt1/tmp/res

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

  Результаты

  Результаты OSDL DBT-1 представлены в виде большого количества текстовых файлов. Основной показателем является количество BTs (боготранзакций в секунду). Interaction % Avg. Response Time (s) Admin Confirm 0.09 0.274 Admin Request 0.10 0.259 Best Sellers 4.95 1.103 Buy Confirm 1.18 0.565 Buy Request 2.55 0.586 Customer Registration 2.94 0.000 Home 16.69 0.505 New Products 4.98 1.125 Order Display 0.65 0.554 Order Inquiry 0.74 0.470 Product Detail 16.92 0.467 Search Request 19.88 0.478 Search Results 16.92 0.684 Shopping Cart 11.41 0.510 59.3 bogotransactions per second 68.5 minute duration total bogotransactions 243754 total errors 0

  Вторым важным показателем является во время исполнения теста. Cpu Statistics (sar -u) Linux s1 2.4.21-2421-ism2 #4 SMP Mon Jul 14 20:08:52 MSD 2003 i686 unknown Linux 2.4.21-2421-ism2 (s1) 07/16/03 17:34:35 CPU %user %nice %system %iowait %idle […] Average: all 50.46 0.00 6.38 0.00 43.16

  Хорошо видно, что в данном случае процессоры были загружены лишь наполовину. Для полной загрузки возможно потребуется увеличить количество EU (эмулируемых пользователей), а так же размер самой базы данных (items). При увеличении количества пользователей мы сталкиваемся с ограничением glibc и библиотеки pthread, которое не позволяет эмулировать больше, чем примерно 900 EU с одной машины. В этом случае придется запускать несколько программ dbdriver и appServer на разных машинах.

  Кроме вышеописанных, существуют еще большое количество отчетов-статистик.

  • индивидуальная по процессорам , (это результаты в тесте без HT);
  .

  Особая благодарность Cormac за помощь с переводом спецификаций.

Развитая технология тестирования является эффективным средством контроля знаний на любых стадиях учебного процесса. Программный комплекс «Студия визуального тестирования» позволяет автоматизировать контроль знаний студентов, включая создание набора тестовых заданий, проведение тестирования студентов и анализ результатов.

Комплекс состоит из модулей:

Редактор тестов - для создания тестовых заданий;
- Редактор сценариев - для задания параметров тестирования студентов;
- Тестовая оболочка - для проведения тестирования в образовательном учреждении;
- Результаты тестирования - для анализа и просмотра результатов тестирования;
- Списки студентов - для управления списками групп и студентов;
- Администрирование - для управления безопасностью программного комплекса.

Редактор тестов позволяет создавать тестовые задания 7 различных видов: Да/Нет, выбор одного или нескольких правильных ответов, ввод числа или слова, установление последовательности и соответствия. При создании текста можно использовать формулы, рисунки и сложное форматирование.
В редакторе сценариев можно выбрать, какие задания использовать в тестировании из одного или нескольких тестов, задать время и количество заданий, определить режим тестирования.

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

Для определения оценки могут использоваться два алгоритма, один из которых учитывает статистическую погрешность угадывания правильного варианта ответа. Единая база данных хранит задания и накапливаемую статистику тестирования, которую можно использовать для оценки качества тестовых заданий и совершенствования теста.
Для обеспечения безопасности используется многоуровневая система управления доступом, шифрование, парольная или Windows-аутентификация и аудит событий.
Система тестирования может использоваться как отдельная система, так и в связке с другими системами автоматизации. В этом случае автоматически загружаются списки студентов из ИС «Деканат» и результаты тестирования могут экспортироваться в ИС «Электронные ведомости».

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

В результате использования автоматизированной системы тестирования:
1) Производительность труда преподавателя во время контрольных мероприятий возрастает в 8-10 раз.
2) Исключается субъективность при оценке знаний.
3) Возможно использование тестирования как входного контроля перед экзаменом.
4) Созданный банк тестовых заданий можно использоваться повторно.
5) Результаты тестирования могут быть использованы при анализе успеваемости и качества тестовых заданий.

В процессе повседневной эксплуатации ИТ-систем достаточно трудно оценить соответствие параметров аппаратной инфраструктуры актуальным техническим требованиям и текущим бизнес-процессам.

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

Какие задачи решает нагрузочное тестирование

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

Основные этапы нагрузочного тестирования

• Определение критериев испытания

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

• Проведение испытаний

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

• Анализ результатов тестирования

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

Тестирование различных компонентов системы

• Сетевая архитектура

Выявление потенциальных дефектов сетевых адаптеров и драйверов. Установление запаса производительности и определение качества работы сети.

• Приложения

Оценка максимальной эффективности работы выбранных приложений при заданных значениях метрик производительности. Типичные объекты исследования - операционные системы (Linux, MS Windows Server, Solaris), серверы приложений (WildFly (RedHat JBoss Application Server), IBM WebSphere, WebLogic), системы управления базами данных (MySQL, PostgreSQL, MS SQL), корпоративное ПО (ERP-, CRM-системы и т.д.)

• Базы данных

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

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

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

Компания сайт уверена в высоких показателях качества предоставляемых услуг, поэтому предлагает клиентам воспользоваться тестовым периодом. Используя VPS/VDS-сервер в тестовом режиме, Вы сможете оценить работу сервера и убедиться в надёжности нашей компании.

Существуют ли отличия между платным и тестовым VPS/VDS?

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

Что даст тестовый период?

• Возможность поработать в реальных условиях. VPS/VDS-сервер, предоставленный на тестовый период, технически ничем не ограничен. Функциональность и платформенный возможности такие же, как и при платном предоставлении
• Возможность сравнить разницу тарифных планов, для подбора оптимального варианта для собственных нужд
• В тестовый период Вы можете устанавливать необходимый софт и полноценно настраивать операционную систему
• Полноценное взаимодействие со службой технической поддержки, равнозначное платному периоду

Условия тестового периода

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

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

When it is time to run a public test, an appropriate announcement will be published on the World of Tanks website. Shortly after, the developers will release a test version of the client. This can be downloaded by following . Make sure that you follow all of the instructions carefully, so that you don’t accidentally cause problems to your main play account.

Your test client account will usually be a copy of your play account, meaning that all the vehicles purchased and the research that you have completed will be the same. However, please note:

• The test account is completely separate from your normal account. Achievements and research that you complete on the test client will not be carried over to your play account.
• Financial transactions are not possible on the test server and payments will not be accepted.
• Depending on the needs of the test, your test account may be credited with gold, credits and/or experience.

The test server is subject to the same EULA and general rules as the World of Tanks game server. This means that you still need to play nice or you will face the usual consequences in the same way as you would on the official game server.

All test accounts will receive a one-time credit of:

• 100,000,000
• 100,000,000
• 20,000

The rate at which you gain credits and experience will not be increased for the test unless stated otherwise in the appropriate announcement.

Feedback

Once you have logged into the test client, you are free to play as much or as little as you want. We encourage you to try out all the new features and see what you can do!

Once you have been playing for a while, please let us know your feedback by posting in the dedicated forum threads. These threads are divided into two categories: bug reports and general feedback about the test version . The appropriate links will be provided in the respective announcement. The community managers will collect up all your responses on the thread and send them to the developers.

The sort of feedback we are particularly interested in includes:

• Any bugs or glitches that you have found in the game. Got stuck in the scenery? Game crashes when you do a certain action? Tell us all about it!
• Honest feedback about vehicles and game mechanics. If you think something doesn’t function well, then please tell us.
• Anything you particularly like? Do you love the new stats for a previously underpowered vehicle? Confirm to the developers that the community is now satisfied with that feature, letting them focus on other new improvements.

How to Join the Public Test

In order to join a test, please follow these instructions:

1. Download the test client installer (the link will be provided in the announcement)
2. Make sure you pick a save location that is different to your regular World of Tanks game files. Save and run the installer.
3. Run the new copy of the game. The launcher will download all the additional data (the amount of data may vary).
4. Log in and start playing. Remember to post your feedback in the appropriate forum threads.

Please be aware of the following:

In order to make the test experience more efficient, it may be necessary to limit the number of players on the test server. If the server is full when you log in, you’ll be placed into a queue.

The test server will be restarted regularly, according to the following schedule:

• First Periphery: every EVEN day of the month. Average duration will be around 25 minutes.
• Second Periphery: every ODD day of the month. Average duration will be around 25 minutes.
• Central Database: every day. Average duration will be around 2 or 3 minutes.

The test server may be subject to unscheduled restarts and maintenance.

IMPORTANT: Please remember that it is a test server. This means that you may encounter bugs and temporary features. Everything in the test version could change before the final release.