Думаю, уважаемому сообществу будет интересно узнать о моем опыте разработки интернет-проекта с использованием веб-сервисов Amazon. Я не берусь утверждать, что весь проект идеален, но попытаюсь описать основные решения, которые помогли реализовать этот проект. Wikipedia.org, вдохновивший нас на работу, обслуживает 12 миллиардов страниц в месяц, поэтому мы с самого начала постарались подготовить код к растущей популярности.
Что такое wikipaintings.org - www.wikipaintings.org/ru/О программе Сейчас завершается первый этап разработки и основные задачи следующего этапа — привлечение волонтеров для наполнения сайта.
Если кто-то считает картины скучными, посмотрите работы Арчимбольдо — www.wikipaintings.org/ru/giuseppe-arcimboldo/spring-1573#supersized-artistPaintings-184903 Если вам интересно наконец разобраться в классификации стилей живописи, добро пожаловать на www.wikipaintings.org/ru/paintings-by-style Ну а теперь, после того как вы установили сайт с Hubbraeffect (если вы еще этого не сделали, отправьте ссылку всем своим друзьям), перейдем к главному — техническим советам.
Технологическая платформа
Этот проект был выполнен с использованием ASP.NET MVC, LINQ2SQL, MS SQL Server 2008 R2 и JQuery. Ни для кого не секрет, что AWS больше ориентирован на разработчиков JAVA/PHP, но я не чувствовал себя обделенным.Предлагаю к рассмотрению свои советы разработчикам в порядке традиционных слоев веб-приложений.
База данных
Мы начали с централизованной базы данных бизнес-объектов — по нашим оценкам, достаточно мощный инстанс способен обработать необходимое количество типовых запросов клиентов в ближайшем будущем (на данный момент это High Cpu Medium Instance).Для наиболее популярных HTTP-запросов мы позаботились о том, чтобы выполнялся ровно 1 SQL-запрос, который возвращает все необходимые данные — именно базу данных в этом сценарии сложнее всего масштабировать.
Важно сказать решительное «нет» хранению файлов в базе данных.
Несмотря на расширенные возможности SQL Server 2008, это неправильный путь.
EC2 расшифровывается как Elastic Computing Cloud не случайно: ваш сервер — это, прежде всего, просто процессор, и его основная цель — выполнять вычисления, а не хранить.
Изначально пользовательских файлов будет слишком много, чтобы поместиться на каком-либо диске — поэтому их место в S3 — бесконечном и очень надежном файловом хранилище.
Вначале он может показаться медленным, но его скорость не меняется; С ним будет работать 1 ваш процесс или 1000. Кэшируйте результаты сложных запросов на уровне базы данных.
У нас есть все возможные поиски картин и художников, инкапсулированные в одну хранимую процедуру.
Все его параметры мы записываем в виде ключа кэширования, и когда другой пользователь кликает по тому же тегу или стилю, у нас уже есть подготовленный список идентификаторов подходящих объектов в базе данных.
Это также позволяет мгновенно возвращать результат при использовании пейджинга.
Упакуйте подчиненные объекты вместе с главным.
Например, изображение хранится как сериализованный XML в строке «Картина» и тот же XML в строке «Художник».
Да, это не очень красиво, но каждый подзапрос занимает не менее 0,0005 секунды, а когда вы рисуете все картины на странице, это время нужно умножить на 200. Статья «Раскрытие скрытых данных для оптимизации производительности приложений» также очень полезна.
http://msdn.microsoft.com/ru-ru/magazine/cc135978.aspx — Еженедельно проверяю правильность индексов (уверен, что у многих это уже есть в закладках)
C#/средний уровень
Следите за временем рендеринга страниц и каждой основной операцией.Недавно появился профилировщик из stackoverflow , а вообще что-то попроще можно быстро сделать самому.
В BeginRequest — инициализация, EndRequest — проверяем, не рендерилась ли страница более N секунд. Если отрендерилось больше, пишем запись в журнал ошибок.
Разместите в приложении код, регистрирующий затраченное время, когда вам нужно понять, сколько времени занимает каждый шаг.
Не помешало бы такой лог отобразить в конце мастер-страницы в виде html-комментария, чтобы наглядно увидеть эффект от настройки производительности.
Сделайте методы контроллера «произвольными действиями» — это намного проще, чем изучать селен или что-то подобное, и позволит вам протестировать скорость различных функций приложения с помощью простых тестов, таких как loadimpact. Будьте осторожны с вложенными циклами.
На первый взгляд безобидный цикл рисования, который на каждом шаге проходит по массиву с помощью Where(), занимает десятую долю секунды.
Тот же цикл, перед которым мы конвертируем массив в Словарь, совершается за сотую долю секунды.
Возвращаться несколько таблиц от одного SP даже если вы используете Linq2sql, это возможно и работает хорошо.
Я оцениваю накладные расходы на выборку элементарного объекта с помощью PK в 0,005 секунды; Если такая операция происходит циклично, экономия возрастает многократно.
Например, хранимая процедура возвращает не только картину, но и художника, нарисовавшего ее.
Чтение данных пакетами, а не по одной записи за раз.
Так работает отображение результатов поиска картин.
Получив список картин на C#, мы формируем список идентификаторов художников и читаем их одним подзапросом в словарь, а затем присваиваем прочитанные объекты соответствующим картинам.
Не используйте собственный компонентный подход ASP.NET для макета страницы.
При этом предполагается минимум параметров для каждого компонента, что на практике приводит к тому, что каждый компонент читает пользователя, проверяет его права и читает его приватные настройки.
Создайте системный контекст, действующий ровно на время выполнения запроса, где вся необходимая информация собирается по мере необходимости и считывается ровно один раз.
Не полагайтесь на выходной кэш.
Это круто, быстро и этим стоит пользоваться — снизит нагрузку на сервер, но это не панацея.
Например, на 18 мая 2010 года было 19К просмотров страниц, из них 8500 РАЗНЫХ (по данным Google Analytics).
Кроме того, каждый процесс имеет свой выходной кэш, а это значит, что затраты памяти будут пропорциональны количеству объектов в системе, умноженному на количество серверов.
Для главных страниц, у которых нет параметров, продолжительность кэширования может быть довольно большой (15 минут), а для редких страниц мы устанавливаем 30 секунд в случае публикации этой ссылки на Hubbra. С другой стороны, ajax-запросы хорошо кэшируются — у них не так много параметров, они часто повторяются, а их результат обычно меньше, чем у HTML-страницы.
Перенесите сложные части в отдельные проекты.
Типичный облачный сервер достаточно слаб, но их может быть несколько.
Например, мы вынесли генерацию миниатюр в отдельный веб-сервис, что дало возможность разместить его на другом сервере и улучшить скорость загрузки картинок при импорте.
Отложите то, что не можете сделать сейчас — Amazon предоставляет отличный, быстрый, бесконечный и дешевый (наша стоимость этого сервиса менее 10 центов в месяц) инструмент для работы с очередью (см.
Исходный код №2).
Используйте общую память.
Например, на странице картины ( http://www.wikipaintings.org/ru/giuseppe-arcimboldo/portrait-of-eve-1578 ) показываем другие картины этого художника, одинаковые на разных страницах.
Сохранив в памяти минимально необходимую краткую информацию о картинах каждого художника, мы сократили время генерации этой страницы в 2,5 раза.
Можно, конечно, использовать Velocity, но для нас проблемой стало отсутствие поддержки Windows 7, на которой мы разрабатываем.
Мы написали собственную службу Windows, с которой веб-приложения взаимодействуют посредством удаленного взаимодействия.
По сути, это примерное повторение System.Web.Caching.Cache, но поддерживает один и тот же набор данных для всех экземпляров.
Клиентская часть
Проверьте результат с помощью различных инструментов — таких утилит, как YSlow, Скорость страницы Firebug — ваши лучшие друзья.Мы переносим все, что можем, в Cloudfront. Очевидно — картинки, миниатюры, но туда же пишем CSS, собранный в 2 файла — один обычный, 1 — gzip. Важно именно расширение .
gzip, поскольку Safari не понимает .
gz. Этот прием продемонстрирован в примере кода №1. Назначить срок действия — S3 не делает этого по умолчанию (см.
пример кода № 1).
Вы сэкономите время пользователя и деньги на трафике.
Для этой работы и управления статическими файлами на s3 я вообще рекомендую морошку.
Важным нюансом для увеличения скорости загрузки страниц стало распределение запросов по разным поддоменам.
Протокол http не допускает одновременного выполнения более двух запросов к одному серверу; Хотя браузеры делают до 5 запросов, загрузка страницы со 100+ изображениями заняла более 10 секунд. Мы распределили изображения по поддоменам и теперь при наличии хорошего канала одна и та же страница загружается до 8 раз быстрее.
Для этого создайте набор доменов в Cloudfront (у нас есть uploads0, uploads1,.
uploads8) и псевдослучайным образом выберите тот, который вам нужен.
Еще лучше для этого зарегистрировать отдельный домен, чтобы куки не передавались при каждом запросе, но мы посчитали это паранойей.
Не загружайте больше информации, чем необходимо для отображения страницы — все остальное можно загрузить позже с помощью ajax. Чем быстрее загружается страница, тем выше лояльность пользователя.
Главное сделать красивую и адекватную анимацию при загрузке данных.
Рекомендации по развертыванию
Мы используем один экземпляр централизованно для базы данных и набор микроэкземпляров, которые отображают страницы под контролем балансировки нагрузки ( См.статью о настройке Windows Server 2008 R2 Core.
.Сама балансировка нагрузки очень проста в использовании — для работы с ней имеется графический интерфейс.
Целесообразно предоставить страницу состояния системы, которую Amazon будет проверять с интервалом от 6 до 60 секунд (установлено).
В случае двух (или более) отрицательных результатов (таймаут или код ошибки) экземпляр объявляется «неработоспособным» и запросы переходят к другим серверам.
После восстановления работоспособности он возвращается к работе.
1 балансировка нагрузки предоставляется бесплатно в течение первого года.
Резервная копия базы данных ежедневно создается на отдельный диск EBS. Что бы ни случилось с хост-системой или самой Windows, с помощью панели управления вы можете отключить этот диск от одного виртуального сервера, подключить его к новому, поднять бэкап и продолжить работу.
В качестве дальнейшего шага по повышению устойчивости системы к аварийным ситуациям вы можете автоматически создать снимок этого диска.
Процесс развития
Процесс разработки также сыграл важную роль.Мы не рассчитывали на фиксированную стоимость этапа проекта, просто каждую неделю выпускали новую, стабильно работающую версию (хотя, надо признать, бывали задержки).
В ходе итерации вся команда сосредоточилась на 3-4 основных задачах, над которыми мы продолжали работать, пока не остались довольны.
После запуска очередной версии реальная жизнь и реальные пользователи часто вносили коррективы, и 1-2 функции шли на очередную доработку.
Ужасен ли этот процесс с точки зрения планирования? однако он работает гораздо лучше, чем стандартный аутсорсинг, где на каждую задачу заранее выделяется определенное количество времени с точки зрения результата.
Это также отлично влияет на мотивацию, как с точки зрения того, что нет второсортных задач, так и поддерживает постоянный рефакторинг, чтобы в будущем было комфортно вносить изменения.
Пусть клиент признается себе, что важнее не сроки и бюджет построения черт знает чего, а продукт, который не попадет в мусорное ведро, и тогда, возможно, вы сможете работать с agile-подходом.
выводы
В целом, несмотря на, казалось бы, слабые серверы и высокие цены, Amazon зарекомендовал себя как надежная платформа, помогающая строить проекты, готовые к «светлому будущему», и другим клиентам я обязательно порекомендую использовать облачные подходы.Если вы готовы немного поработать, то всегда можно найти возможность сэкономить и довести затраты на хостинг практически до уровня стоимости обычного сервера.
Полезные ссылки
1. Работаем с С3
2. Работаем с СКС.
3. Настройка Windows Server 2008 R2 Core для Micro Intsance
4. SQL Server — раскрытие скрытых данных для оптимизации производительности приложений
5. Мини-профилировщик для веб-приложений из stackoverflow
Теги: #разработка веб-сайтов #облачные вычисления #Amazon Web Services #Amazon EC2 #масштабирование #разработка веб-сайтов
-
21 Факт О Блоггерстве От Коперника
19 Oct, 24 -
Планирование Разработки По: Делюсь Опытом
19 Oct, 24 -
Блоги! Недорого! Не Стесняйся.
19 Oct, 24