Not a glassfish specialist here but in a project where GlassFish is to be used as enterprise service bus, and I am sort of on the receigving end and a little no agreeing with the architecture team.
What are practical limits on throughput (messages per second) and message size for GlassFish? Just as house numbers for a decent modern dedicated server. Asking because the architectural proposal on my desk is IMHO ridiculous - but I have no idea about the limits of GlassFish.
You really should run your own benchmark yourself (on your hardware, with your own settings) but to my experience, GlassFish ESB is pretty efficient, and reliable.
Just in case, here are some resources that might give you some ideas:
Benchmarking BPEL Service Engine
BPEL SE Scalability Experiments/Evaluations
Benchmark Glassfish ESB April 2010
But if you need to convince someone, you should IMO come back with demonstrable facts.
Related
How to estimate resources (cpu, memory, for rabbitmq? On the manufacturer's website I found the short information https://www.rabbitmq.com/production-checklist.html
Use PerfTest to simulate your expected and potential future workloads.
I am designing a distributed master-worker system which, from 10,000 feet, consists of:
Web-based UI
a master component, responsible for generating jobs according to a configurable set of algorithms
a set of workers running on regular pc's, a HPC cluster, or even cloud
a digital repository
messaging based middleware
different categories of tasks, with running times ranging from < 1s to ~6hrs. Tasks are computation heavy, rather than data/IO heavy. The volume of tasks is not expected to be great (as far as I can see now). Probably maxing around 100/min.
Strictly speaking there is no need to move outside of the Windows ecosystem but I would be more comfortable with a cross-platform solution to keep options open (nb. some tasks are Windows only).
I have pretty much settled on RabbitMQ as a messaging layer and Fedora-commons seems to be the most mature off-the-shelf repository. As for the master/worker logic I am evaluating:
Java-based: Grails + Postgres + DOSGi or GridGain with
Zookeeper
Python-based: Django + Postgres + Celery
.net-based: ASP.NET MVC + SQL Server + NServiceBus + Sharepoint or Zentity as the repository
I have looked at various IoC/DI containers but doubt they are really the best fit for a task execution container and add extra layers/complexity. But maybe I'm wrong.
Currently I am leaning towards the python solution (keep it lightweight) but I would be interested in any experiences/suggestions people have to share, particularly with the .net stack. Open source/scalability/resilience features are plus points.
PS: A more advanced future requirement will be the ability for the user to connect directly to a running task (using a web UI) and influence its behaviour (real-time steering). A direct communication channel will be needed to do this (doing this over AMQP does not seem like a good idea).
Dirk
With respect to the master / worker logic and the Java option.
Nimble (see http://www.paremus.com/products/products_nimble.html) with its OSGi Remote Services stack might provide an interesting / agile pure OSGi approach. You still have to decided on a specific distribution mechanism. But given that the USe Case is computationally heavy & data-lite, using the Essence RMI transport that ships with Nimble RSA with a simple front end load balancer function might work really well.
An good approach to 'direct communication channel' - would be to leverage DDS - this a low latency Publication / Subscription peer to peer messaging standard - used in distributed command/control type environments. I think there is a bare-bones OSS project somewhere but we (Paremus) work with RTI in this area.
Hope the above is of background interest.
Are there any advantages what so ever to form a cluster if all the nodes are Virtual machines running inside the same physical host? Our small company just purchased a server with 16GB of Ram. I propose to just setup IIS on the box to handle outside requests, but our 'Network Engineer' argue that it will be better to create 3 VMs on the box and form a cluster with the VMs for load balancing. But since they are all in the same box, are there actual benefits for taking the VM approach rather than no VMs?
THanks.
No, as the overheads of running four operating systems would take a toll on performance, plus, I believe all modern web servers (plus IIS) are multithreaded so are optimised for performance anyway.
Maybe the Network Engineer knows something that you don't. Just ask. Use common sense to analyze the answer.
That said, running VMs always needs resources - but you might not notice. Doesn't make sense? Well, even if you attach the computer with a Gigabit link to the Internet, you still won't be able to process more data than the ISP gives you. If your uplink is 1MB/s, that's the best you can get. Any VM today is able to process that little trickle of data while being bored 99.999% of the time.
Running the servers in VMs does have other advantages, though. First of all, you can take them down individually for maintenance. If the load surges because your company is extremely successful, you can easily add more VMs on other physical boxes and move virtual servers around with a mouse click. If the main server dies, you can set up a replacement machine and migrate the VMs without having to reinstall everything.
I'd certainly question this decision myself as from a hardware perspective you obviously still have a single point of failure so there is no benefit.
From an application perspective it could be somewhat tenuously suggested that this would allow zero downtime deployments by taking VMs out of the "farm" one at a time but you won't get any additional application redundancy or performance from virtualisation in this instance. What you will get is considerably more management overhead in terms of infrastructure and deployment for little gain.
If there's a plan to deploy to a "proper" load balanced environment in the near future this might be a good starting point to ensure your application works correctly in a farm (sticky sessions etc). Although this makes your apparently live environment also a QA server, which is far from ideal.
from a performance perspective, 3 VMs on the same hardware is slower
from an availability perspective, 2 VMs will give higher availability (better protects from app software failures, OS failures, you can perform maintenance on one node while the other is up).
I'm searching for a distributed caching solution on mono similar to java's terracotta and infinispan. I want to use it as a level 2 cache for nhibernate. Velocity and sharedcache have no mono support, and memcached isn't distributed nor have high availability.
Best Regards,
sirmak
You are looking for a more sophisticate data grid solution that will provide scaling and high availability, memcache I find is a bit too primitive for such a requirments. I would advise to look into Gigaspaces XAP or VMware Gemfire. Both are java product that have .net clients both are very strong. Gigaspaces may offer a bit more co-location capabilities.
I think you meant "replicated" instead of "distributed". Memcached is indeed distributed, but not replicated. However, you can make it replicated with this patch.
we are evaluating ActiveMQ and I whould like to know what you think about it. Any feedback is welcome.
EDIT:
actually, I need to know things like: how does it scale? What about stability? Is it stable enough for production environments? Memory consumption, etc.
Its been used in thousands of production environments, some examples are Sabre Holdings (travelocity,lastminute.com,etc),FAA,CERN,JPL, etc - so its proven to be robust and perform:
Sabre -32k transactions per second -
that's reliable performance
A large retailer (can't name them) -
10k+ stores, all connected with
real-time updates over ActiveMQ - that's scalability
Here's my opinion & experience, for what its worth.
We have been using ActiveMQ in production for almost 2 years. We did have a couple of issues with ActiveMQ 5.1 that we had work arounds for, but since ActiveMQ 5.3 (we are using SNAPSHOT from July) we have not had any issues and have been happy. Our system pushes an average of 60 msgs/sec through the system with peak volumes > 700 msgs/sec. We run a single active/passive broker pair with persistence journaling via NFS mount to a dedicated NAS device.
--Steven
We have had customers move from ActiveMQ to FioranoMQ - they had the following problems that they reported - found Active MQ configuring very cumbersome/difficult to the point of giving up; and stability could not be achieved; support and documentation are a big issue as he said he can't get a working answer from them how to solve the problem which means even if they paid for support it might not help. Data loss prevention configs for non-persistant/persistant and stability are big concerns and ofcourse limitations on speed. Failure under peak conditions - eg. when message-rate
spikes.