views:

85

answers:

2

I'm working on a rather intensive rewrite and given a choice of the following options:

  • JSP / Java running on Tomcat
  • PHP running under Apache
  • Ruby (running under I'm not sure, ROR?)

A couple of basic questions I would like to know about the above.

Speed is a concern. We have a MongoDB backed database, so we shouldn't need to be waiting on the database for information, but the frontend needs to be as fast as possible. The common saying speed isn't a concern doesn't really apply here. If you're processing 500k+ objects in one request it needs to be fast.

Scalability is another concern. Suppose our database blossoms out of control. Which (of the above) would provide the easiest method of handling this?

What are common downsides of Tomcat / JSP and Ruby? Is parallel processing easy to do with PHP or Ruby?

The goal is not to save money but to build a solid, fast, scalable system to continue development on for years to come.

I'll be honest, I'm a former Java developer (not JSP) turned PHP developer. My preference for anything is PHP but I also am a big believe in using the right tool for the job. The team is competent enough to write this is anything that we

+1  A: 

Seems like any of them would be acceptable based on the limited info so far. The important things I've begun to consider when launching new projects are more about the ORM and framework than about speed. For every extra 40 hours of developer time I have to spend on a project I can provision and operate a new server for 1 year.

If you have developers that are better versed in the APIs for a particular language, that alone could (potentially) make your decision. If you can parallelize 500k things across 10 servers, and choosing language (and API/libraries) A over B will save you 10 weeks, then that is your breakeven point. Similarly, if one set of things is 2x as slow, and having 2 servers instead of 1 could double your processing speed, then it will only take 1 week of extra fighting in the "faster" language before all your performance gains are wiped out due to longer development time...

Zak
@Zak: Not concerned with development costs. We're rewriting a system that's almost ten years old, and this is designed to last for longer then that. Upgradeability and scalability (along with speed) are the main points, not cost. Right now the system is build on JSP / Tomcat, but as I said, we're rewriting and can choose whatever language we want.
Josh K
My point is, that since you are rewriting, speed on a single processor is not your primary directive for speed. Parallelized speed is your main directive. Design your app to be fast. Don't count on the language to make it be fast. Cost is always a factor. For instance, if you want hands down fastest speed, you can write your app in C or assembly. Google did this. They even wrote their own file system. Also, PHP can be faster than Java/JSP at many tasks. But in designing a large app, some of Java's strong typing could help you keep Junior developers on a more bug-free path. Or maybe not!
Zak
@Zak: That is why we're leaning towards a Java/JSP approach. I don't normally use Java/JSP and was worried about scaling the application later on.
Josh K
There are design patterns to help you deal with scalability. Front Controller is one that comes to mind. Your Front controller can take a problem, chunk it up into smaller problems, then deliver the smaller problems to background servers for parallel processing. this is independent of being written in a particular language. In php, you just have a request come in, split up your request into smaller chunks to process, then curl_multi_exec to as many servers as you want: http://us.php.net/manual/en/function.curl-multi-exec.php You can do similar things with Ruby.
Zak
@Zak: That sounds very reasonable. Is there *any* benefit to Ruby? It was tossed to us as an option and I'm not sure if it fits into the overall scheme at all. It's also the language we have the least experience with.
Josh K
Ruby is the language I have the least experience with also. However, rails, and the way Active Record is implemented can be a huge timesave to use as opposed to JPA and/or Doctrine. If time is not an issue, have your team spend a week building a tool in ruby that you can all use.. maybe a bug tracker or source management aid. It is pretty fun.
Zak
A: 

Ended up going with Play!

Reasons:

  • Quick startup
  • No redeploying / packaging
  • Straight forward MVC pattern
  • Groovy template / inherited views
  • Drop-in support for dependencies as JAR files

Development was never hindered by it. No one had to learn anything new besides where to put the controllers / models / views.

Josh K