1

Im currently developing a java web application, and im researching how i should combine different types of technology in order to get the most use of a single webserver.

My plan so far is to have the following architecture setup

Internet ->
Varnish (reverse proxy) ->
Apache2 (mod_pagespeed, mod_jk) -> 
Ehcache-web (caching html page fragments,spring-cache) ->
Tomcat (java appsrv) ->
Ehcache (cache layer) -> 
MySQL (persistance layer)

Is there any problems with this design? What about scaling and clustering when it comes to that? Is there any other (better) solutions?

Thanks!

netbrain
  • 9,194
  • 6
  • 42
  • 68
  • It depends - I'd not consider using Varnish day 1 unless the app you're building is going to get hit real hard. You'd also want to consider using memcached between Tomcat and MySQL (caching layer). – lobster1234 May 11 '11 at 08:37
  • Ah forgot, i have ehcache between tomcat and mysql – netbrain May 11 '11 at 08:41

2 Answers2

2

I do not envision a webapp in a traditional manner - but in terms of service providers and consumers. At work we've a RESTful API layer running under Tomcat, built by implementing Shindig interfaces. The layer interacts with MySQL as well as MongoDB. We have near/far caching using Memcached, which we plan to move to Redis given that we use a lot of list and set based operations. This layer also interfaces with Twitter and Facebook for certain APIs (like pushing out the status updates). All the endpoints are accessible as OpenSocial compliant REST/XML calls. We use NewRelic to monitor the service performance and SLA. Currently we're doing a little over 30K RPM with a response time of 10ms. We have a cluster of 4 Tomcats, 3 memcacheds, 3 MySQL (1M 2S) and 3 MongoDB (replicaset). All of the stack runs on Virtual Machines hosted by XenServer, running Centos. We use RabbitMQ for messaging/async operations like sending notifications out or talking to 3rd parties (Twitter/Facebook) so as to not block the VM threads. We plan to move to HornetQ+Scala Actors in the near future as the platform gets popular. The search runs on Solr but we're actively migrating to ElasticSearch.

We architected the system in this API/Services based model so that we can serve more than one client platform. So when our Mobile app launches, that can re-use the APIs instead of having a separate set of the same stack for Mobile. This architecture abstracts the back-end offerings with no coupling to the front end. The front end we have is built in PHP/Zend, and it uses JQuery extensively. We are building a mobile front-end using HTML5, Phonegap and Sencha touch.

For security we have open GETs but the writes are secured via 2-legged oauth. We will need to provide 3-legged oauth once we open up the API to external consumers and app developers.

I hope this summary helps. Please do not hesitate to comment if you need further information or have any questions.

lobster1234
  • 7,679
  • 26
  • 30
  • Very interesting indeed. Thanks for the input on platform & technology choices and other utilities. – netbrain May 12 '11 at 07:15
1

We are using for our high traffic portal ( ca 55 mil. PI /month ) 3 Varnish proxies, 3 Apache (2) load balancers, on 6 servers pro server 4 tomcats communicating with apaches over mod_jk. As RDBMS, we have Oracles. I think the DB selection is critical. Our contents are our existence, for that reason we need a DB product, which's responsive, robust, scalible, reliable, high available, so on. We could need support in worst cases. For that reason our selection was Oracle.

Tomcat / Application Server selection depends on your application architecture. In our case, we have Coremedia CMS (Spring based CMS which contains distributed services like content server, master live server, feeder, etc. communicating over CORBA) and clustered Tomcats are sufficient.

I think that your list / setup and this combination seem very well and sufficent for most cases.

Erhan Bagdemir
  • 5,231
  • 6
  • 34
  • 40