In my last blog, I had some issues with Atlassian Stash. In the last week and half, I would like amend my attitude to the product. In fact, I thank Atlassian Support for their really good responses and quick turn around to my questions. The biggest problem, which I think that even engineer like me, experienced failed to realise, that was code always changes and all resources are finite.
First, I upgraded my Atlassian Stash product from 2.10.1 to 2.12.3. Therefore, I obtain the latest improvements in the product in terms of performance and bug fixes.
Second, I was running the Tomcat 7 server on a Virtual Private Server (VPS) with only 1GB of RAM. This would have been plenty of memory if Tomcat was the only service running on the Linux system, but when you start add other services like Apache HTTPD, Play Framework with Codehale’s Dropwizard and other test services. Stash itself requires a Java VM with 768MB of RAM. I upgraded my VPS to at least 1.5GB RAM and the performance of Stash is now much better. I also limited the memory consumption of Apache server and other restricted the other ad-hoc services.
The moral of the story is this. Until there is a JVM that allows shared classes and resources, then you will have to careful tune the resources running multiple JVM instances in a virtualised environment. If your demands require more memory then you have to buy and scale out horizontally. As Kirk Pepperdine said, “You can’t ever hope to virtualise performance increases with JVMs running inside a virtual environment”. Atlassian Stash is like another service, requires it own JVM (or Tomcat server) to run with physical memory demands. Netty and Play Framework services are other examples of other JVM instances. So Reactive Mongo people could also take note of this advice when running Scala web applications.
I recommend Stash to your services and clients if you want to get a private Git Repository reliably on a server for your office team. The user interface is also very good.