New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Alexander Olaru on Dec 06, 2007
Beware of these frameworks if your app requires high performance. Prototype, jQuery fall over terribly when using large tables and grids.Another commenter pointed out that Mootools has a page benchmarking Protoype, JQuery & Mootools.
I’ve done extensive benchmarking for my current project at work which is very AJAX heavy and will use at it’s core large tables.
I’ve experimented with both jQuery and Prototype and the performance was always lacking. The problem? document.getElementById(). DOM lookup is VERY expensive. In fact, our tests seem to suggest that DOM lookup is not done via hashing.
A lot of these frameworks add extensions that many times you will not need, slowing performance down. Our solution has been to study what is beind done and write our own code, minus all the extensions and any extraneous framework support it is doing.
But for small webpages without large tables, Prototype or jQuery work very well and are nice to work with.
Mobile and the New Two-Tiered Web Architecture
18 agile and lean practices for effective software development governance
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
This is great stuff - but why only Javascript. This would seem to apply to all things...especially open-source.
beren
It's an interesting list, but it seems to leave out one of the single most important evaluation criteria: whether the framework leans toward unobtrusive or obtrusive JavaScript.
For instance, ExtJS tends to be highly obtrusive, but suitable for some people who don't mind coding lots of their interface in JavaScript rather than HTML.
On the other hand, jQuery and Prototype, and their UI plugins, tend toward unobtrusiveness. Or at least you have more of an option on how obtrusive you'd like to be.
This is not to point out those frameworks, but rather the glaring omission from the article above.
?? He gives a bunch of generic criteria, most of which _do_ apply when selecting any type of framework. The he doesn't really give any answers, other than "Prototype and JQuery can be slow." So I guess that means Dojo, YUI, ExtJS and MooTools are faster?? We don't know because the whole thing was kind of lacked detail. Other than where he wrote that they re-wrote the framework with just the parts they needed. That doesn't really seem like framework selection to me. That sounds more like "roll your own JS framework."
We can use the part of the jQuery function.
If Prototype & jQuery aren't suited for Ajax heavy applications, then what should we use?
@ Hussein: you could take a look at Dojo, Tibco and Backbase. Those are some of the more comprehensive Ajax frameworks.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
6 comments
Watch Thread Reply