Should A High-Profile Media Website Abandon Java? 156
"It is all hugely expensive to license and to run, and it's not very scalable. We'd like to up our userbase from several tens of thousands to ten times that number - but the cost of scaling the Java/Solaris infrastructure is not trivial, because the Java servlet architecture costs too much in memory and execution time (creating several 100Ks of in memory objects for each logon is expensive stuff!). On current hardware we can support only 1200-1500 concurrent logins and scaling up requires a new app server (eg 1 processor + 1GB RAM) and a $20K software license for each additional 600-750 concurrent logged in users. And in today's 'cost per active subscriber' economics it doesn't add up - we cannot justify the present cost structure, by any rational measure, even before we try to scale it up.
So we're thinking of chucking it out and replacing it with a largely static site that is generated (written out to cache) from a new, simpler content management system. The few dynamic elements would be assembled using simple PHP scripts, frontending our existing Oracle DB server. We reckon we could serve vastly higher numbers, ten to a hundred times as many, of users on the same (or cheaper!) hardware: and it would be simpler by far to build and maintain and support.
I, personally, believe that the benefits of the Java system (rapid prototyping, development) are not important when large scale deployment is the issue. I am (as a user) fed up with large, poorly performing Java-based websites. My beef is not about Java the language though - it's a question of appropriateness. Fifteen years ago we'd prototype in Smalltalk and then code for deployment in C, and I feel the same applies here. The economics of the noughties do NOT support spending massive amounts of money on web infrastructure, unless the transactional revenue justifies it. Of course, most businesses generally don't justify it, in my opinion.
Our outsourcing partner who supports and maintains the architecture thinks we are crazy. Putting their potential loss of revenue aside they are hugely concerned that we'll not be able to support what we create. They are seriously against this idea.
I remember, prior to Java & the like, supporting simple CGI websites with tens & hundreds of thousands of users off of cheap FreeBSD systems, and we didn't have to pay an outsourced partner to do it.
So what does Slashdot think? What would you do if you, were in the same boat?"
Your problem is architecture (Score:5, Interesting)
With all the above being said, I don't know what is wrong with your system, but it isn't that hard to build a dynamic site in Java that meets your scabilitiy needs. All you need is a good caching strategy and you are set. Generally speaking, a good caching strategy coupled with a dynamic site can lead to as good as or better peformance than a static site.
Re:Your problem is architecture (Score:3, Interesting)
A J2EE or even a lighter java servlet based solution may not be the best for your needs but it sounds like to me your "big, custom" content management system is at least somewhat bloated.
Unless your system is very highly customizable by your users you should have all sorts of opportunities for caching and optimizations geared towards scaleability.
It's not the same but the webmail for UF [ufl.edu] scales to 2,000-3,000 concurrent users during peak load with only one gig of ram. Unlike a news
Slashdot is a great place to get ideas. (Score:3, Interesting)
From the parent post: "Anyway, slashdot is the wrong place to be looking for serious solutions to problems like yours."
Maybe so, but Slashdot is a great place to get ideas. Many times Slashdot readers have extremely useful comments because they have unique experiences and are willing to share them.
Re:Slashdot is a great place to get ideas. (Score:2)
I agree with second and third parts, but not necessarily the first...
Re:Your problem is architecture (Score:1)
Dude the problem is not Java.. but your application. Yes, dynamic generation of pages can suck under heavy load, there are too many bad applications out there that were not profiled properly, and yes static page generation (ie caching to disk) can be a good way around that.
However, none of this is going to go away just by shifting to PHP. Address the problem, not the politics.
Wrong place man! (Score:4, Insightful)
Sorry dude, but you're going to get many of these:
For your case, I hope I'm wrong. Just out of curiousity, have you considered, I donno, profiling your application, to see where the time's being spent. Also, how about switching to a more cost-effecitve Java platform? I've heard good things about this little thing called Linux.
But, your current solution does work, right? How much exploration have you done in optimizing the application? Oracle can certainly scale, and you're already willing to strip down the site to mostly static pages. Why throw out all that proven and thoroughly tested code? And if you're outsourcer can't do that, maybe its time to switch partners, not platforms. You have a large investment here, there's a good chance you can save most of it.
Python (Score:2, Informative)
When you're done, swap the JVM out of Jython and run pure Python with debugged code. If Python gives you any performance trouble, write small C-based modules for your frequently used code and wrap it in Python (fairly easy to do).
Re:Python (Score:5, Informative)
1. Writing C for web apps is not a solution. The wrapping tools for Python aren't impossible to use, but they can't perform miracles. Yes, it is very easy to use an external C function for performing some repetitive math function, an FFT or something- but in a data-intensive web app, it really makes no sense. In the case of the poster's problem, he and his team would end up re-writing half of the framework their using in C, giving it Python interfaces. If they were having problem with just Java's raw execution speed, they could just as easily use Java's JNI to interface with C libraries.
2. No matter good it looks on paper, going from a big system written in Java for one particular framework to a system written half in Python and half in Java doesn't make all that much sense. They'll be dealing with the same bottlenecks, the same bloat- it's all running on the JVM. If anything else, they'd increase the footprint and slow the app down, as they're adding on yet another layer of complexity.
Yes, I am fully aware that Jython outputs Java bytecode itself, but Sun's Java compiler does a lot better generating efficient Java bytecode out of Java than Jython does. Nothing inherent to Python or Jython, but when you've got a multi-billion dollar project like Java, when you consider what Sun puts into it- then compare that to the miniscule (by comparison) project that is Jython, it'd be absurd to expect the same results.
I know it's easy to get a little jumpy when the dude mentions PHP and your favorite language is Python, or hell, anything that isn't PHP. You want to come in any say "hey, use my favorite language!" Believe me, I'm wanting to do the same thing, and I could substitute the word "Smalltalk" for "Python" throughout your post, and it'd be just as true; unfortunately, so would my points against it.
Python and Jython certainly have their places, no doubt. Depending on a couple factors, I may use Python to write my system intiailly, but simply having a language that spit out Java bytecode doesn't mean you have some non-trivial, seamless transition between two system.
MOD PARENT UP (Score:2)
Re:MOD PARENT UP (Score:1)
MOD THE PARENT DOWN (Score:3, Informative)
I've done it with two projects, one was heavily overbloated with EJB, another one was a typical JSP thing. In both cases I've moved to Python+Zope and it was done pretty quickly and smoothly.
Well, I admit, I've done it without Jython, as I've found there was no need for old/new code temporary integration aside of transparent authentification (which was simple - through LDAP
Re: (Score:2)
Re:Isn't this a question of scalability??? (Score:2)
We talked about Java vs Python and EJB vs Zope here. Tests I've made shoed that on the same hardware (P3-4x500MHz + 2GB RAM) both JSP-no-EJB (Tomcat) and JSP+EJB (Tomcat+JBoss) are actually slower than Python+Zope. Pa
Re:Python (Score:1)
The lack of static typing (inherent in the Python language) will make it slower. Methods will be looked up by name (in string form) instead of by VFT offset.
Re:Python! (Score:1)
The biggest thing standing in the way is the lack of libraries. There are VMs and compilers available but the huge class library takes longer to replicate. The GNU Classpath project [gnu.org] seems to be coming along nicely. I don't think the project will be abandoned any time soon either because lots of other projects depend on it.
Boy you're exposing yourself (Score:1)
One problem I see. Who's the architect of this thing? Is s/he being held responsible for your scalability problems?
Another: Does your vendor/outsource/partner actually know what they're doing? Where are their references recommending them for building a highly scalable site?
The other thing is: tuning tuning tuning.
Re:Boy you're exposing yourself (Score:3, Informative)
Second: profile, profile, profile
Third: well, almost anybody that has used a J2SDK (or JRE) on Solaris knows about its problems. Try to run Volano [volano.com]'s benchmark [volano.com] to know more about this. But like any banchmark, please don't believe your software will perform the same way the benchmark does. It is ju
your problem is architecture not java (Score:3, Interesting)
You should be able to deal with a lot of your scalability issues by putting some kind of cache in front of your system, like Squid [squid-cache.org].
But it sounds like every page on your site is really dynamic. And thus uncachable.oy
But you want to replace it with a mostly static site, so obviously, not all that dynamic stuff is required.
Before you chuck the baby out with the bathwater:
- Can you revise your existing java site to serve most pages as essentially static?
- If so, will putting some cheap squid cache boxes in front of your main servers do the trick?
This technique really works, if you can do it.
Re:your problem is architecture not java (Score:1)
Re:your problem is architecture not java (Score:1)
Caveat Emptor. If the issue is database latency, then caching can improve performance but at the cost of scalability.
Why? Because a simple caching scheme precludes the use of clustering due to the problem of the dirty read.
You can go with a more complex caching scheme that writes dirty objects back to the database but there are problems with this approach. Typically, you either decide that it's okay for the user to see data that isn't always current or you have to implement some kind of "heart beat"
You need to justify your choice of J2EE platform (Score:5, Informative)
I'm afraid your company must seriously consider other J2EE platform, rather than root up your existing architecture.
First of all, fuck SUN. I'm biased, of course, because I'm here to pro-Linux in this case. SUN's J2EE app server is almost the most expensive among their competitors, not to mention the incremental maintenance cost incurred by expensive SUN hardware. Nowaday big corps like IBM and HP offers enterprise support for J2EE on Linux platforms, and their support are M3(24/7) with at least 3 9's maintenance
Also, you don't pay per user for large scale web deployment, you pay per server license. Fuck SUN's sales multiple timesfor not reminding you of better license terms for your new deployment.
I remember, prior to Java & the like, supporting simple CGI websites with tens & hundreds of thousands of users off of cheap FreeBSD systems, and we didn't have to pay an outsourced partner to do it.
You're just going backward in this case. Existance of J2EE platform is to solve various problems with CGI. One of our deployment just switch from CGI to J2EE due to the former behaved unstable when handling high volume requests. Of course, I've been told of many success with CGI, but J2EE seems to fit in in this case.
Besides, I don't understand why you've scale-up problem with J2EE. Scalability is the major advantage of J2EE. In our most current project, we decouple RDBMS(Oracle), Web-Tier(Apache), App-server(9iAS) and EJB containers(OC4J) into 4 seperated Linux cluster pool and one share storage of SCSI raw disks. We could easily scale up our architecture on various requirements.
Re:You need to justify your choice of J2EE platfor (Score:2)
He specifically said it was a non-J2EE proprietary Java app server. My guess is ATG Dynamo (a pre-J2EE version). I doubt Sun's sales had anything to do with recommending it.
Come on (Score:1)
Php, perl, c, etc. Are not the panacea your looking for, good architecture is what you need. Languages have their pluses, but it sounds like you just need a better design.
Should you throw out the baby with the bathwater? (Score:5, Insightful)
Instead, try to improve your current solution an bring its cost down:
Good Luck!
Re:Should you throw out the baby with the bathwate (Score:2)
This is excellent advice (i.e. MOD UP).
It sounds like some areas of the Java solution are giving particular problems, in particular with respect to memory. If this functionality is provided by the application server, you need to look at alternatives (WebSphere, JBoss, etc). If it is provided by your custom-build CMS then profiling and limited refactoring to make use of object pools, etc, should take you a long way.
Most of the cost issues (apparently) relate to the application server and its host syste
Re:Should you throw out the baby with the bathwate (Score:2)
Don't do it (Score:4, Insightful)
Think of the risks that a rewrite introduces:
you break existing business logic with the new implementation
you build a system that is slower than the existing one
you take way too long to finish it, all the while you have to pay your existing licences
Typically, the argument for a rewrite is that the cost of implementing new functional requirements is higher than the cost of just implementing them in a brand new system. Have you tried optimization? How are you maintaining session state? Do you know what it would take to get your app running in a free container? Have you looked at free/cheap caching APIs?
Further, java may not be the out-of-the-box fastest platform, but there is no reason whatever that it can't scale in an environment designed for it. Yes, you may need to have many smaller machines because of jvm memory issues, but that's exactly what you should want. The ideal situation is when you can say, 'if we need to support 10x the current users, we just need to drop in 10x more app servers.' It's called 'scaling linearly.'
is it just me... (Score:1)
/me points finger north. samples wind. (Score:2)
I'm so glad you asked. Given the scant details, this should be great fodder for a Java/PHP/whatever flame war. Seriously, you expect good advice based on that. Having said that, look at some 'real' big sites and see if they use Java: yahoo, google, slashdot, etc.
Re:/me points finger north. samples wind. (Score:1)
Remember don't throw every toy in the toybox into the playpen.
Seems to me that the most useful sites are low in graphics/tech-glitz. Of course, I'm a pop-up blocking, dial up at 28.8 weenie. Your real users may have a different perspective.
Re:/me points finger north. samples wind. (Score:2)
Re:/me points finger north. samples wind. (Score:1)
yes, switch (Score:5, Interesting)
Ditch Solaris and go with Linux or FreeBSD on Intel hardware. Amazon and AOL did it and saved buckets of money, so you should feel confident that you can do it too.
Re:yes, switch (Score:2)
This has come up a million time I imagine. The vast majority of companies will not ditch a huge hardware, software and training investment on a system like Solaris so that they can have the feel-good-vibe of knowing that they are using an open source platform. They couldn't give a rat's ass if Linux is open source or not. Sure, they could install Linu
Re:yes, switch (Score:2)
Re:yes, switch (Score:2)
Is this really the forum for this kind of question (Score:2)
Re:Is this really the forum for this kind of quest (Score:1)
A rewrite probably isn't cost effective (Score:2)
Re:A rewrite probably isn't cost effective (Score:2)
Sometimes a fresh start is the best (Score:1)
Most of the early CMS's built during the boom times they were large, very flexible and complex systems that tried to be all things for all people.
I think products like ATG Dynamo are great but they tend to be very over-engineered for small to medium size sites and maintaining them becomes a nightmare of inter-dependencies. It doesn't mean they won't perform and scale, just that you need very experienced people that k
Don't forget Developer skill sets (Score:4, Insightful)
But I would consider changing the architecture if that makes sense.
Who are you ? (Score:2)
CIO? Sysadmin? Architect ? Project manager? Consultant? Programmer?
Do you make architecture/infrastructure decisions ?
Let me get this straight... (Score:5, Insightful)
Hmmm... somebody should be loosing their job. Either the consultants who built it or the person that approved such a thing.
If you had a true J2EE app that wasn't coded by a team of monkeys on a wild rampage this shouldn't a problem. The "porting" to a new app server should be trivial, if anything has to be done at all. You'd be able to keep the Sun hardware and whatever app server you use on it, while chucking in Linux machines with Bea, WebSphere or maybe JBoss on them. Slap a hardware based load balancer in front of it and viola, horizontal scalability.
I didn't see anybody else take offense to this, but 100k+ per user login memory usage? I might be showing my age, or rather my roots, but that seems excessive. My guess is your app's written like the app I now support. User logs in and everything about them is swallowed up into session (or application) wide collections immediately. The "lazy caching" thing just didn't cross these guy's minds. Of course, in my case neither did the "mark data dirty" thing but that's another matter.
Please, somebody show me 100k worth of data that you would really want on-demand from-memory on a user at any given instant. Just a C struct or something would suffice.
J2EE apps can be bleeding fast ultra lean sons of bitches if you do it up right. It can also be a dog-ass slow memory-hogging bastard. It just depends on who you had at the business end of the whiteboard I guess.
Going the PHP/static generation/caching route isn't neccessarily a bad idea either... but I don't think you should have to do this. I'm seeing the maintence of such a system as a big onus on the system administrators to make sure everything is up all the time... I know of no PHP frameworks out there that would let you drop sessions from one system to another. I've never tried pushing PHP that far though.
If your a system admin such a system might seem ideal... because while the systems and network might be a little "wonky" that's your domain and you feel comfortable supporting such a thing. I can't fault you for that; however I do think the onus is on the application development team. It is their job to make something scalable and construct it in a manner that it should fail over, recover, etc. from anything weird that may go on.
This isn't realistic, but you probably purchased a scalable application toted as portable because it's Java and you didn't get that. Demand that. If they can't deliver boot them out the door and take it inhouse if you must but I see many obstacles in your path on the system admin side alone... and certainly the re-development of it won't be cake walk.
Scalability problems are largely the development team's responsbilities, so long as such a requirement was put forth in the original development. Good system administration can help to reduce their errors along with a good helping of hardware but that's just a bandaid to the real solution.
Just my two cents.
Re:Let me get this straight... (Score:2)
Personally, I'd prefer a cello for this type of application.
Re:Let me get this straight... (Score:1)
DIRK: "but that's a whole nother thing"
FADE
Re:Let me get this straight... (Score:2)
I personally have pushed PHP that far. From my personal experience PHP sessions provide a very clean
Broadvision? (Score:3, Insightful)
Also, anyone who got suckered into a Broadvision sales pitch for a enterprise solution should be shot^H^H^H^H fired on first site.
How about... (Score:1, Flamebait)
It's just so typical for people who don't have a clue about web application development to make stupid claims like:
1) J2EE is for rapid development/prototyping of web apps. - J2EE is far slower than anything else I've used. The advantage of Java is that if you use it properly, it lets you creat
How to reduce cost and scale... from my experience (Score:4, Interesting)
In my experience, Java was not the wisest choice, it was bloated, difficult to maintain (that's one that will rile the pro-Java camp), required too much focus on non-business focus areas (i.e. creating things like session pools and encryption when we should have been focusing on getting the actual business requirements fulfilled), created a object model bureacracy (pure OO with respect to encapsulation? or break the purity of the model because you know in advance that you want 27 objects and you could get them all from one piece of SQL, but this would have presumed knowledge on the internals of the object and thus have broken the rules of encapsulation).
All in all, Java proved to be the most substantial factor in late deliveries of projects, limited scaleability... and expense (you wouldn't run Java on Windows, and we were running it on some very sizeable Sun boxes). We had several major works at performance improvements, memory caching, singletons to persist seldom-modified data, re-working SQL, etc. But this didn't help dig us out of the hole that we were in.
As a comparison, we also ran some Windows boxes with ASP 3 code on it... used prolific file system caching, and because of poor OO support abandoned hope of properly creating encapsulation and objects purely... we did use re-usable components in DLL's, and we did do extensive work to cache page parts in both memory and on disk according to the predicted frequency of use.
Both systems were behind reverse proxy caches... but the Java had the benefit of all pages being cached (as authentication ran in an NSAPI plugin on the proxy), whereas the ASP did not have its pages cached (just the images, styles, etc) as authentication code ran in the pages (it had not moved behind the plugin when I had left the company).
Yet of these... the ASP consistently performed better on page generation times, concurrent users, etc... even though the ASP boxes were just cheap Compaq servers and the Java boxes were very over-specced Sun servers.
My experience of all of this led me to the following conclusions... which were ever obvious but merely got re-inforced.
1) Right tool for the right job. And at the moment that means considering things like PHP, Perl, ASP for web pages... not Java. String manipulation languages and those that are lower overhead are performing better on web sites.
2) If you do use Java, be prepared to dilute the purity of the object model you create to favour performance. DO NOT get caught in the trap that the object model purity is more important than total performance/maintenance... OO purity does not necessarily equate to maintenance increase... documentation and commenting achieves that more.
3) Cache everywhere! Parts of pages, generated pages, the images and styles used on pages, the queries in the database.
4) Control your cache flushing fiercely! Do not allow apps to ever flush anything that you are not sure has to be flushed... wild-card flushing should never occur. If you stay in Java, implement the Observer pattern and persist and serialise data everywhere.
Ultimately it comes down to architecture... but I have witnessed that Java encourages really strange architecture as everyone starts running after a holy grail of a pure object model.
I would generally favour not using Java and going for the re-write. Other languages encourage pure string manipulation and control of what you're doing at a far more approachable level.
Remember that you're only creating web pages:
1) Query database
2) Concat string
3) Echo string
4) ???
5) Profit!
It really isn't hard, and doesn't need rocket science. Look at
go to dot net... (Score:2, Funny)
Update your resume (Score:3, Interesting)
The solution, therefore, is to get away from the proprietary system. But only if you think you can do better. Either find a better proprietary system or write your own. If you write your own then plan for 'scale out' on lots of servers running something cheap like *BSD or Gnu/Linux, Apache, Tomcat, JBOSS, posgres, mysql, etc.
If you _can't_ get away from the proprietary app, then perhaps you can 'wrap' it in something else. Use static pages, PHP/mod_perl/C++/Lisp/jsp/whatever and a cheap but good database (mysql, postgres). Use these for all of the 'custom' content. Then have them access your 'back end' and dumb down the back end to get rid of everything that is not essential to a data feed. If possible aggregate the 'php' users into a few categories for the CMS to deal with. E.g.: have a 'sports' profile with 10,000 php users accessing a single 'sports' user on CMS.
Try negotiating with the vendor. Perhaps you can present your 'success story' at a gartner symposium or somesuch. Complain about scalability. Demand a linux version. Get them to agree to some unlikely performance guarantee and use that to cut costs down (via penalties). Get some free consulting from them to help fix the problems. Make sure to wear a T-Shirt or use a pen from their major competitor whenever they are around -- much more fun that way.
Find a failed
Another approach is to update your resume and get the heck out of there.
Bad Idea! (Score:2)
On the other hand, sometimes it is worthwhile to just chuck out the whole implementation and start over again. In my case, we're thinking of doing that because we want to implement a bunch of new functionality that really changes the intent of our application. And after 7
Re:Bad Idea! (Score:2)
However, as an IT manager, I rarely find it "sellable" to take an internally-ugly application, replace it with another application of identical functionality, and tell anyone that it's a success.
Wrong approach. You're not 'replacing' the app with an identical app, you're doing a 'major performance upgrade' to the app (new major version). If that new major version happens to share no lines of code in common with the previous version, so be it :-)
As for replacing the hardware, I agree, there's no good r
Profile profile profile (Score:3, Interesting)
If you have 100s of K per login it almost certainly isn't the platforms fault, and it probably isn't the developer's fault either - all that memory must be going to customize content for the user, which means you can trace the performance problems back to the requirements. (your developers could be crap too, but profiling will tell you!)
If the user gets content which requires a massive amount of customisation on each and every page - and this a requirement - then performance will suck no matter what the platform, as that memory will still need to be used.
I've been through this before with a customer who demanded we try out every app server under the sun to resolve performance problems even though we showed him profiling figures that proved only 1% of the time per request was appserver overhead - 80-85% was in the DB, and the rest was the app code. Because the customer took a "religious viewpoint" that the appserver was wrong rather than believing at the profiling data, we wasted weeks.
You need to profile before you can state that java is the problem - and equally, you need to profile before you can state that it's not.
Re:Profile profile profile (Score:1)
Then throw the user away, that's the faulty component. Or give him fixed, ugly content so he doesn't come back. Oh wait, the user is paying the job...
Not letting folk-wisdom trick you...... (Score:2, Insightful)
This isn't the problem.
(creating several 100Ks of in memory objects for each logon
This is.
So what does Slashdot think? What would you do if you, were in the same boat?"
Don't know what /. thinks, but I think you need a serius rethink of your application's design. It sounds to me like you're throwing away exactly the advantage that servlets can give you by creat
If it ain't broke (& has any measure o complex (Score:3, Informative)
The article speaks for itself, but essentially Joel's point is, "If it ain't broke, it's going to take you a heck of a lot longer to rewrite something inferior than you could've ever expected." Old code has tons of lessons learned that you'll never tease out. New code is easy to read and can implement every buzz word you'll find on O'Reilly Net right now, but it won't be battle-tested.
If you're still able to even think about throwing out your old investment and moving to CGI and BSD, however, I'm thinking your site isn't doing much very fancy. If you don't have much customization invested in your propriatary system, what Joel and I are saying is moot, especially at the licensing fees you're mentioning.
I'd also point out the title is very misleading. It's not Java that's the issue -- it's your system's architecture. Java is just as capable as creating a, "largely static site that is generated (written out to cache) from a new, simpler content management system," as language X. This is quite similar to the discussion we had about whether Java is an SUV [slashdot.org] just a while back (if it is an SUV, btw, that's not a bad thing [blogspot.com]). Your programmers' skillset is what's most important. If they already have a familiarity with Java, why ditch it?
So, keeping true to the post that says the recommendations here come out our arse, here's another pulled from the same place:
I'd recommend trying to refactor [extremeprogramming.org] your current codebase to do two things. First, try to implement your static page idea using your current system. Two, take out as much of the crappy, non-scalable system that happens to be written in Java as possible. You don't name the system, but the whole advantage of Java is that it doesn't need to be platform-specific (if done right). Ditch Solaris. Create a server-farm of cheap x86 hardware with Linux or BSD with a JVM installed. Reread your license -- if you have thirty "clients" (new Linux servers) making static pages from one legacy server's dynamic content, can you pay a lower fee?
PS -- Who said Java was good for prototyping? Visual Basic (and vbscript/ASP or *gulp* ColdFusion), sure. REALbasic, sure. Java? Are you folks mad?!!
Drop Java (Score:1)
This is just not possible.
Whatever you Java-gurus would say, it won't scale, it won't run as fast as it could.
Yes, perhaps development time is somewhat shorter in java, but if you want to tweak your app to run 0.75 as fast as a properly developed C++ solution, you would spend 5 times as much time profiling and looking for bottlenecks, when, in fact, the bottleneck is the java architecture itself.
In fact, the be
Re:Drop Java (Score:1)
Re:Well Said: "Today's programmers are lazy." (Score:2)
If this guy & his colleagues lack the talent to even hire skilled outsourcers to develop an application for them, whether they use C, Java, or the C-Shell to implement matters little.
Not really enoght information. (Score:2)
2. Does the programming staff know PHP?
3. Could you easily change your site to be static pages?
You might have a lot of solutions available. Have you looked at JBOSS? it is a much lower cost java app server. You could do JBOSS on Linux and save a bundle comparied to Solaris.
PHP is a good a good solution to a lot of problems but it is not what I would choose to generate static pages. Perl or Python are the classic choices but you could get wild and use Java, Lisp, or even OCaml. You
Simple - Dynamic Cache! (Score:1)
Don't step down (Score:3, Informative)
See Ace's Hardware articles on how they converted from PHP to Java/Servlets/JSP, it is a blow-by-blow walkthrough that reads like a HOW-TO:
Building a Better Webserver in the 21st Century [aceshardware.com]
SPECmine - A Case Study on Optimization [aceshardware.com]
Scaling Server Performance [aceshardware.com]
Free OS, Free App Server, Free DB (Score:1)
Your problem is that you contracted this out to a company that grew up during the dot com haze and they gave you a dot com CMS. Now they're more than happy to manage and maintain the beast.
If you weren't using proprietary Java APIs (from BEA, ATG, Broadvision, etc.) you could get the same system running on inexpensive Intel-based machines with Linux or FreeBSD, Apache, JBOSS or JonAS (I can't believe nobody mentioned it yet) or even straight Tomcat with a Postgres DB on the back-end. All free/open source
How often do changes occur? (Score:2)
My suggestion would be to build a proxy/caching server and specifically set the no-cache directive for dynamic content. If you have dynamic content within most pages that would take a slightly different approach; I would suggest hosting dynamic content on seperate pages on the server and have the proxy server stitch the two together. A proprietary HTML extension (similar to IFRAME) and slight modification of the proxy
Just a couple of points/ideas: (Score:2)
First of all, I never understood why people who were serving up something static like news articles would want to store them in a database, fetching them dynamically with Java. They usually say "to permit searching" but there are other ways to do that (i.e. store some metadata and URLs in the database, and the actual articles in the filesystem). I think most people who write database apps do it becau
Re:Just a couple of points/ideas: (Score:1)
If you manage consultants correctly you can account for their time and this is not an issue. The salaried guys OTOH are impossible to get to do *anything*, their biggest decisions of the day are whether to complain about the coffee, the company, or the weather, especia
Advice from another media business... (Score:2)
My company is a large-market daily-US newspaper, and we are building CMS systems in Zope [zope.org] & Plone [plone.org] (using Python). There may be several advantages to using a scripting language, but a shift from Java to a non-OO scripting language like PHP is likely higher risk for you - Zope (and the Zope Content Management Framwork) may offer a better solution given it has a toolset of components to leverage out-of-the box, and a simple, component-oriented way of developing content management applications with a script
Money (Score:2)
You have already seen the problem, but do not want to acknowledge it. You are on a system that when it scales, costs lots of money.
Several others have suggested refactering/rearchitecting. If you have not done so in a while, you may wish to do just that. You have suggested the idea that Java may be killing you, but then you point out that you use pure java on Solaris. Your real costs is the system with the use of a pure dynamic environment.
If you truely have a significant amount of static or near static
Dump SPARC (Score:1)
problem is design, architecture, Suns, not Java (Score:1)
Java is definately on the right track...try IBM (Score:2)
Java seems to have the most hooks to the really cool database functions necessary for enterprise web. This isn't MySql land anymore. You absolutely need persistance and triggers and a DB that takes care of itself. Right now that's a terrible hack in PHP t
You should re-architect for sure (Score:2)
I have personally been in this position - I managed a development team which had inherited a large piece of web architecture (not java !) from a consulting firm just prior to launch (yeah, I should have seen it coming), and it didn't scale. At all. On our big, expensive, 4-processor sun boxen, we could support
Multimedia (Score:1)
this goes into the category of (Score:1)
Don't do PHP! (Score:2)
Something sound awfully skewed in that application. I suspect that your site does the dotcom era idea of "MyNewsite" and stores loads of info on the specific users layout etc. While this is fine and dandy, one does ask oneself why all this is sitting in memory all the time. It sounds
Blah blah blah... (Score:2)
Good programmers can write good/fast/efficient code in ANY language. Crappy programmers write crap/slow/inefficient code in EVERY language.
Interesting (Score:2)
Please post again.
Re:look before you leap (Score:4, Insightful)
Bingo. Right on the Money. You are my hero.
Maintainability is not an asset to consider, it is by far the most important asset (that and a good user interface.)
I sometimes wish all these Python/PHP/Ruby/whatever dudes would learn that strong typing is an ASSET not a problem. Simply because the compiler checks a lot of structural integrity BEFORE the damn thing runs highlighting load of errors right there.
I know the argument that a type system is only in the way and is not really needed when the program is debugged in any case.
But a type system makes a hell of a difference when you (or your poor successor) needs to change anything later because many (if not most) of the conflicts caused by a change are IMMEDIATELY nailed down by the typechecker. This thing is, typeing bugs are bugs. If you send a number to a thing that expects a database connection Python will moan just as much as JAva. the difference is JAva will moan before you run. PYthon and PHP will not.
Don't get me wrong, I write loads of tings in Ruby and Python. Most of them are small things that do a specific task, adminstrative scripts that sort of things. But for large complex systems, don't get me on a non-typed language.
That said, I wish Java would move into a type system that is much more based on type inference, such as HAskell where the language IS stronlgy typed but you pretty much don't have to worry about it since it will infer almost everything. The parts you have to specify are not too much and you get teh best of both worlds. Strong typing as well as non-cluttered code.
Re:look before you leap (Score:3, Informative)
Don't get me wrong, I write loads of tings in Ruby and Python. Most of
Re:look before you leap (Score:1)
I like Python and unit testing as much as the next guy, but unit tests do not make up for what you lose going from static to dynamic typing. Even if you proofread, it's nice to have a spell checker.
Re:look before you leap (Score:2)
However, you are correct in that static typing will remove some expressiveness from your language. Whether the loss of expressiveness is outweighed by the static language support depends on the application. (and also how expressive the rest of the language is).
There are several other approaches out there. Some flavors of Scheme allow you to write optional types for arguments; the compiler will complai
Re:look before you leap (Score:2)
I copy from this thread: http://weblogs.java.net/pub/wlg/373
And I quote:
* weak typing: the language does not detect type errors reliably; examples: C, Perl, Tcl
* strong typing: type errors are detected reliably (whether at runtime or at compile time); examples: Java, Python, Scheme, many others
* static typing: type errors are detected at compile time; examples: C, Java, ML
* dynamic typing: type
Re:look before you leap (Score:2)
To be able to "declare" types is not necessary for having a type system:
attributes of classes would need to have a defined type.
Furthermore, you also have a hierachy of type
Re:look before you leap (Score:2)
Consider this: my_function(a,b) {
No one can tell in advance if my_func("a string", 1); is correct.
As in python the type of a varies from the point where my_func is called.
You can call it with my_func(1,2) or with my_func("a string", "another");
Both is legal and both
What you show is that attributes of classes have_a type. But the type is not defined as it is depending on the assignment, so the reader may crash, where a c
Re:look before you leap (Score:2)
People always confuse things like "design by contract" with static typing (also in this thread), while the first should be seen as conscious design choice (by the programmer/designer of the software), and the second is in reality a constraint forced by the language.
I'm absolutely not against enfo
Re:look before you leap (Score:2)
there is no dynamic typed Java. (But you can look at beanshell.org, a Java variant/scripting language with dynamic types)
Except if you say: all classes are derived from java.lang.Object. All container classes handle only "objects".
If you want you can write functions/methods(especially with the upcomming Java 1.5, which has autoboxing) like this: meth(Object a, Object b) and call it with meth("string", 1
The method can of course ask if( a instanceof String)
BUT: if you need java and d
Re:look before you leap (Score:2)
In Java, unlike C#, primitive types such as 'int' are not derived from the Object class. So your code would not compile. In order to make it compile you'd have to call it like this:
meth("string", new Integer(1) );
Re:look before you leap (Score:2)
> of structural integrity BEFORE the damn
> thing runs highlighting load of errors
> right there.
That's what your unit tests are for - they ensure that the correct types are being passed around, and, more importantly, the tests ensure that you're doing the right thing _with_ those types.
> type system is only in the way and is not
> really needed when the program is debugged
Exactly. And your unit tests make sure your system stays debugged. And wha
Re:look before you leap (Score:3, Insightful)
Static typing is first step to design by contract (Score:1)
When a module's new maintainer forgets to look before she leaps, she may break some of the contracts implicit in a module's behavior. Thus, there needs to be some way to automatically enforce these contracts. Many maintainers use test cases to enforce contracts after compilation, but test cases tend to fall subject to bit-rot. It'd be nicer if there existed facilities in the language for enforcing contracts. Static typing is a language feature that enforces one specific class of precondition, namely that t
Actually not a bad idea (Score:2)
Given the license fees you are going to save, a quarter million dollars might not be too much to get you off the Red Queen's racetrack.
Re:Heaven forbid C++ should be used (Score:2)
Re:STL is really great (Score:1)
I think some of the anti-STL sentiment comes from people used to working in embedded environments, where every byte and every cycle are precious. I'll admit that I am one of those people, having programmed in 6502 assembly language for a Nintendo Entertainment System with 4 KB of RAM. (I have since moved on to the GBA, with an ARM7TDMI processor and 384 KB of RAM.)
Is STL really great even with GCC? (Score:1)
With a modern optimizing compiler STL vectors and lists become as efficient - or more efficient - space and speedwise over your own hand rolled code.
Is GCC 3.3.1 such a "modern optimizing compiler"? Or do C++ programmers have to shell out upwards of $6,000 per seat for the processor core vendor's own compiler [arm.com] in order to reap the benefits of STL?
Entity beans (Score:2)
Re:Entity beans (Score:1)
Re:Thoughts not a flame/troll (Score:2)
I work for an ASP that develops and hosts a J2EE application (originally iPlanet on Solaris and now JBoss on Linux on x86).
Most decent J2EE application servers have built-in clustering functionality that enables you to scale easily by adding another server node to the cluster.
Like many others have said, you can make a slow application in any language - even if you hack something up in C if you don't know w
Re:Thoughts not a flame/troll (Score:2)
So, if you are talking about running on Sun hardware, it isn't surprising that you would think that Java was unnecessarily slow. Try running on Linux, you will be surprised at the speed difference.