Масштабирование для сайта TYPO3 - PullRequest
2 голосов
/ 31 января 2012

Клиент попросил меня предоставить веб-сайт на основе TYPO3 со следующими параметрами: - небольшое количество контента (около 50 страниц) - очень маленькая частота изменений - средняя доступность около 95% / день - 20% страниц ограничено, доступно только после входа в систему - Нет требований для модных расширений typo3 или чего-то еще (только ядро ​​Typo3) - страницы среднего размера - Включены только ограниченные цифровые активы (изображения и т. Д.)

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

Как может выглядеть инфраструктура?

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

Есть идеи?

Ответы [ 4 ]

2 голосов
/ 01 февраля 2012

Вполне возможно, уже сделали что-то подобное.Вам нужен как минимум один выделенный сервер с> = 8 ГБ ОЗУ.

Если мы говорим об инфраструктуре, минимальная комбинация:

  • nginx / Varnish для балансировки фронта / нагрузки
  • HTTP-сервер Apache
  • MySQL может находиться на автономном сервере, может быть кластеризован

В таких случаях очень важна оптимизация производительности.

Некоторые ссылкидля дальнейшего чтения:

2 голосов
/ 31 января 2012

Более простое решение - EXT: nc_staticfilecache .Это сохраняет статические страницы как HTML, и ваш веб-сервер автоматически доставляет их по правилам перезаписи (в случае Apache через mod_rewrite).Это очень хорошо работает для статического контента и уже должно позволять вам делать> 100req / s.

Еще более изощренный способ - использовать Varnish Cache .Varnish - это обратный прокси-сервер, который хранит содержимое вашего веб-сайта в памяти и может работать на выделенном хосте.Если вы настроите его правильно (отправьте правильные заголовки кеша!), Он обеспечит вам скорость линии (несколько миллионов запросов в секунду).Существует также расширение TYPO3 moc_varnish , которое, например, очищает кэш лака при изменении страницы в TYPO3.Также существует поддержка включений на стороне ребра, например, для извлечения только пользовательских данных из TYPO3 и использования статических частей страницы из кэша лака (все, кроме " Добро пожаловать пользователя Foo Bar " ..;)).

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

0 голосов
/ 31 января 2012

Я бы посмотрел на виртуальный сервер или ksm и хорошую конфигурацию mysql и php.Когда у меня есть ksm, я бы настроил Linux и использовал iptables для формирования трафика.Выделенный корневой сервер был бы хорош, но это дорого.Тогда я подумал бы об использовании веб-сервера nginx или lighttpd с eaccellerator и memcache.Если это не поможет, я попытаюсь скомпилировать php и mysql с флагами оптимизации или я попытаюсь скомпилировать его с помощью компилятора Intel C.ICC может оптимизировать код на C лучше, чем gcc.Если на сервере много оперативной памяти, я бы использовал ramdisk.

0 голосов
/ 31 января 2012

Я бы разместил это на одном выделенном сервере (или хорошо указанном VPS), но, возможно, сохранил все статические ресурсы на CDN стороннего производителя, чтобы вы могли сосредоточиться на динамических вещах.Я не знаю Typo3, но не вижу причин, по которым вы не можете разместить свою БД на одном сервере для этого уровня использования - наверняка будут варианты кэширования различных типов.Или, возможно, рассмотрим облачный сервер, поэтому, если вам нужно больше возможностей, просто добавьте больше ресурсов.

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

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