Exciting news at ThePort!  Historically ThePort has offered its services via a 100% SaaS model with our hardware stack sitting in a local Atlanta based datacenter.  We've had enormous success with our SaaS model; however, it's clear that many businesses are beginning to accept service via the cloud as a viable alternative to SaaS or even traditional On Premise delivery models.  As we continue to grow our service offerings to enterprise system vendors, we are very aware of the need to expand our delivery options to meet the need of a diverse customer base.  

Over the past few months we've taken a huge step in that direction by fully installing an instance of ThePort Social in Amazon EC2.  The deployment is complete and fully tested, but is currently utilized for internal testing and demonstration purposes.  At this time we have no plans to migrate any customer communities from our physical data; however, we are capable of hosting any new customer sites in the cloud.  The move has allowed us to certify that our technology works like a charm in the cloud.  As an added benefit we've also been able to certify running our platform with a SQL 2008 database, as opposed to our current production environment which runs on SQL 2005.  

Now that SaaS and Cloud delivery options have a nice fat check mark next to them, it's time to turn our focus to the next hurdle: On Premise installs packages.  We have a major release slated for Q2 this year to address that specific issue.  Many more details will be coming over the next few months.  In the meantime we will be hard at work to bring the same great collaborative tools we currently offer behind the firewall!

Over the last several months we've heard you loud and clear regarding site performance.  While we've been heavily focused on developing new features that we hope you'll love, we also recognize the need to continue to improve and enhance the most import feature of your communities: performance.  Our latest release was this past Saturday morning and our team heavily focused on large improvements to both general spread and page load times within your communities. 

Initial tests in our QA environment have been extremely encouraging.  We've seen increases in page load times from 39% up to 80+ % for several highly trafficked system pages.  Obviously, if this holds true in our production environments it would be quite a noticeable improvement.  We will be working over the next several weeks on quantifying the improvement in our production environment.  But, for now we figured it might be worthwhile to ask you directly: are you seeing an improvement?  If our QA data mirrors reality even somewhat, you should see a very noticeable boost in speed.

So, what exactly did we do?  This change boils down to a comprehensive overhaul in the way many pages and modules retrieve their data.  By taking increased advantage of server caching, we have eliminated several unnecessary calls to our database that may result in delayed response times.  In the simplest terms, when a new page is loaded there are tons of small pieces of information that need to be retrieved - requiring a trip to the database and back to render that piece of data.  With our recent changes, we're taking more advantage of cache to "store" pertinent pieces of information for re-use.  These pieces of data become immediately available the next time a user hits a page that might require that data.  As more and more users navigate the site, more data will be stored in cache.  So, performance will actually increase during peak usage.  Logically, this may seem a bit backwards, but it does make sense.  More activity = more information requested from database = more information stored in cache = more information immediately available for the next user.  Now, using cache to optimize performance is not a new concept.  We've used cache in our system for quite some time.  Consider this most recent release an example of "cache optimization" - we're getting smarter about how we use cache to improve performance.  We will continue to build on this improvement in upcoming releases as well.

System-wide, our peak usage hours fall in weekday afternoons (EST).  However, its important to note that the above improvements will be noticed most readily when your specific site is most active.  Our team is very excited about these updates and we hope you and your members are seeing huge speed boosts!  Don't hesitate to leave a comment with your observations or questions about the change.

This morning just after 10 AM EDT our data center encountered an unexpected outage in the course of planned maintenance. Our redundant systems took effect and the downtime was limited to a 1-2 minute span from 10:08 AM EDT to 10:10 AM EDT. At approximately 11:45 AM EDT the data center again took our systems off line as a necessary precaution to prevent damage. It is ThePort’s policy to report any planned downtime ahead of time to our clients, however due to the nature of the outage we were unable to notify clients prior to the downtime in this instance. While the outage was unplanned, the maintenance was completed as planned and system availability was restored as of roughly 12:05 PM EDT. We apologize for any inconvenience this caused you and your community members. We are currently working with our data center to ensure the root cause of this unplanned outage is thoroughly investigated. Please let us know if you have any questions or concerns.

As I sit at the Suiteworld conference here in San Francisco and listen to how NetSuite has built their system on the cloud and how that's enabled them to be more agile, I'm reminded of our story here at ThePort and how we're in a unique position to bring social to any kind of system, anywhere, anytime. How do we do this? We do it through cloud based OEM.

Let's back up a second though. What is OEM? It stands for Original Equipment Manufacturer and is the idea that someone may  produce a piece of equipment or hardware or software that is then resold under someone else's brand. In the software world this happens all the time when a software company produces a piece of software that is then subsumed into another piece of software. It could be a database, a UI component, or anything in between. But OEM in the software world has always almost always shipped with the software as part of the code. This is where we're a little different.

We are what we call a cloud based OEM provider. Its somewhat similar to Platform as a Service (PaaS) but the main difference is that a cloud OEM provides fully functional pieces that can easily be baked into another piece of software. For instance, our discussions platform is a great example of cloud OEM. We're able to easily white label this part of our platform, host it, and bake it right into another platform with relative ease. Same with our Activity Stream / Points platform. A partner could then take the points system (or parts of it) and easily embed it into their system. 

