К концу 2012 года более 50% приложений работающих на х86 платформе виртуализированы. Вместе с тем виртуализировано только 20% бизнес критических приложений.

Это из-за того что ИТ отделы не доверяют платформам виртуализации? Считают ли они платформы виртуализации не достаточно стабильными для поддержки работы критически важных приложений?

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

Тогда если доверие или стабильность не являются проблемой в чём же причина того что ИТ отделы еще не виртуализировали оставшиеся приложения?

Scale out
Scale out или горизонтальное масштабирование - добавление новых ресурсов в инфраструктуру, например, серверов в кластер.

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

Последние семь лет архитекторы инфраструктур на VMware молились на горизонтальное масштабирование. Кто-то может аргументировать за использование именного этого подхода, но он тоже имеет свои нюансы, и всё зависит от требований бизнеса. Плюс горизонтального масштабирования в том, что commodity сервера дёшевы, и в случае выхода сервера из строя это влияет на небольшое количество ВМ. Минус в бОльших затратах на лицензии на vSphere, большие требования к площади ЦОД, и обычно такие commodity сервера не обладают большими вычислительными ресурсами.

Scale up
Вертикальное масштабирование - добавление вычислительных ресурсов в какой-то уже используемый сервер. Обычно это процессоры или оперативная память.

Обычно такие сервера довольно мощные - с поддержкой 4 процессоров и 512ГБ памяти. Кроме того встречаются системы с 8 процессорами и 1ТБ памяти, а некоторым повезло увидеть даже 16-ти процессорные сервера с 4ТБ памяти. И нет, это не мейнфреймы или что-то типа того, это сервера на основе классической х86 архитектуры.

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

• Недостаточные возможности по масштабированию. Нагрузки с высокими требованиями к объёму вычислительных ресурсов являются проблемой из-за ограниченного объёма ресурсов доступных с дешёвыми commodity серверами.
• Недостаточная надёжность. Commodity оборудование или аппаратное обеспечение использующее такие компоненты может быть менее надёжным. Проблему надёжности можно решить с помощью функций о которых я расскажу в следующих статьях.
• Увеличение сложности управления и рост операционных расходов. Легче управлять 100 серверами, а не 1000, ну и, как следствие, 10 серверами управлять проще чем 100. Тоже самое касается и операционных расходов - 10 серверов гораздо дешевле поддерживать чем 100.

Вертикальное масштабирование отлично подходит для бизнес критических приложений с их огромными требованиями к ресурсам. Привет, Monster VM! Все эти прожорливые критичные базы данных, огромные ERP системы, системы аналитики больших данных, JAVA приложения и так далее и тому подобное получат прямую выгоду от вертикального масштабирования.

С выходом vSphere 5 количество ресурсов, доступных одной ВМ выросло в 4 раза.

А с выходом vSphere 5.1 монструозные ВМ могут быть еще монструознее.

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

Всего существует два типа вертикального масштабирования серверов: glueless и glued. На русский язык эти слова переводятся так: без интегрирующих технологий и с интегрирующими технологиями, соответственно.

Glueless архитектура
Данная архитектура была разработана в Intel, и представлена в Intel Xeon E7.

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

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

В 8-ми процессорном сервере каждый процессор напрямую подключается к трём соседним, и через другой процессор к другим четырём.

Преимущества такой архитектуры:

• Нет необходимости в специальной разработке или специализации у производителя серверов
• Любой производитель серверов может выпускать 8-ми процессорные сервера
• Снижается стоимость как 4-ёх так и 8-ми процессорного сервера

Недостатки:

• Общая стоимость владения растёт при горизонтальном масштабировании
• Архитектура ограничена 8-ми процессорными серверами
• Тяжело поддерживать целостность кэша при увеличении сокетов
• Нелинейный рост производительности
• Соотношение цены к производительности падает
• Неоптимальная эффективность при использовании больших ВМ
• Вплоть до 65% пропускной способности шины уходит на широковещательные сообщения болтливого протокола QPI

В чём же причина болтливости протокола QPI? Для того чтобы достичь целостности процессорного кэша каждая операция на чтение должна быть реплицирована на все процессоры. Это можно сравнить с широковещательным пакетом в IP сети. Каждый процессор должен проверить у себя затребованную строку памяти, и в случае использования последней версии данных предоставить её. В случае если актуальные данные находятся в другом кэше протокол QPI с минимальными задержками копирует данную строку памяти из удалённого кэша. Таким образом на репликацию каждой операции чтения тратиться пропускная способность шины и такты кэша, которые могли бы использоваться для передачи полезных данных.

Основные приложения, производительность которых страдает от недостатков протокола QPI это Java приложения, большие БД, чувствительные к задержкам приложения.

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

Glued архитектура
Для решения описанных выше проблем разработчики аппаратного обеспечения разработали glued архитектуру. Данная архитектура использует внешний контроллер нод для организации взаимосвязи островков QPI - кластеров процессоров.

Intel QPI предлагает специальное масштабируемое решение - eXternal Node-Controllers (или XNC), практическая реализация которого разрабатывается сторонними OEM компаниями. Внешний контроллер нод, используемый начиная с Intel Xeon E7-4800, со встроенным контроллером памяти, включает в себя также систему Cache Coherent Non-Uniform Memory Access (ccNUMA) задача которой отслеживать актуальность данных в каждой строке памяти процессорного кэша были актуальные данные.

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

Вертикальное масштабирование — scaling up — увеличение количества доступных для ПО ресурсов за счет увеличения мощности применяемых с серверов.

— scaling out — увеличение количества нод, объединенных в кластер серверов при нехватке CPU, памяти или дискового пространства.

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

Вертикальное и горизонтальное масштабирование, scaling для web

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

Возможности для масштабирования для серверов баз данных определяются применяемыми программными решениями: чаще всего это реляционные базы данных (MySQL, Postgresql) или NoSQL ( , Cassandra и др).

Горизонтальное масштабирование для серверов баз данных при больших нагрузках значительно дешевле

Веб-проект обычно начинают на одном сервере, ресурсы которого при росте заканчиваются. В такой ситуации возможны 2 варианта:

• перенести сайт на более мощный сервер
• добавить еще один сервер небольшой мощности с объединить машины в кластер

MySQL является самой популярной RDBMS и, как и любая из них, требует для работы под нагрузкой много серверных ресурсов. Масштабирование возможно, в основном, вверх. Есть шардинг (для его настройки требуется вносить изменения в код) и , которая может быть сложной в поддержке.

Вертикальное масштабирование

NoSQL масштабируется легко и второй вариант с, например, MongoDB будет значительно выгоднее материально, при этом не потребует трудозатратных настроек и поддержки получившегося решения. Шардинг осуществляется автоматически.

Таким образом с MySQL нужен будет сервер с большим количеством CPU и оперативной памяти, такие сервера имеют значительную стоимость.

Горизонтальное масштабирование
С MongoDB можно добавить еще один средний сервер и полученное решение будет стабильно работать давая дополнительно отказоустойчивость.

Scale-out или является закономерным этапом развития инфраструктуры. Любой сервер имеет ограничения и когда они достигнуты или когда стоимость более мощного сервера оказывается неоправданно высокой добавляются новые машины. Нагрузка распределяется между ними. Также это дает отказоустойчивость.

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

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

Читайте про и балансер

) Здравствуйте! Я Александр Макаров, и вы можете меня знать по фреймворку «Yii» — я один из его разработчиков. У меня также есть full-time работа — и это уже не стартап — Stay.com, который занимается путешествиями.

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

Что такое масштабирование, вообще? Это возможность увеличить производительность проекта за минимальное время путем добавления ресурсов.

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

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

Самый классный вопрос, который задают, — а зачем оно надо, если у меня все и на одном сервере прекрасно работает? На самом-то деле, надо проверить, что будет. Т.е., сейчас оно работает, но что будет потом? Есть две замечательные утилиты — ab и siege, которые как бы нагоняют тучу пользователей конкурента, которые начинают долбить сервер, пытаются запросить странички, послать какие-то запросы. Вы должны указать, что им делать, а утилиты формируют такие вот отчеты:

