Build to Scale: our Web Architecture
July 2nd, 2007 GeekeryHi, I’m Scott Miller, Chief Architect at Thoof. For the geeks out there, I wanted to write a short post about some of the software level decisions we made while developing Thoof. We think this stuff is interesting, so why not share it?
When we set out to design Thoof’s software architecture, we wanted to create a flexible platform for the website. Not just for delivering pages, but for implementing complex functionality quickly and easily, and with performance in mind.
Using the open source Wicket web frame work got us a lot of the way there. It allowed us to modularize components of the site, and gets a lot of the basic plumbing of logic and presentation out of the way. Next, we needed a way to keep the site fast and responsive, independent of some of the more complex processing that underlies Thoof. To do this, we added an asynchronous events system.
The events system gives us two major things. First, the ability to decouple action from reaction. This allows each component of the site to be concerned only with its inputs (dependencies) and its outputs, and keep other components blissfully ignorant of who needs its results or who is providing its inputs. In short, it cuts down on spaghetti code.
Second, events allow us to decouple the need for processing from the processing itself. Much of what goes on in a typical request to Thoof matters a great deal, but not to the request that’s occurring Right Now. By firing an event which is processed by a threaded background engine, we can race on through what actually needs to be done during the request. Even better, it means that if something is slowing down the system, its not slowing down page generation, just other background tasks.
Controlling the performance of our complex database tasks led to another decision, to use the iBatis SQL abstraction layer. Unlike typical ORM frameworks like Hibernate, or even more “hands off” systems like those employed by Rails, iBatis lets us write the SQL queries. This is more work on the front end, but gives us much greater flexibility in the long run. If a query is performing slowly, we can edit the SQL ourselves, trying different ways of ‘phrasing’ the SQL to govern performance, without affecting the DAO pattern based model objects in the application itself. It also lets us take heavy advantage of PostgreSQL views and stored procedures, so that we can not only tweak SQL, we can often do it in the database instantaneously, without having to redeploy the application.
How well does it work? We’d be remiss if we didn’t benchmark it. Under our worst case, a series of page views which we know stress both the web application logic and the database, we were able to push about 50 requests/sec from each web node. Even better, that value didn’t seem to change as concurrency varied during the test from 20 to 200 concurrent requests.
12 Responses to “Build to Scale: our Web Architecture
Martijn Dashorst
Nice overview. What would be interesting is to see what hardware you are running the cluster on, and session sizes for users.
John Carnell
Just in case you wern’t aware your mail server hasnt sent me a sign up email yet tried 2 addresses one live.com one my private still waiting.
In the spirit of helping you out so i can post stories :-)
Love the site by the way and the concept behind it. Digg is getting Dull
A Wicket Diary» Blog Archive » Thoof uncovered: Build to scale
[…] Miller, Thoof.com’s Chief Architect writes about the architecture powering Thoof, and the open source products they use. Of course Wicket is one of the products they […]
Jeremy Kraybill
Thanks for the overview. I’d be curious if you could expand how you handle collection management via iBATIS. I agree with the strengths you mention, and have found iBATIS to be especially great for mapping read-only models to whacked legacy data models. However, I could never figure out how to get the level of flexibility that Hibernate has for managing both lazy-loading and smart re-persistence of collections. Do you end up having a relatively shallow model, and managing assocation and dirtying logic in custom DAO code?
And are you not using Spring to tie all this together?
Scott
We use iBatis’s handling of collections for the most part, except in one or two areas where we wanted custom sets and iBatis couldn’t deliver them.
Repersistence we do handle on our own, with a change recording abstraction which allows us to cascade changes to the database when the containing model is updated (Jon Locke’s invention). We do have a fairly shallow model, but only due to the relative simplicity of the data in the application. The complex relationships are all handled completely database side, and we expose only whats needed in the app. This makes it much easier to implement features in general, and helps with performance.
As for Spring, we didn’t see the advantage in our particular case. We’re sort of minimalist. We use frameworks only as we need them, and otherwise shoot for straight Java. In our case Spring was just more configuration with little benefit.
links for 2007-09-25 « Object neo = neo Object
[…] Thoof Blog » Blog Archive » Build to Scale: our Web Architecture Thoof ’s chief architect on scability. (tags: wicket architecture thoof) […]
Michael Swierczek
Scott,
Hibernate lets you specify custom SQL queries at every single step in your application. The default behavior is to let Hibernate generate all of the SQL, but you can put your own explicitly defined queries wherever you like.
I’ve never used iBatis, so I can’t compare it to Hibernate otherwise.
Thanks for the overview otherwise. We have a large (at least by our standards) Struts 1.x/Hibernate app, and while the Hibernate side is reasonably well assembled and not too painful to modify, the Struts 1.x is getting increasingly full of spaghetti code, so we’re looking for a replacement.
Leave a Reply