Technology - The Gathering 2003

  PartyTicket.Net >> The Gathering >> The Gathering 2003 >> Information

Information

General terms and conditions

About us

Blackmarketing

Privacy policy

About PTN cards

Security

Technology ]

Services

Mail problems

This is just a small description of the technology that we use here at PTN, mainly for fun, if this is of no interest for you feel free to skip this page.

Starting at your end, the useragent (aka the webbrowser) and working towards the hardware on our side of the Net the gritty details are:

Useragent

We support any webbrowser that supports HTML 4 and CSS 2.

With HTML 4 it's pretty easy to keep within the limits of what works everywhere, as just about any browser made in the last 6 years understands HTML 4.

CSS 2 is another matter, not many browsers implement all of CSS2, the three best are Opera, Konqueror and Mozilla, but that doesn't matter as much as CSS is only about look 'n feel, not function, and features that browsers don't understand are simply ignored.

We use very little graphics on the site and as much of it as possible is in png, png images are usually smaller and faster than gif, all relavant browsers support it.

We use absolutely no JavaScript at all, in fact all clientside scripting is wrong and should never be done, by anyone, not even for fun.

Bottom line of browser support is that we support using any browser at all, even Lynx (a unix text mode browser), we develop the site on Linux using Mozilla as the browser because it is fast and has better CSS2 support than most browsers out there and because we have based the output on standards, not the quirks (aka features) of one product we can get away with not testing on 19 different browsers and still claim that the site works perfectly on every browser on the planet, except the ones that are too broken for any use.

If this site has any functional defect as a result of us using a feature that your browser doesn't support, then please send us a bugreport to tell us what browser you are using and what fails.

Webserver

The program your webbrowser talks to at our end is a webserver, our webserver is Apache, it's no coincidence, because it is both reasonably fast, very flexible and the most widely used webserver, running over 60 % of the active websites in the world, it is also Free software which means that we have much more freedom than if we had used a resticted piece of software.

We have a Squid in front of Apache, that helps performance, not by caching the pages (it can't it's all dynamic), but by taking care of the long, boring task of sending content over the Net to the clients, without the Squid an Apache process has to wait for the client to suck all the content before it can process another request, this leads to wasted memory as well as colder cache.

Perl

Inside our Apache we have Perl, it provides a reasonably fast (as in: it's not the bottleneck) scripting language that is compiled when Apache starts and then executed several times.

There are faster languages out there, but there is no language as flexible or with as many freely available modules as perl has.

Apache::Vulcan

In the old days we used HTML::Mason as an application framework for the system, it took care of finding the right code to execute when Apache got a request, via extensive profiling we found out that the Mason framework was way too slow and it used way too much memory to be practical in the long run.

We looked around for a good alternative, but we couldn't find anything that was just right so in stead of wasting any more time with other peoples bug-heaps we simply wrote our own.

Apache::Vulcan is a very perl- and unix-near framework that exploits Perls builtin features and the fact that we know that there is only one request running pr. process at any one time, so we have simply done without a lot of the complexity that other frameworks seem to be so fond of.

The new framework is fast, so fast that the framework is no longer the bottleneck of the system like in the old days and the time it takes to process a request is down to 20-40% of what it was and it is much more predictable with much less memory usage (aroun 5%).

HTML::SmartTemplate

Apache::Vulcan is only part of the story, because it only takes care of making it easy to write perl code that handles requests, but it doesn't make it easy to generate pages, this is the job for a templating system, we benchmarked a few existing modules like CGI::FastTemplate and Template Toolkit but found that both performance and flexibility was lacking, so we wrote our own.

HTML::SmartTemplate is a brand new templating system that has the same flexibility as template toolkit (both use perl for flow control) and is 40% faster than CGI::FastTemplate, stores a collection of templates in one file and makes it safe to have non-programmers fiddle with the template.

Zepo::NG

Our own part of the system Zepo::NG is the end result of yet another re-write of a system that started out back in 1996, to do voting for parties, in its time the system has gone from being DOS/Windows based, over being web/NT/IIS based to finally be web/Linux/Apache based.

The last rewrite, done during 2001, had the purpose of cleaning up the code to use a consistant API towards the database and to make supporting many parties at the same time easy.

There are over 38400 lines of code in the application part of the system, but most complexity is in the modules that take up over 132776 lines of perl.

The majority of the library code is in the Object Oriented database wrapper, ZDB, which is about 121820 lines of generated code, this leaves 10956 lines of handwritten module code.

The ZDB module is generated by a 3100 line utility called squealer which takes about 13895 lines of API code (near-native perl) and generates all the Database creation code, API classes and documentation for the API, because everything is generated from the same source it is always in perfect sync.

DBMS

Over the years we have used many different databases: Interbase, MSSQL, Sybase, Postgresql, Interbase (again), all of them with their own limitations, but today we use two databases, SAP DB and MySQL, both are Free software.

The important data is stored in the SAP DB database, this is a very full featured and very scalable database that the good people at SAP has released under GPL, it takes advantage of multible CPUs, can manage a large number of disks and can be backed up while it's online, it supports all the features that all real database have, like transactions and foreignkey constraints.
The best proof that SAP DB scales is that it can be used as the backend for SAP R/3, which has 2 GB of data and over 16000 tables in an "empty" database.

The temporary data is stored in the MySQL database, this is because MySQL is quite fast at its limited feature set, the reason we don't use it for all the data is that it doesn't help preserve data integrity the same way other databases do, so with MySQL you can easily get your data corrupted.

OS

We use Linux for everything, it's easier to use than anything else we have tried, we use a mix of SuSE and Red Hat, both are nice distributions and has about the same feature set (like flexible, 100% reliability and fast).

Hardware

The current machine is a standard box with two P3 755 MHz CPUs, 1 GB RAM and 2 mirrored 15GB SCSI disks on a RAID controller, not very spectacular hardware, but with proper tuning it will quite happily handle our load.

  - Contact / SupportSite map - This site is implemented and run by CoreTicket