Slashdot Mirror
Choice of Language for Large-Scale Web Apps?
anyon wonders: "PHP is the most popular language for the web. eBay uses ISAPI (C), Google uses C/C++ (search), Java (gmail), and Python. Microsoft uses ASP (what else?). For small web site, it really doesn't matter. What's your take on language choice for large-scale web applications? Maybe language choice is irrelevant, only good people (developers) matter? If you can get the same good quality people, then what language you would chose? Considering the following factors: performance, scalability, extendibility, cost of development (man-month), availability of libraries, cost of libraries, development tools? Has there been a comprehensive comparison done?"
No question about it!
performance, scalability, extendibility, cost of development (man-month), availability of libraries, cost of libraries, development tools
Performance? Assembly will give you the best performance followed by C and C++. All three of do not have that great of support for web apps..
However, Java is almost exclusively being used for large enterprise websites. Its powerful enough to handle the big jobs, and using the appropriate app server will give you great performance.
Cost of development is heavy in initial development, but pays for itself in maintenance. Most libraries and APIs are free in java (struts, spring, hibernate, tapestry, etc etc etc...). I'd say they are second to perl in terms of freely available and powerful libraries and APIs.
Development tools? Just check out the (free!) eclipse platform.
In my mind there is no question that Java (more specifically J2EE) is the best option for general large scale enterprise applications.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Ajax, which stands for Asynchronous JavaScript and XML, does not necessarily imply Java on the backend. Many Web application frameworks, such as Ruby on Rails, include Ajax helpers. I'm sure many Java Web app frameworks have also added support for it.
Adaptive Path has a nice article introducing Ajax called Ajax: A New Approach to Web Applications.
What people mean by 'it doesn't scale' is that it doesn't scale. Not that it doesn't run fast enough or have enough functionality for pretty much anything at the small-to-medium sized website...
I have a set of 200 or so websites all running though a self-built PHP template-based content-management system (hey, this was 8 years ago, they were rare then!
And will all those features it's still not scaleable. I can't split the system over multiple webservers and begin a transaction on one webserver, have a hardware failure, and have it complete on a different webserver.
I server about a million page-impressions a day (less at weekends) so I'm hardly "big iron", but at the moment it's all serving from a single machine(*) with a manual backup ready-to-go. We're (probably) about to triple our daily throughput (time to splash some cash
I can't have the above level of scalability but I can divide up the work over (say) 4 cloned webservers, and use round-robin DNS (low TTL) or transparent-proxy load-balancing to share the load. Then at least if one of the machines goes down (not the proxy
We're probably going to have 2 database servers as well - one in slave mode, one in master mode (all writes to the master, because we use MySQL). The single point of failure then becomes the proxy gateway (because RR DNS is a bit of a pain), so we can have a spare standing by - the configuration of a load-balancing proxy is pretty trivial, and doesn't depend on anything else, so it can be sitting ready to run and swapping ethernet patch cables ought to be all that is necessary.
And that's about as "scalable" as I can make it - not very. All I'm doing is duplicating hardware for speed and reliability. I can have robustness against a machine dying, but that's about as far as I can go. True scalability allows the operation the machine was doing when it died to complete successfully, and PHP ain't there (yet). I guess you could implement it in s/w using lots of state tables, and perhaps get 80% of the way there, but it's an add-on not a built-in, and not a complete solution. Better to go with something that works if you need it...
Just MHO.
Simon
(*) It is a bit of a beast of a machine though
Physicists get Hadrons!
The only reason people think they use ISAPI is because that's what they originally used, and an executive decision was made to not break any existing links at any time, ever. Check the Powered by Java image. The /ws/eBayISAPI.dll that you see in all of the requests just invokes a servlet.
20k lines of code? That is miniscule. I've got a mid-sized enterprise system that's got 20k FILES containing millions of lines of code integrating a dozen desparate systems over a network of 50 or so servers. It handles thousands of concurrent users performing transactions - not just viewing content. That's just a mid-sized system. Some large scale systems use clusters of hundreds of servers. Not to bash what you're doing but I think you could use a little perspective on the size of your application.
0 2-jperf_p.htmlo mmti-systems.de/main-Dateien/reviews/languages/ben chmarks.html& CFTOKEN=101A9EF8-9F8D-153A-37A5E0A40D3EE24A
I don't care if you've got a freakin army of PHP programmers, you're never going to build a system that can scale like Java.
1) Scripted languages in general: slow performance
2) Compiled languages in general: Requires rebuild before changes take effect, so testing and retesting is slowed down.
3) Java/.Net/Byte-code languages: Worst of #1 and #2 above.
Don't believe the hype about Java's performance. Today's just-in-time compilers can optimize code as well as hand optimized code and they don't waste resources optimizing paths that don't get executed. There are many benchmarks out there that confirm that Java's performance is comparable to C++ and even better in some areas.
http://www.javaworld.com/javaworld/jw-02-1998/jw-
http://www.tommti-systems.de/go.html?http://www.t
http://java.sys-con.com/read/45250.htm?CFID=29694
I agree with your point though, there are a huge number of crappy programmers out there. Good programmers write good code in whatever language they are using.
So, what is good code?
IMHO, good code performs well and is easy to understand and use.
Then I guess you never heard about using database driven sessions. The way how you've designed that bad boy, it would'nt scale in any language.
Here's what we do:
- 8 Apache Webservers
- 3 Million pageviews per day
- Distributed PHP sessioning (Postgresql based)
- PHP module
- Postgresql (no worries with MySQL write locks)
Scaling? We add new machines in the mix, tell our load balancer about the new machines, and we've scaled linearly. A machine goes down? The load balancer redirects to another machine and the session continues without a beat.Bottleneck? The database, but then you throw big iron at that.
Look, the web is stateless, if applications are designed from the get-go realizing that fact, heck, you can get a shell script sitting in cgi-bin to scale with your server pool.
There's absolutely nothing in PHP that inherently causes it not to scale. Sure, other languages have easier and sometines better features built in, but if you're already using PHP, implementing those features are usually worth the few programming hours of effort instead of switching to another language/platform.
Newsfollow.com