Главные два параметра: n — количество запросов, которые надо сделать, с — количество одновременных запросов. Таким образом они проверяют конкурентность.

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

Есть еще один параметр — Response time — время ответа, за которое в среднем сервер отдал страничку. Оно бывает разное, но известно, что около 300 мс — это норма, а что выше — уже не очень хорошо, потому что эти 300 мс отрабатывает сервер, к этому прибавляются еще 300-600 мс, которые отрабатывает клиент, т.е. пока все загрузится — стили, картинки и остальное — тоже проходит время.

Бывает, что на самом деле пока и не надо заботиться о масштабировании — идем на сервер, обновляем PHP, получаем 40% прироста производительности и все круто. Далее настраиваем Opcache, тюним его. Opcache, кстати, тюнится так же, как и APC, скриптом, который можно найти в репозитории у Расмуса Лердорфа и который показывает хиты и мисы, где хиты — это сколько раз PHP пошел в кэш, а мисы — сколько раз он пошел в файловую систему доставать файлики. Если прогнать весь сайт, либо запустить туда какой-то краулер по ссылкам, либо вручную потыкать, то у нас будет статистика по этим хитам и мисам. Если хитов 100%, а мисов — 0%, значит, все нормально, а если есть мисы, то надо выделить больше памяти, чтобы весь наш код влез в Opcache. Это частая ошибка, которую допускают — вроде Opcache есть, но что-то не работает…

Еще часто начинают масштабировать, но не смотрят, вообще, из-за чего все работает медленно. Чаще всего лезем в базу, смотрим — индексов нет, ставим индексы — все сразу залетало, еще на 2 года хватит, красота!

Ну, еще надо включить кэш, заменить apache на nginx и php-fpm, чтобы сэкономить память. Будет все классно.

Все перечисленное достаточно просто и дает вам время. Время на то, что когда-то этого станет мало, и к этому уже сейчас надо готовиться.

Как, вообще, понять, в чем проблема? Либо у вас уже настал highload, а это не обязательно какое-то бешеное число запросов и т.д., это, когда у вас проект не справляется с нагрузкой, и тривиальными способами это уже не решается. Надо расти либо вширь, либо вверх. Надо что-то делать и, скорее всего, на это мало времени, что-то надо придумывать.

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

Что может показать мониторинг? Мы можем упереться в диск, т.е. в файловую систему, в память, в процессор, в сеть… И может быть такое, что, вроде бы, все более-менее, но какие-то ошибки валятся. Все это разрешается по-разному. Можно проблему, допустим, с диском решить добавлением нового диска в тот же сервер, а можно поставить второй сервер, который будет заниматься только файлами.

На что нужно обращать внимание прямо сейчас при мониторинге? Это:

1. доступность, т.е. жив сервер, вообще, или нет;
2. нехватка ресурсов диска, процессора и т.д.;
3. ошибки.

Как это все мониторить?

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

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

Старьё! - скажите вы.
- Вечные ценности! - ответим мы.

highload junior

Добавить метки

Сегодня мы научимся пользоваться этой полезной конструкцией языка c++.

Очень часто в процессе написания программы требуется писать длинные if-else конструкции, например, когда мы получаем какой-либо ключ от пользователя; если вы пишете игру, то придется проверять на какую кнопку нажал игрок (вправо, влево, пробел и т.д.).

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

Конструкция switch-case — это удобная замена длинной if-else конструкции, которая сравнивает переменную с несколькими константными значениями, например int или char.

Синтаксис

switch (<переменная>) { case значение1: Выполнить если <переменная> == значение1 break; case значение2: Выполнить если <переменная> == значение2 break; ... default: выполнить, если ни один вариант не подошел break; }

Переменная в скобках сравнивается со значениями, описанными после ключевого слова case. После двоеточия находится код, который будет выполнен в случае если переменная оказалась равной текущему значению. break необходим для того, чтобы прервать выполнение switch. Рассмотрим пример, где нет break:

Int a=1; switch(a) { case 1: a++; case 2: a++; case 3: a++; } cout<<"a= "<

Данная программа выведет a = 4.

Значения для сравнения, описанные после case могут быть только константами, поэтому следующий вариант использования switch-case — неверен:

Int a = 10; int b = 10; int c = 20; switch (a) { case b: // Code break; case c: // Code break; default: // Code break; }

При попытке скомпилировать данную программу, вы получите подобное сообщение:

Test.cpp:9: error: "b" cannot appear in a constant-expression

Блок default — необязателен, но он полезен для обработки исключительных ситуации.

Следующая программа демонстрирует один из возможных вариантов использования switch-case:

#include using namespace std; void playgame() { cout << "Play game called"; } void loadgame() { cout << "Load game called"; } void playmultiplayer() { cout << "Play multiplayer game called"; } int main() { int input; cout<<"1. Play game\n"; cout<<"2. Load game\n"; cout<<"3. Play multiplayer\n"; cout<<"4. Exit\n"; cout<<"Selection: "; cin>> input; switch (input) { case 1: playgame(); break; case 2: loadgame(); break; case 3: playmultiplayer(); break; case 4: cout<<"Thank you for playing!\n"; break; default: cout<<"Error, bad input, quitting\n"; break; } cin.get(); }

Эта программа показывает простой способ обработки вводимых пользователем данных.

Минус данной программы в том, что она дает только одну попытку, без права на ошибку 🙂 . Это легко исправить, заключив весь блок switch-case в . Но может возникнуть вопрос: внутри switch-case есть break, не прервет ли он выполнение цикла? Нет, break прервет только выполнение блока switch.

Сравнение switch-case с if-else

Если у вас возникают проблемы с пониманием того, как работает switch-case, посмотрите на следующую if-else конструкцию, она работает точно так же, как и switch

If (1 == input) { playgame(); } else if (2 == input) { loadgame(); } else if (3 == input) { playmultiplayer(); } else if (4 == input) { cout << "Thank you for playing!\n"; } else { cout << "Error, bad input, quitting\n"; }

Если мы можем сделать то же самое с помощью if-else, зачем вообще нужен switch? Главное преимущество этой конструкции в том, что нам понятно, как работает программа: единственная переменная контролирует поведение программы. В случае с if-else, придется внимательно читать каждое условие.

Создаем собственные типы с помощью enumeration

Иногда при написании программ могут понадобится переменные, которые могут принимать только строго определенные значения, которые известны вам заранее. Например, вы можете задать ограниченный набор цветов, которые пользователь может выбрать. Очень удобно иметь сразу и набор доступных констант и тип переменной, который связан с этим набором. Более того, подобные переменные хорошо подходят для использования в switch-case, так как вы знаете все возможные значения заранее.

Тип enum (сокращение от «enumerated type «, ) содержит перечисление различных значений, например цветов радуги:

Enum RainbowColor { RC_RED, RC_ORANGE, RC_YELLOW, RC_GREEN, RC_BLUE, RC_INDIGO, RC_VIOLET };

Несколько важных моментов:

• Для объявление перечисляемого типа используйте ключевое слово enum .
• Имя нового типа вы задаете сами, например RainbowColor.
• Все возможные значения для данного типа перечислены в фигурных скобках.
• После объявления перечисления необходима точка с запятой.

Теперь вы можете объявлять переменные с типом RainbowColor:

RainbowColor chosen_color = RC_RED;

И, как уже говорилось, эти переменные хорошо подходят для использования в switch:

Switch (chosen_color) { case RC_RED: /* paint screen red */ case RC_ORANGE: /* paint screen orange */ case RC_YELLOW: /* paint screen yellow */ case RC_GREEN: /* paint screen green */ case RC_BLUE: /* paint screen blue */ case RC_INDIGO: /* paint screen indigo */ case RC_VIOLET: /* paint screen violet */ default: /* обработка исключений */ }

Так как мы используем перечисления, мы можем быть уверенными, что рассмотрели все возможные значения переменной. Значения констант в перечислении — это простой int, по умолчанию каждое следующее значение больше предыдущего на 1. Для первого — 0, для второго — 1 и т.д. В нашем случае: RC_RED = 0 и RC_ORANGE = 1.

Вы также можете задать собственные значения:

Enum RainbowColor { RC_RED = 1, RC_ORANGE = 3, RC_YELLOW = 5, RC_GREEN = 7, RC_BLUE = 9, RC_INDIGO = 11, RC_VIOLET = 13 };

Преимущество использования перечисляемых типов в том, что вы можете задать имя значениям, которые иначе пришлось бы хард-кодить. Например, если вы пишете игру крестики-нолики, вам нужен способ представления крестиков и ноликов на доске. Это может быть 0 для пустой клетки, 1 для нолика и 2 для крестика. Значит, наверняка придется использовать подобный код:

If (board_position == 1) { /* do something */ }

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

Enum TicTacToeSquare { TTTS_BLANK, TTTS_O, TTTS_X }; if (board_position == TTTS_O) { /* some code */ }

Теперь все гораздо понятнее 🙂 .

На этом всё! Подписывайтесь и не пропустите новые уроки! 🙂

Часто вместо нескольких расположенных подряд операторов if else целесообразно воспользоваться специальной конструкцией switch-case . Оператор switch сравнивает значение условного выражения с несколькими значениями. Как правило, в качестве выражения используется переменная, в зависимости от значения которой должен быть исполнен тот или иной блок кода. Для сравнения в switch используется оператор равенства (==).

Представим себе переменную $action , которая может иметь значения "JUMP" (прыгать), "SWEEM" (плавать), "FLY" (летать). Оператор switch позволяет легко определить блок кода, который должен исполняться для каждого из этих значений. Чтобы показать разницу между операторами if и switch , выполним проверку переменной на соответствие нескольким значениям. Следующий пример показывает два различных способа сделать то же самое. Первый способ использует серию операторов if и elseif , а второй - оператор switch:

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

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

case

Обратите внимание, что за ключевым словом case каждый раз следует значение (литерал), после которого должно обязательно стоять двоеточие. Тип значения, указанного после оператора case , должен совпадать с типом значения возвращаемого условием. Перед началом исполнения тела (содержимое между фигурными скобками) оператора switch , переменная указанная в скобках, должна быть инициализирована каким-нибудь значением, поскольку это значение будет сравниваться со значениями, указанными после case. Инструкции, расположенные после case , будут исполняться до тех пор, пока не встретится оператор break .

Примечание: в операторе case может быть использовано любое выражение, которое приводится к простому типу, то есть к числу (integer), вещественному числу (float), строке (string) или логическому значению (bool).

break

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

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

"; } ?>

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

Обратите внимание на этот пример: список инструкций для выполнения в секции case может быть пустым, в этом случае управление просто передается далее по списку - следующему оператору case .

continue

Обратите внимание: оператор continue применяется в конструкциях switch и действует подобно оператору break .

Выбор по умолчанию

Если значение условного выражения не совпало ни с одним из предложенных значений в секциях case, оператор switch позволяет выполнить некоторые действия по умолчанию. Для этого используется ключевое слово default . Работает оно следующим образом: если значение возвращаемое условием не совпало ни с одним из предложенных значений в секциях case, оператор switch начинает выполнение инструкций расположенных в секции default .

"; case "SWEEM": echo "Я люблю плавать.
"; case "FLY": echo "Хотел бы я научиться летать.
"; default: echo "Что-то мне вообще лень, что-либо делать."; } ?>

Оператор default обычно указывается в конце тела switch , после всех меток (case). Это логичное и обычное место для него, но на самом деле, оператор default может быть расположен в любом месте внутри конструкции switch . Так как блок кода расположенный в секции default обычно является последним в теле switch , ключевое слово break чаще всего опускают.

Дополнительные сведения

Возможно у вас возник вопрос когда же лучше использовать оператор switch , если тоже самое можно сделать используя оператор if else ? Ответить на этот вопрос можно так: в операторе switch выражение вычисляется всего один раз и этот результат сравнивается с каждым значением оператора case. В условных выражениях elseif , значение выражения вычисляется каждый раз заново. Если ваше условие более сложное, чем простое сравнение и/или находится к примеру в цикле, в этом случае конструкция switch может работать быстрее, чем elseif .

На последок хотелось бы упомянуть о том, что вместо двоеточия после операторов case и default , можно использовать точку с запятой: