WebSync Method Containers and Memory Usage

by anton.venema 22. June 2010 20:20

With WebSync Server 3.0.2, we've introduced the targedScan web.config attribute and the WebSyncMethodContainer assembly-level attribute. Together, they can help to reduce memory consumption significantly. This is especially important for shared hosting environments, but is a good practice for any production system.

Before explaining what the new attributes do, let's first look at why memory consumption is an issue at all.

WebSync lets you decorate methods with attributes so they attach to specific server-side events (BeforePublish, AfterSubscribe, etc.). This ability is what makes WebSync so extensible and part of what makes it so easy to use. In order for WebSync to invoke the methods, though, it first has to find them. To do that, WebSync scans the currently loaded assemblies, looking at each type and checking for methods that are decorated with WebSyncEvent or WebSyncScriptModifier. This scan happens just one time, at first run, after which the decorated method information is cached and can be accessed later as needed.

So what's the problem?

Well, there's one small catch. Reflection is expensive, and the .NET framework architects made a design decision a long time ago that any reflective calls for metadata should be cached internally rather than allowing developers to implement caching solutions themselves. This means that whenever type or method information is accessed, the metadata is cached permanently in the application domain. The intention of the architects was to ensure that the reflective work was only every performed once, but for server environments with scarce resources, this is a problem.

As WebSync scans the assemblies/types/methods, .NET caches every piece of information. The internal .NET bloat can be noticeable, even upwards of 100MB memory consumption. We think you would agree, the memory could definitely be put to better use.

Enter the targetedScan and WebSyncMethodContainer attributes, which define where and how to scan.

If targetedScan is set to true in web.config (WebSync/server[targetedScan]), WebSync will ONLY analyze types that are explicitly specified by the WebSyncMethodContainer assembly-level attribute.

For example, if your WebSyncEvent methods are defined in a class called MyWebSyncEvents, simply place the following attribute in AssemblyInfo.cs (in your Properties folder):

[assembly: WebSyncMethodContainer(typeof(MyWebSyncEvents))]

Now, if targetedScan is set to true, WebSync will restrict its scan to just that type and its methods, ignoring all other types/methods and thereby preventing their metadata from being cached by .NET.

(Note: WebSyncMethodContainer can be defined multiple times per assembly, once for each type containing WebSync methods.)

We highly recommend that you use this approach, especially in production systems and reusable extension class libraries. There is no reason to have unnecessary memory consumption, especially when that memory could be used to increase concurrency :)

Tags:

WebSync 3.0.2 Released

by jerod.venema 22. June 2010 20:17

Well, they just keep coming! We've got a new release ready for you. WebSync On-Demand customers, simply adjust your script files to point to ?v=3.0.2 to take advantage of the fixes and performance improvements. WebSync Server customers, you can grab a new copy from our downloads section, or for those of you who've made a purchase already, you can now easily grab the latest version by simply logging in to the portal and going to the "Order History" tab where you'll find a link to download the latest copy of your particular version of WebSync.

Overall, this release can be summarized as a few performance enhancements (some through a new feature, the "targetedScan" web.config entry) and a few bug fixes. The total list is as follows:

  • A new "targetedScan" web.config option for WebSync initialization has been added; using this feature can help reduce initial load time and memory usage, and it's highly recommended for production setups. It's used in conjunction with the new WebSyncMethodContainer attribute, which allows you to specify which assemblies and classes WebSync should analyze.
  • Added performance tuning scripts for machines hosting WebSync Server
  • Added auto-caching enhancements for the JS client to improve load time, especially under HTML5 postMessage scenarios
  • Added domain name sanitization to the PHP publisher so regardless of where the domain name is set, it's cleaned up properly
  • Fixed a few bugs - core serialization with un-matched curly or square brackets within a string, reconnect events after a network failure, and a subscribers re-subscribe issue.

Happy coding!

Tags:

WebSync 3.0.1 Released (That was Quick!)

by jerod.venema 17. June 2010 04:16

Well, as always, we release a product, and the floodgates are opened :). Thanks everyone for your feedback! We've now released WebSync 3.0.1 (that was quick!).

This release adds a few features, updates the documentation, and fixes a bug or two. Here's the list of changes:

  • Added Silverlight components to support the "Subscribers" and "ReturnData" extensions (thanks Santiago!)
  • Added an additional example demonstrating the use of the "Subscribers" and "ReturnData" extensions from a .NET environment
  • More documentation of use of extensions and how they're created
  • Removed a conflicting library reference that was causing problems for VB applications running on .NET > 2.0
  • Fixed an issue with event handlers inside partial classes
  • Made the "Before" events fire for cascaded events (see below for details on this one)
  • The "Community" edition now supports SSL; you asked, we listened :)

There have also been a few minor updates to the online tutorials for WebSync 3 to fix some inconsistencies (thanks Troy!)

Regarding the "Before" events: in all previous versions of WebSync (including WebSync 2), certain events would only trigger an "After" event to fire. For example, when a user disconnected, the "AfterUnsubscribe" would fire, indicating that the users had been disconnected. The reason the "Before" event didn't fire was that these events *cannot* be cancelled. You can set "Successful" to false all you want, but once the user is gone, they're going to be unsubscribed.

As a result, it was possible to write code that you would *think* would work, but wouldn't, such as detecting a "BeforeUnsubscribe" in order to mark a user as unavailable. This has now officially changed.

With WebSync 3.0.1, the "Before" events will fire for *all* actions taken by WebSync, and a flag called "Forced" will be set to true if you cannot prevent whatever action is occurring from continuing. This gives you the information you need to determine if you can prevent the action, and *all* events now follow the same model, firing both a "Before" and "After" for every action that is taken on the server.

This should not be a breaking change, since these events were not firing before, but it is something to be aware of.

Tags:

WebSync 3 Released!

by jerod.venema 10. June 2010 19:00

Greetings, WebSync Patrons!

Well, we now officially have updated to a new website, and...after many months of hard work...

I'm pleased to announce the release of WebSync version 3.0!

In this release, you'll find:

  • Security enhancements in WebSync Server
  • Performance improvements
  • A new, much more powerful .NET client
  • A more powerful, easier to understand WebSync Server API
  • Support for custom extensions (keep an eye on our blog for more about this one!)
  • A brand new Silverlight client, written in 100% managed code - no more JavaScript bridge!
  • Support for the Microsoft Azure platform
  • An improved JavaScript client, with more support for HTML5 and even better cross-browser capabilities
  • Way, way more documentation!

...and much more! Keep an eye out on our blog for further updates and information, and as always, feel free to drop us a line via our Google Group if you have questions, thoughts, or just want to chat.

For those of you considering upgrading from WebSync version 2, you can check out our migration guide which should help you make the transition smoothly. Don't worry though, we're still supporting you guys too!

Happy coding!

Tags: