Для начала, некоторые поразительные показатели проекта Ebay.com:
- Более 89 миллионов активных пользователей
- 190 миллионов товаров в 50 тыс. категорий
- Более 8 миллиардов URL запросов в день
- Большая динамика развития — сотни новых функциональных улучшений каждые 3 месяца
- 39 стран, 9 языков, 24 часа в сутки, 7 дней в неделю, круглый год
- 70 миллиардов операций чтения/записи в день
- Обработка 50 Тб данных в день
- Анализ 50 Пб данных каждый день
Дальше — 10 основных правил масштабирования от Ebay + презентация
Вам наверняка приходилось сталкиваться с проблеммой медленной работы сайта.
Причину того мы обычно ищем в PHP и MySQL, но зачастую забываем о том,
что из себя представляет страница, которая попадает в браузер пользователя. Помимо HTML есть еще и Javascript, CSS, множество картинок, флеш объекты и прочее.
Время загрузки страницы зачастую занимает лишь несколько процентов от времени загрузки всех компонент этой страницы. Существует ряд практик и подходов, которые помогают оптимизировать загрузку страницы в браузер в разы (все зависит от ситуации, но это может быть и 10 раз).
Несколько подробных статей на эту тему:
*
Оптимизация клиентской части*
Как ускорить работу сайта для посетителя*
Скорость имеет значениеСтоит добавить еще несколько вещей1. Стоит помещать Javascript файлы в конец HTML и использовать только внешние методы для регистрации событий (не использовать атрибутов, типа «onclick» и т.п.). Это поможет избежать ошибок в тех случаях, когда Javascript еще не загружен, а пользователь уже пытается выполнить какое-то действие
2. Стоит заранее сжимать статику gzip-ом, а в отдающем сервере просто отдавать необходимые заголовки. В этом может помочь
этот модуль nginx'a3. Изолируйте отдачу на разные сервера (например, динамику и статику отдавайте с разных серверов) — поможет изолировать проблемы с нагрузками
Зачем мы используем реляционные СУБД, поддерживающие SQL синтаксис? Хранить данные, инкапсулировать работу с данными, делать хитромудрые выборки, сортировки и т.д. Насколько часто Вы (или Ваши разработчики) анализируете определенную задачу на предмет того, какую технологию хранения данных применять? Угадаю — почти никогда. Выбор обычно делается в начале проекта (MySQL, Postgres и т.д.), а потом этот выбор является условием «по умлочанию» для любого рода технических задач, требующих постоянное хранилище.
Интересное аппаратное решение для
memcached, на которое я наткнулся читая highscalability.com.
Как заявляют производители этой железяки, она позволяет вставить в 5...10 раз больше оперативной памяти в обычный юнит (ракспейса), чем стандартный сервер. Что, по их словам, достигается новой гибридной архитектурой устройства подсистемы памяти.
Интрефейс этого аппаратного решения поддерживает протокол memcached, поэтому Вам не придется прилагать дополнительных усилий для интеграции этого решения в Вашу рабочую среду.
Интересно услышать Ваши мнения, т.к. вертикальное масштабирование — это хорошо, но ведь не бесконечно.
Их официальный сайт
