T3Sites

From TYPO3Wiki

Official TYPO3 websites

Facts on Load

Hosting requirements for typo3.org / typo3.com

- reverse proxy
- 2 webservers, fast processors, Zend platform, RAID 1 or 5
- 1 MySQL server, 4GB RAM, RAID 1
- servers connected via Gigabit
- one of the webservers contains replicated MySQL as emergency fallback
- webservers share the same filebase (via fileserver) ???
- traffic per month?
- _____________

- Image Magick V ___ , GD ___, ______________
- root shell account for site maintainer(s)
- statistics
- monitoring of all services (if possible, also hardware) from a server outside the datacenter by nagios or similar
- full backups, at least _____ levels plus MySQL dump
- _____________

[Who wrote the following paragraphs? --Robert 09:53, 15 Mar 2005 (CET)]

IMHO it's a bit early to throw in performance figures for a particular machine.
(4GB RAM, RAID something, ...)

Let's get the general design straight and then decide on "how big".

Foremost, a _scalable_ solution is called for. Scalable meaning not one or
two machines, but N for any reasonable number of N. For the major task
of content delivery to end users it must be possible to double the systems
capacity by simply doubling the amount of servers in use. This should scale
linearly up to at least a couple of dozen machines.
Reason: no one can foresee the future growth. At least my crystal ball is
at the shop for a major inspection, currently ;-)

TYPO3's architecture poses one major problem to simple straightforward
database clustering: TYPO3 uses filesystem storage in addition to the back end
database. From a computer science point of view, this is bad bad bad
design ;-) No insult intended - in practice, of course, it isn't. Despite of what
Larry Ellison tries to sell the world, throwing everything into a database eliminating
file systems altogether doesn't scale very well.

For these reasons we came up with a "one writer, multiple readers" model,
meaning, write/editor access to the site in question will still be channeled
through a single system guaranteeing consistency. Content delivery to end
users will be done by N delivery servers being able to scale linearly.

As long as readers by far outnumber editors this system will last quite long.
And it implicitly answers the question, which parts of the entire TYPO3
site to host separately - any part that is accessed for editing often enough
to justify a dedicated editor server. These numbers can easily be measured
by monitoring system load and doing proper logfile analysis using a suitable
tool. Unfortunately as it seems we don't have the readers/writers ratio of
the current site?
For the delivery part of the concept IMHO all parts should be handled by the
same single cluster, thus spreading the load evenly and putting all the machines
to work.

To summarize:

- clustered "new" architecture for high bandwidth TYPO3 sites
- constant measurements of servers health, load, traffic
   up to date status via web interface, monthly report
- advanced logfile analysis showing the main contributors to increasing
   server load - we can react _before_ the load hits the roof
- hosting location with good interconnection to major backbone providers,
   measurements of site's response time from multiple locations "outside"
   of our own hosting location - monthly reports and evaluation of hosting
   location's quality
- hosting provider with guaranteed SLA's, meaning round trip times to
   major "outsode" locations as well as availability of staff and reaction
   within a defined time in case of hardware/network failures

Open questions in our concept:

- separate application layer firewall?
- commercial grade load balancing system instead of DNS round robin?
   this would implicitely implement an application layer firewall!