I have a Windows server with SQL Server /IIS running on it, and the for the next application we're planning to create a Java Web App. I've found Spring Framework / Hibernate combo as a compelling option, but I can see that only in my development phase it consumes a lot of memory and processor and I got many PerGem Exceptions, Of course that I've tuned the Java Opts for the increase of Pergem Space,etc but what I can see is that in my dev environment (NetBeans / Maven) it gets really slow, to wait for Tomcat recognize XMLs, redeploy the app, it is more slow than the classic servlet MVC aproach,
My question is: ¿In a server with modest hardware/memory config, with services already running is the Spring / Hibernate combo play well or better I go for other modest way(JSF or Servlets JSPs? ¿Opinions, experiences?, For now there's no budget to buy a new server.
Spring MVC vs JSF should not make a big difference in memory consumption. Replacing hibernate by spring-jdbc might safe you a bit, but how going out of PermGem with a normal Spring/Hibernate app seems strange. Which version of tomcat are you using?
And are you only redeploying/ hot swapping, or sometimes also restarting?
Tomcat has had memory issues with hot-swapping for a long time.
Related
I am investigating replacing Weblogic 10.x with Apache Tomcat for dev machines and I'd appreciate any insight or recommendations anyone may have.
The reason for replacement is probably known to anybody ever trying to do dev work on a production webapp server monstrosity - to improve dev efficiency. The application is large (several million lines of code), legacy codebase, containing a smorgasbord of technologies (Struts, EJB 2, EJB 3, to name a few) and changes to codebase frequently entail doing a redeploy/restart of web server (even with JRebel) - which takes a long time (to the tune of 5-10 minutes). That obviously wastes time, introduces frustrations and leads to mistakes.
What I'd like to know is - is it even tenable contemplating this replacement? The codebase would later on in dev pipeline be validated against a geniune WL instance but for the dev machines, I'd like it to be as lean as possible. This obviously won't be a trivial transition but I'd hate spiking a week on something that's completely impossible or, at least, absolutely inadvisable.
So obviously I'd need something implementing JavaEE spec (doesn't need to be officially validated - as long as it works :) ), so I've looked at possibilites and, to me, Apache TomEE looks promising. Geronimo is long dead, seems like, Glassfish is in limbo (?) and Jonas an unknown. Working under Java 8 would be a BIG plus (which TomEE 1.7 seems to support).
Lastly, we don't work with XA transactions (two-phased commits), so supporting that at least won't be necessary.
Is this a reasonable approach? Is there an alternative I am missing? Any experience doing the transition? Any thoughts are welcome.
long-time TomEE user here. We have been using TomEE in production for the past 3 years. We started off with bigger SOA on version 1.7 (Java EE 6) and a year ago upgraded to TomEE 7 (Java EE 7) for microservices.
Our stack is Kotlin, JAX-RS, CDI, JSON-B, BVal, mybatis for db (pgsql and db2), elasticsearch, hazelcast, kafka, akka-stream-kafka and akka. TomEE makes for a nice, small application server. On startup and initial garbage collection I think it runs around 30m heap usage (or less). We are starting to run Docker on Kubernetes.
WildFly has some cool stuff happening and seems like they are more active, and obviously they have a huge corporate company behind it.
We concur and run the setup that Adam Bien espouses, which is not going uberjar due to the size of docker images, transferring 128M containers vs smaller 5-20M, running on a full application server.
I've tried out WildFly Swarm, it's cool, and there is also a hollow-jar deployment where instead of a fatjar, you can deploy a war (meecrowave also supports this and I think Payara micro too).
I would put TomEE, WildFly (and Swarm), and Payara on my list of app servers to use to stick with Java EE route. If you consider a different direction, prepare to wade through a ton of information, articles, blogs, etc. Akka-HTTP? Play? Scala? Spring Boot, which just runs on netty/tomcat/etc? vert.x?
So many players out there to choose from. Find one that you like and works. For us right now that is TomEE.
I want to offer some REST services which collect data from a database and store passed data in this database. Because I work often with Java it is my prefered language instead of PHP, nodeJs or some other lightweight language/framework.
AS prefered database I would use mySQL or PostgreSQL.
To save some resources I want to use Jetty in combination with Jersey and Hibernate. For the frontend angularJS should help with its asynchronous behavior.
Could this setup run with 500MB of RAM on a small virtual server (VServer) or would it be not enough? Is these a more frugal setup for my prefered language Java?
Many thanks ;)
Going with Java for what you are suggesting is obviously going to take more resources than other obvious choices you mentioned. I'm like you though and like to use Java for this type of thing.
I have done a Jersey, MySql, AngularJS setup just you like you mentioned many times. 500 mb should be enough for you although it really depends on how large your project ends up being.
In my opinion Spring Boot is a nice way to have all your desired components up and running quickly and with minimal configuration (lots of convention-over-configuration and autoconfig).
If you're not familiar with Spring Boot, the spring.io website and its guides should get you up and running. Here is a simple guide to create your REST web service: http://spring.io/guides/gs/rest-service/
(or search for tutorials and talks on youtube/vimeo).
Here you can see an memory footprint analysis of a Spring Boot app: https://spring.io/blog/2015/12/10/spring-boot-memory-performance
As you can see there, 512 MB should be plenty for a simple app.
Spring Boot uses Tomcat and Spring MVC by default with good Hibernate support. You could swap in Jetty (search for appropriate howtos), but Tomcat works really well.
Important (whichever framework you end up using) is to set the memory parameters of the JVM manually (see the memory performance post linked above).
I am developing an AppEngine application with GWT framework using Java. Objectify as back-end(storage purpose). Application has around 30 modules. Whenever I open any page in my web application, it is too slow to display. I want my application faster.
Please help me out with this nasty problem.
Two back to back steps.
Here is the SpeedTracer
And here is the Optimization Techniques of GWT
as already mentioned above, do this steps in general.
but developing for AppEngine needs thinking for AppEngine.
so also AppEngine Docu:
https://developers.google.com/appengine/kb/java#What_Is_A_Loading_Request
Main stuff: AppEngine is not a Java App Server like, Tomcat, Jboss and so on.
AppEngine is a complete own environment running java, (this you should at latest realize when you downloaded the AppEngine SDK )
and then you should see two options, change your account to billing account, and pay for preloaded App
or better, forgot about third party libs and write it by yourself,
for what you need objectify ??? the appengine datastore api is very good.
using the Apis directly will also point your thinking of how to design your app for AppEngine better.
Use Appstats to profile your application and identity which RPCs are slowing down your app.
Having done this, you should be able to find ways to reduce the number of RPCs you're making, e.g. by using memcache. You could also try to use async APIs wherever possible.
You should think to cache data for the session or across sessions on your client side also. You can do statistics on the most common requests and do server caching on them too
I am quite certain the reason its slow is because your application loads all the code in the browser.
Use HTTP watch tool to see whether this is correct. For a 2MB nocache.js file it usually takes 2 minutes to load.
Are you using any MVP framework on your application; if not, this could be one of the problem. Objectify is not going to slow you application, I presume it is the way you built your application.
Also try to use GWT 2.5, so you can take advantage of the closure compiler so you can reduce you application's footprint for about 20% (maybe). Furthermore if you are deploying in Tomcat, you can try to enable gzip compression.
"Slowness" of an application can't be attributed to just one part of the application, it could be spread across the layers of your application (based on my experience)
Hope this helps.
here is situation, my boss ask me to develop a web application for querying and editing data of tables in a database. Then server environment is restricted to jdk1.3 with websphere(a old version, i dont remember which) as application server. This web application need to be light weight as the server is old and slow. the database to be connected is not finalized and my boss proposed to use jdni for later switching database, i will be using oracle for testing.
As the websphere is not yet setup in server, my boss ask me to test on jboss 3.2.7 first and later migrate to websphere when it is ready.
Is there any framework that is light weight and compatible for jdk1.3, jboss and websphere that simplify the task like object relational model, mvc etc.
Use straight forward JSP + Servlets + JDBC approach since you need every thing to be lightweight and JDK 1.3 compatible. Use Apache DBUtils to ease JDBC pains.
Develop a new app on JDK 1.3 and an old version of WebSphere? What's the rationale for this poor decision?
That JDK reached its EOL on 25-Oct-2004. That's almost seven years ago! That's pre-generics, pre-collections, pre-concurrency package, pre-generational garbage collection, and a host of other improvements.
You and your boss should reconsider this decision. There's no reason that would explain it. If it's cost, get a free Java app container. If it's a web app, use Spring and deploy on Tomcat; if you require EJBs, use JBOSS.
I've switched from classpath scanning of Controller classes to explicitly declaring the beans, but was wondering what else I can do to cut down on the initial startup of a Spring MVC application.
Not knowing the specifics of your project, I would say your best bet is to profile the startup of your Spring MVC application.
You can do this using %JAVA_HOME%\bin\jvisualvm.exe from the Sun JDK, if that's what you're using.
Netbeans has a good article on profiling Java web application.
If you are working on an open-source project or have the money, you can use YourKit.
Have you ever profiled before? You should start profiling when your specific webapp starts loading and stop when it's done, if you know it's your web app that is causing the slowdown.
Otherwise, you should profile your entire web container / app server from start to running.