Scaling для сайта TYPO3

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

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

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

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

Любая идея?

источник

2012-01-31 user_ja

Это слишком сложный вопрос, чтобы дать вам ценный ответ. Тем не менее, я бы сначала сосредоточился на оптимизации производительности веб-сайта TYPO3, и если бы этого было недостаточно, ТОГДА я бы сосредоточился на системной стороне проблемы. Итак, google для «TYPO3 performance». 3 ключевых слова могут помочь вам сосредоточиться на правильном материале: ** eAccelerator **, ** статический кеш-файл **, ** memcached **. – tmt

Не используйте eAccelerator, вместо этого используйте xCache или APC. Статический файловый кеш объясняется ниже. Не используйте memcached как кеширование, а APC или Redis (зависимо от вашей настройки PHP). – StephenKing

@StephenKing: eaccelerator - это кэш php, а не кэш базы данных. Он должен использовать xCache или APC дополнительно, а также memcached и Redis. – Bytemain

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

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

источник

2012-01-31 13:09:30 halfer

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

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

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

источник

2012-01-31 14:01:14 StephenKing

BTW: Ваш клиент действительно ожидает 1000 одновременных посетителей, или он только воображает, что может быть так много? ;-) – StephenKing

Нет, я действительно не думаю, что это будет так много, но это основа для контракта ;-) –

Необходимость прокси-сервера еще не доказана, на мой взгляд, но хорошая информация, поэтому +1. – halfer

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

источник

2012-01-31 14:57:17 Bytemain

Жаль, плохой ответ ИМХО. Не пытайтесь tweek операционной системы. Начните с хорошей настройки приложения (TYPO3 + PHP). – StephenKing

@ StephenKing: Вы должны научиться читать. У меня нет средств для настройки системы, но это обычная практика в Linux, так почему бы и нет, если у вас есть средства? – Bytemain

Он просит решение для веб-приложения. Почему вы ожидаете, что он будет компилировать серверное программное обеспечение? Возможно, он использует управляемый сервер, общий хостинг или имеет системного администратора, который может это сделать. Он может испортить всю производительность из-за плохой конфигурации TYPO3, но он не может исправить это оптимизированными двоичными файлами или ramdisk. – StephenKing

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

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

Nginx/Лак для передней/балансировки нагрузки
Apache HTTP Server
MySQL может быть на отдельном сервере, можно было бы подразделить

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

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

источник

2012-01-31 20:56:31

Почему не nginx или lighttpd? Апач сложный и зверь. И почему выделенный сервер? Протяженность километров намного дешевле? – Bytemain

Apache немного тяжелый, да, но он имеет очень хорошую функциональную основу и может быть настроен, чтобы избежать перегрузок. Можно использовать nginx, да. Что это за «кмс», извините? –

Это опечатка. Я имею в виду KVM, см. Здесь http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine. У вас может быть больше контроля над гостем. Вы можете изменить, например, параметры ядра и скомпилировать ядро. – Bytemain

Scaling для сайта TYPO3

ответ

Смежные вопросы