Масштабирование для сайта TYPO3

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

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

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

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

Есть идеи?


php infrastructure apache content-management-system typo3
person user_ja    schedule 31.01.2012    source источник
comment
Это слишком сложная тема, чтобы дать вам ценный ответ. Тем не менее, я бы сначала сосредоточился на оптимизации производительности веб-сайта TYPO3, а если бы этого было недостаточно, ТОГДА я бы сосредоточился на системной стороне проблемы. Так что погуглите производительность TYPO3. 3 ключевых слова могут помочь вам сосредоточиться на нужных вещах: eAccelerator, кэш статических файлов, memcached.   -  person tmt    schedule 31.01.2012
comment
Не используйте eAccelerator, вместо этого используйте xCache или APC. Кэш статических файлов описан ниже. Не используйте memcached в качестве бэкенда кэширования, а вместо этого используйте APC или Redis (в зависимости от вашей настройки PHP).   -  person StephenKing    schedule 31.01.2012
comment
@StephenKing: eaccelerator - это кеш php, а не кеш базы данных. Он должен дополнительно использовать xCache или APC, а также memcached и Redis.   -  person Gigamegs    schedule 31.01.2012
comment
Я знаю, что такое eAccelerator. Он больше не поддерживается и легко вызывает проблемы, если он скомпилирован с неправильными параметрами (и комментарии PHPdoc удалены). Поэтому используйте (xCache||APC) в качестве кеша байт-кода плюс (APC||redis) в качестве бэкенда кэширования. Memcached как кэширующий сервер вызывает проблемы, если вам не хватает места. См. wiki.typo3.org/Caching_framework.   -  person StephenKing    schedule 31.01.2012

Ответы (4)


arrow_upward
2
arrow_downward

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

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

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

person StephenKing    schedule 31.01.2012
comment
Кстати: Ваш клиент действительно ожидает 1000 одновременных посетителей, или он только воображает, что их может быть так много? ;-) - person StephenKing; 31.01.2012
comment
Нет, не думаю, что столько будет, но это основа договора ;-) - person user_ja; 31.01.2012
comment
На мой взгляд, необходимость прокси еще не доказана, но это хорошая информация, так что +1. - person halfer; 31.01.2012

arrow_upward
2
arrow_downward

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

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

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

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

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

person Fedir RYKHTIK    schedule 31.01.2012
comment
Почему не nginx или lighttpd? Apache сложный и зверь. И зачем выделенный сервер? км намного дешевле? - person Gigamegs; 01.02.2012
comment
Apache тяжеловат, да, но у него очень хорошая функциональная база и его можно настроить, чтобы избежать перегрузок. nginx можно использовать, да. Сколько км, простите? - person Fedir RYKHTIK; 01.02.2012
comment
Это опечатка. Я имею в виду KVM, см. здесь en.wikipedia.org/wiki/Kernel-based_Virtual_Machine. Вы можете иметь больше контроля над гостем. Вы можете изменить, например, параметры ядра и скомпилировать ядро. - person Gigamegs; 01.02.2012
comment
Если Вам нужна такая персонализация ядра, то почему бы и нет. Но использование виртуализации может увеличить производительность. - person Fedir RYKHTIK; 01.02.2012

arrow_upward
0
arrow_downward

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

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

person halfer    schedule 31.01.2012

arrow_upward
0
arrow_downward

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

person Gigamegs    schedule 31.01.2012
comment
Извините, плохой ответ ИМХО. Не пытайтесь настроить операционную систему. Начните с хорошей настройки самого приложения (TYPO3 + PHP). - person StephenKing; 31.01.2012
comment
@StephenKing: Тебе следует научиться читать. У меня нет средств для настройки системы, но это обычное дело в Linux, так почему бы и нет, если у вас есть средства? - person Gigamegs; 31.01.2012
comment
Он просит решение для веб-приложения. Почему вы ожидаете, что он будет компилировать серверное программное обеспечение? Возможно, он использует управляемый сервер, виртуальный хостинг или у него есть системный администратор, который может это сделать. Он может испортить всю производительность из-за плохой конфигурации TYPO3, но он не может исправить это с помощью оптимизированных двоичных файлов или виртуального диска. - person StephenKing; 31.01.2012
comment
@StephenKing: я исправил свой ответ и удалил прокси. - person Gigamegs; 01.02.2012