The Java Guy
-
This interview with Jarod Jenson from the ACMQueue is fascinating. He used to be a system administrator at Enron prior to their collapse and has since moved on to his own consulting firm. He's a Java guy, so I'll warn you, and this is long, 9 good pages, but if you are interested in performance profiling and tuning, it's very interesting.I'm not really a Java guy and when he talks about "memmove(3) or memcpy(3)", I'm barely following. When he gets to "using the plockstat(1M) command", I'm completely lost, but I understand the ideas he's going over and while it's nothing new, the detail and level to which he examines things is refreshing to see. Rarely do I see someone dive in this deep when troubleshooting an application. Perhaps because .NET doesn't have a tool like DTrace, but most likely because no one thinks of doing it. And if .NET doesn't have something like this, Microsoft needs to get to work on it.
I had the chance once to work with a Microsoft performance specialist. He came down to JD Edwards and spent a couple days going over how he looks for issues with SQL Server. I was kind of expecting some amazing advice, but it came down to some good Profiler techniques more than anything and then pushing back for code rewrites where possible.
That's well and good when you are working with a custom application, although the powers that be don't want to hear something like that. They'll be more interested in what you can tune right now. With third party applications, however, that usually leaves you buying more hardware.
Read the article; this one I highly recommend. One last very interesting development idea was when they deployed EnronOnline 1.0. Before it was complete, they pulled people off to start 2.0, working from scratch, but with what they'd learned from v1 and feedback. Now that is an interesting development idea if you can afford to take a chance.
Steve Jones
-
This is one of the most brilliant conversations to which I've been exposed. Thanks for including it. I've never written a line of Java code but this guy's attitude is just awesome and what he said is totally applicable to what all of us do.
-
Thanks Carlos, I thought it was great as well.
Apparently not many others have time for a 9 page interview
, maybe they'll read it this weekend. -
I just wanted to thank you for bringing this up. Although I'm not much of a Java person, I am an ACM member and a fan of Queue, so it brings me great excitement to see its name out there.
-
Alright , I read it, I get it.
"He's sorry."
At nine pages its long... but it makes sense, sort of.
It seems it takes just as long to apologise for using JAVA as it does to develop in it.
They were probably stuck with a bunch of Solaris servers, paid through the nose, sold by a flashy sales man with the key words "UNIX, SUN, JAVA, industry standard."
My experience with SUN is that its the Solaris UNIX is for those wearing mittens. I've used some of their 4G tools its very VB 4/5 / its close to Lotus notes in its style. There are better compiled versions of UNIX out there, but with a few score of kinds, I really dont have time to keep up. I've never engineered that giant of n-teir app for 10's of thousands of concurrent users connecting to a mainframe for parsing huge math queires, but at the time maybe that was the only choice. Mind you it doesnt sound like they did either....
In contrast we have today, robust clusterable SQL SERVER 2k/2k5,and then if theres an issue for mainframe access... there's that bridge over to the mainframe server product MS has out.
You got asp, jsp, aspx and good old IIS to do some of the preprocessing. You probably could run the math calculations as SP's or forumla's, then optimise, get out the old calc uni books, re run..etc.... check sqlservercentral.com and the jedi council, get the run times down.. then go have a smoke.....
Also now the vendors for the hardware products are a little more variable. Cheap to have a dev box up and running just to compare issues.
But java is always built on the premise that speeds will increase but never built with the entire functionality built right from the get go. Its not what it does right away thats the problem its all the extra stuff and fundimental limitations of how many interations of the browser one can have running that kills it.
Anyway, thats my two sense.
If you want to talk programming mem handing techniques,, versis who is better.. I need more coffee...
PS: He also forgot the KISS techinque... and I tend to prefer the spagetti method.....
-
PS: Whatever build an web app I generally build to handle up to 1000 users concurrently at a useful level with slow down at a pretty flat curve toward an upward maximum of 10k. I figure if more than 1000 users are using it !!!at one time!!! you'd be surprised how low that number can be gien many customers claims of googles of hits and users ... there will be plenty of revenue to cluster, then it maxes out My guess would be 50k users. Which would probably topple an OC3.
A realistic comparision might be an exchange 2k3 box for access times with web development. Throwing a little extra weight in for SSL. I've done some tests with the gmail accounts versis an exchange 2k3 accounts and found the exchange to be much more robust and a little more forgiving when you start to approach the 300-600 meg range for accessing the webmail versis equivilant amounts on gmail, and exchange definately wins hands down in the 650- 900 meg size accounts versis gmail.
If you want to get fussy, your packet sizes are really the issue if you make your app files a full "k's" you will get better use versis wasted bits in the packets, but that requires more abstract programming thought. And to me probably too fussy.
Damn i'm running out of pennies...
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply