|
Thinking BIG
|
|
 Joomla is a lot easier than many of the other CMS systems. It was this ease of use and the power which originally attracted us to this platform, and convinced us to concentrate on Joomla. We have not regretted our decision.
One of the immediately intuitive features of Joomla are the 2 separate views of the site - the front end view which is your website, and the backend view which is your administration interface. Personally I like this separation, it makes sense to me. The frontend is where your content lives. The backend is where you control the way that your site works. I find the mixed homogeneous interface (like you see in Wordpress and Drupal) to be confusing.
If you have a small Joomla site, then you might have one or two people who are adept at front and back end. They control the content and tune the CSS, and load new components too. That's fine, for small sites.
But larger Joomla sites will probably have a number of content writers, authors, contributors. And there will be systems admin too, who keep the site running. These are two very separate roles and with Joomla you have a separate interface for both of them.
Great ... up to a point.
Because there is a problem. The Joomla native tools for front end editing are not enough for complete content management. Oh sure, you can create new articles and edit existing ones - but its a bit clumsy, and nowhere near as easy as it is in the back end. That's why we created a suite of plugins and components to make front end content management a reality, and the preferred alternative.
Over the years we have honed our add-ons and tested them on huge Joomla sites with hundreds of editors. We have a clear idea and simple model of how large sites work. The backend is exclusively for systems admin and everything to do with content, and who can see it, is driven from the front. We call it, driving from the front.
Just like the bobsled driver in the image, we imagine the content editors are the ones looking forward - and they can never spare the time to look down!
|
|
Thinking BIG
|
|
 If your are planning to get BIG, then one natural consideration is making sure that you are hosted on a big server. We thought the same, but then when we worked through the issues (over a number of years) we have have come to different conclusion.
You need to make sure that you are hosted on a good server, and you need to make sure that you have an upgrade path if things get really busy. But your main website is not the biggest issue. The LAMP (Linux, Apache, MySQL, PHP) is very efficient and it can handle a lot of traffic very well. But we have found that there are three types of web traffic that cause issues - video, statistics and email.
Video is heavy on bandwidth and storage. On site statistics (for live business intelligence) are heavy on MySQL tables and cause huge spikes on processors. Newsletters and email can also cause traffic spikes, but will probably cause all kinds of other errors and be ineffective as a delivery mechanism unless your delivery model is carefully planned.
Our solution was not to keep investing in a bigger and bigger central server, or server cluster, but to segment the processing and send specialists tasks to specialised resources. The next three articles investigate how.
|
|
|
Thinking BIG
|
|
 Our experience has taught us not to treat all web content equally and not to continually add bigger and bigger servers. Instead we have separated some content and give it special attention. In this way our overall server infrastucture is flexible and capable and cost effective.
First up was video. The reasons are obvious. This page (when completely written) will take about 2 minutes to read. On a disk it will be less than 5k of data and the complete webpage will be less than 100k. However, if the same text was recorded as an MP3 audio file it would be about 2MB in size, or 20 times larger. If it was a video it would probably be a 10MB MP4 - that's 100 times larger than the original web page. So video content is at least 100 times larger than the original text (as a rule of thumb), and that extra size causes many problems. Firstly it fills your disks quicker, but disk prices are small. More importantly, your webserver has to deliver at least 100 time more information to each and every user - that's the same as suddenly getting 100 times as many users.
It does not matter whether you use shared hosting or dedicated servers, you will have bandwidth limits and video will rapidly eat bandwidth. To compound difficulties, video is streamed to users. Video streams need to constantly chatter and sync with your webserver and if the stream is interrupted the video will degrade, stutter and stall. Delivered across the globe even the fastest networks will take valuable milliseconds which are imperceptible for web pages, but noticeable as juddering in video.
All in all video is not a good content set to be delivered from your standard web server. We have found that for a large or even modest website a proper video (Content Delivery Network) CDN is absolutely essential. CDN services offer masses of extra storage, bandwidth, high speed delivery, and multiple points of presence (ie: they replicate copies of your video across lots of locations around the globe for even faster service). There are hundreds of CDN services available but we usually use Amazon, as its fast, reliable, and low cost.
So that's great we have video 'in the cloud', it's fast, low cost and effective. The problem is, how do we actually get the video there and link it back to a Joomla article? [Remember - to us, a video is a piece of content, and content is to be loaded by editors who 'drive from the front' end of Joomla and have no desire or need to know how anything works.]
|
|
Read more...
|
|
Thinking BIG
|
|
 There are lots of web site statistics packages, the best known is Google Analytics. It's good, it's easy to integrate and it's free. But site statistics have a failing, they are usually measuring the activities of anonymous users. In Joomla terms, those users who are not logged in.
For many sites anonymous users are the norm. But many big sites rely on logged in users. They want to know about the total traffic and the overall volumes, but they also want to know about the actions of individual users. Recording some of this data is possible with Google Analytics, and other off site stats services, but it's not that successful and relies upon large amounts of data being sent over the web each time a user moves across your site.
Your standard Joomla install will already record much about what is happening across your site and it's easy to add more to your database. Every component and many plugins record what they are doing. There are also on-site stats components, many based on the long standing (though largely abandoned) component called Joomlastats which records your site stats. Recording the data this way is secure and reliable, and with a decent knowledge of MySQL it's very flexible as all your data is to hand.
We use our own Smart Tracker Plugin to record all activity across our sites, by all users, using any site features. It even records 'in page' navigation to tell us where a user went within a large page .
However local data storage like this has a problem. Because even if you only recorded details of each page impression from a busy site with 100,000 pages served per month, you will have a data table of over 1 million lines before the first year is over. Every time you want to generate a historic report you might have to select, group and sort that data multiple times. It will become a bigger and bigger processing job and could take a while to run. You won't be able to create results 'on the fly', and you may find that your live stats are killing your site's performance.
Our solution is to throw hardware at it. But not by making the main server bigger. We simply added separate servers for statistics. Each night we back the live site stats to the Stats server and we link all live report requests to the Stats server. Our server boys tell me that the (memory, cache, timeouts, etc...) configuration we have evolved for the Stats server is totally different from the main web server even though the hardware is virtually identical. The reason is they have different tasks to perform.
Of course by running the reports from a day old archive the results do not reflect 'live' activity. But this is true for Google Analytics too and is not a problem for them. Plus - if we need to have a truly 'live' report we still can link a report to the live database. Our live site is therefore unaffected by the majority of reports, and even if a huge report is run it has no impact on the live site.
And so, we have a solution that will allow us to run reports without killing our live site. But what reports? And how do we write them and how do these become the really impressive graphical dashboards that our clients want to see?
|
|
Read more...
|
|
When you build a website you want it all to be seen by everybody, right? Well, no. Not always.