So what are the benefits? The ability to rapidly plug a new feature into your platform is the first and most obvious benefit. The rapid pace at which we upgrade these tools is another. Instead of seeing upgrades once a year, you're going to see upgrades every month (if not more frequently). Lastly, we incur the hosting burden. We make sure the system is up and running and performing as well as possible. 

That's right. Despite rumors of its demise, we don't see email going away anytime soon. Especially in the enterprise and non-profit realms where email is still a critical communication tool. We absolutely see social networks, texting, IM, and technologies yet to be discovered reducing the need for email over time. But is it going away in the near future? No way.

To that end, we are making two critical improvements to our email delivery system:

1) In the next few days we will be deploying an enhanced email monitoring system. We have a fairly lightweight monitor right now but its simply not doing a good enough job telling us the overall health of the email system. Our new system will actively monitor how many emails are sent and if we start to see a delay in email delivery, the system will notify us. Most importantly, we're separating this monitoring system from the remainder of our platform. That way, if there's a systemic problem, the monitor will be unaffected (this may seem obvious but you'd be surprised!)

Here is a screenshot of the system we will be deploying (note: this is what happens when engineers design something. Our UI team would like me to be clear that they had nothing to do with this!)


It may be difficult to see but we'll keep a rolling 30 day snapshot of the overall health of the system. This will help us trend how email delivery is going and spot any issues that are repetitive. 

2) Coming sometime this summer will be another enhancement -- we'll start using Amazon's Simple Email Service for email delivery. When we first built our email system, our needs were small and delivery less critical. So we used our own internal SMTP servers to send email. But as demand has grown, as well as stability needs, we require a more "professional" email delivery system. Amazon's cloud service should provide for greater overall stability and higher email delivery success rates. This will be soft launched in June with a full deployment throughout the summer. 

We're looking forward to getting both of these improvements out the door. We'd love to hear feedback!

As you may know we have been experiencing intermittent issues with delayed e-mail delivery for system generated e-mails recently. Specifically, the impact you would have experienced would have been delays to receive subscription e-mails, e-mail notifications or e-mail digests.

First off, we sincerely apologize for any inconvenience this might have caused you over the recent weeks. The good news is that we have identified a root cause and have a plan in place to ensure that these issues do not become systemic. Essentially, what has happened is that one of our application servers has been experiencing intermittent performance degradation to the point that it begins running very slowly. The degraded performance causes back ups in processing of requests. Hence, outgoing system e-mails are delayed . This performance degradation has occurred twice over the last three weeks and in both cases a server re-boot has restored normal service. However, due to the short timeframe in which we've experienced two similar issues we have decided to replace the equipment. While the equipment is still functional, we are expediting the replacement strategy to make sure we prevent future e-mail delivery issues.

Again, sorry for any inconvenience this has caused you or your members. Please feel free to ask any questions in our support message boards or send us a ticket at support.theport.com if you have further questions or concerns.

- ThePort Product and Development Team

As all of our customers are aware, this latest release came with a wide array of changes to our search engine. First and foremost, we did a major upgrade to the core engine, SOLR, which will pave the towards better in document searches and location based searching. If you're unfamiliar with SOLR, check it out, its been fantastic for us. 

Not only did we upgrade the engine but we upgraded how much we catalog and for whom. Previously we were focusing our search efforts around users, groups, and blogs. With this release we're now cataloging more discussion data as well as documents. And we finished the migration of all of our customers off of our old, legacy search to this new SOLR based search. So we're now indexing deeper into our communities as well as ALL of our communities. Good news, right? 

Well sort of.

Last Thursday morning, a few of our alerting systems started spewing weird monitor emails in our direction. We dug in and found that the routine we have to populate the indexes was having an issue keeping up. Upon digging a little deeper, we found that the JVM we use to host SOLR was having random "out of memory" exceptions. We tweaked memory settings, rebuilt indexes, and tried a handful of other things to stabilize search to no avail. We kept seeing the out of memory exceptions. We concluded that the 32-bit JVM we were using had run out of gas. We were now indexing so many assets across so many communities that even though the machines we run our search engine on have 8 GB of memory, the 32-bit JVM could only access 2 GB at any given time. We had found the ceiling of our search engine and were trying our best to punch through it. Fortunately we quickly identified 2 resolutions:

Short-term -- Upgrade the JVM to 64-bit. This would allow us to access all 8 GB of memory on the machine. We did this Thursday afternoon and saw an immediate turn around in our search engine. No more out of memory exceptions and our indexes were able to complete their respective rebuilds. Our problem temporarily solved!

Long-term -- Split our search across multiple machines. We actually built this stratification in from the get go. That is, depending on the community, search would be handled by one or more machines. This architecture is wired into our platform, however, its not yet enabled. This, in conjunction with the 64-bit JVM we're using, will allow us to scale our search engine to tens of millions of assets across thousands of communities.