ThePort's Product and Technology blog. We'll share helpful tips about the platform, talk about upcoming releases, and maybe on occasion share a story or two on how awesome the team is here.
Object Queuing Architecture
Queuing means a lot of things to a lot of people. I'm going to explain what it means when we say we are introducing a queuing mechanism here at ThePort. This is a platform scalability and performance enhancement that has been highly anticipated internally.
The reasoning behind the queue is straight forward. Get slow track operations out of the user's fast track. This is especially viable when the operation is not particularly time sensitive. When an operation is queued the bulk of its work and time are taken out of band, and replaced with a simple and predictable write to the queue. Anything time consuming can fall into this category; be it database updates, photo conversions or bulk cache modifications. For example, a user should not need to wait on his last login date to be updated as he is logging into the site. They simply want the next page to load quickly. This is generally what we mean when we refer to the fast track, things that a user does frequently. Slow track operations are those that happen infrequently, and need immediate results. Administrative pages are often in this category, and queuing is undesirable because it could interfere with the timeliness of information.
Now, it's time for the technical highlights. A more complete name for our new queuing system might be a "generic object oriented method queue". The foundation is Microsoft SQL Service Broker. From our client, any object in our platform can be packaged with its data, a method to call, and any necessary parameters and sent to the queue. Using load balancers, multiple redundant queues may be used seamlessly to provide fault tolerance. In the queue, the operations are persisted to disk and inherit the stability and consistency of Microsoft SQL Server. Independently, an application server farm constantly polls the queue, or queues, for items to process via a Windows service. There are three independent queue priorities each serviced by a separate thread. This allows important processes to bypass a long running one. When an item is taken from the queue, the item is de-serialized, and reflection is used to invoke the desired method.
That's all there is to it. Our new queuing mechanism goes live with our Q3 release.