Value cannot be null. Parameter name: s solution

I recently worked on a project where we were getting the error message below in our log files. This mysterious issue plagued us for weeks and we did not understand why we were getting the error and even how it impacted the user. We only knew that it would come in about 1 of 300 page views.

We were using a custom PageStatePersister and saving Asp.Net Web Forms Viewstate to a database. The error never showed up in the development environment.

We tried all sorts of things to reproduce it and make it go away. After some time trying to reproduce the error we managed to reliably reproduce it locally by doing simultaneous page requests for different web pages. Any request type async/non-async, postback/non-postback would trigger it. For end users it would manifest itself as annoying glitches or hiccups with possible loss of input data.

We finally managed to also locate the error after days of changing one by one line of code back to an older version.

The error was caused by someone having redefined the LosFormatter variable as static in our PageStatePersister.

Changing the LosFormatter variable definition to non static immediately solved the problem and also improved performance.

Exception type: System.ArgumentNullException

Value cannot be null.
Parameter name: s

   at System.Web.UI.ObjectStateFormatter.DeserializeIndexedString(SerializerBinaryReader reader, Byte token)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.Deserialize(Stream inputStream)

Benefits of a schema-less database

A typical argument for choosing a NoSql database (such as a document store or graph database) over a relational database (such as MySql) is that NoSql databases are schemaless and that makes you more agile.

So, what does this actually mean? What are the concrete benefits of being schema-less and how does it actually make you more agile as a developer or as an organization?

In this context we use the term agile not strictly as in Agile software development but more in term of just being faster, more flexible, nimble and adaptable to change.

Here are some of the real world reasons why schemaless makes you more agile:

• When starting a new development project you don't need to spend the same amount of time on up-front design of the schema (which is likely to change several times anyway). Less need for planning -> more agile.  
• Once the NoSql is up and running the developer does not need to know about the database. No need to learn SQL or database specific stuff and tools. Less to know about. Less to learn for new developers -> faster development -> more agile.
• The rigid schema of a relational database (RDBMS) means you have to absolutely follow the schema. It can be harder to push data into the DB as it has to perfectly fit the schema. Being able to add data directly without having to tweak it to match the schema can save you time-> more agile.
• Minor changes to the model and you will have to change both your code and the schema in the DBMS. No schema -> don't have to make changes in two places -> Less time consuming -> more agile.
• With a NoSql DB you have fewer ways to pull the data out -> fewer ways to shoot yourself in the foot -> less chance of being bogged down in problems later (e.g. as unforeseen intricate future queries starts to manifest themselves as performance issues) -> more agile.
• Schema-less -> Less overhead for DB engine -> better performance and scalability -> Less overhead for developers related to scalability -> Fewer devopment obstacles -> more agile. 
• Changes to the DB schema will often break the solution for other developers and they have to keep updating the DB schema locally even if they are working on something completely unrelated. Syncing DB and code as you pull from your source code repository requires extra work and sometime even extra time trying to figure out why your solution don’t work after Git pull. No schema -> Fewer problems with code/schema not being in sync -> More agile development.
• ALTER TABLE operations during deployment can be very heavy on the system and will usually result in downtime. Schema changes in general will break the system when code and schema is not in sync during deployment. No schema -> less downtime -> deploy whenever you like-> more agile.
• Save time when the day comes when you have to denormalize tables because of performance issues. Less overhead related to schema -> more agile.
• You don't have to deal with artificial link-tables (for many to many relations) because it is built into graph databases. -> fewer things to deal with -> easier to modify code/"schema" -> faster development -> more agile.
• Eliminates the need for Database administrators or database experts -> fewer people involved and less waiting on experts -> more agile.
• Less time needed to pick the right datatypes for new database columns -> save time -> more agile.
• Schema-less -> better DB engine performance -> less chance of having to create separate systems to offload the DB because of heavy queries from big reports etc. -> less complicated system -> more agile. 
• Save time writing complex SQL joins -> more rapid development -> more agile.
• Rolling back code doesn't necessarily break the App, you might just not get the data you expect. Easier to deploy/rollback without serious consequences -> more agile.
• As more and more applications/systems use your RDBMS it is harder to change the schema because of dependencies. Change the schema and you might f* up some other system. With NoSql schema changes other systems might not get the expected data but the chance of runtime errors is less. No schema -> less worry about messing up for other systems -> more agile.

In this blog post I have covered only the benefits of schema-free. There are also drawbacks but for the sake of brevity it is not included here. Being super agile might not be the top prioritization for all organizations.

Complex web pages have huge differences in rendering time in different browsers

I recently had the task of optimizing HTML for a web application that was getting somewhat slow. We were seeing big differences between browsers. Chrome seemed to be exceptionally fast. So I went ahead trying to reproduce this performance issue in order to decide where to go ahead with optimization. 

I knew that the web app had lots of nested divs with a lot of inline styling. I was curious to find out what performance penalties this had so I made this client side performance test.

There's a lot of websites that talk about website optimization and they all say you should minimize the payload that has to go over the wire. I could not find much on the topic of speed when it comes to rendering large HTML documents.

Summary of results

My tests show that large DOMs with many nested elements (in this case 7381 divs) can have a huge impact on client side performance. Compared to Chrome, IE9 spent 9-25 times longer rendering the exact same page.

The tests

I programmatically created 3 html documents; A, B and C. They all have nested divs and some styling. They look something like the grid below. It has 1 big square and inside this square there are 9 squares and inside this there are 9 squares and so on. It goes 4 levels deep so there's a total of 7381 divs. Fairly simple HTML document but the DOM is relatively big.

Measurements where done using the HTML documents that are linked to blow. The server was located in the same country and the Internet connection where this was carried out was very good. The browser cache was unprimed. All the divs have fixed size so drawing the layout is pretty easy for the browser. There is no need to recalculate and re-position elements as the page is gradually received.

Test A 
This document has lots of duplicate inline styles just to create lots of bytesize. Each div looks something like this:

<div id="d_34" style="width:34px; height:34px; float:left; dispaly:block; margin:0; padding:0; border:1px solid #FFFFFF; background-color:#bbb">...

Test A document size is 1.1Mb

	IE9	Chrome19	FF13
Typical time until received all bytes	390ms	330ms	339ms
Typical time until DomContentLoaded event fired	2,22s	411ms	1,33s
Typical time until OnLoad event fired	2,43s	408ms	1,34s
Time from all all bytes received to onLoad and DomContentLoaded event fired	2040ms	81ms	1001ms

Test B 
This is just the same as A only with all the inline styles moved out to an external css file. Now each div looks like this:

<id="d_34" class="lvl2">...

Test B document size is 237Kb with an additional 400b CSS file.

	IE9	Chrome19	FF13
Typical time until received all bytes	187ms	178ms	195ms
Typical time until DomContentLoaded event fired	1,02s	227ms	366ms
Typical time until OnLoad event fired	1,18s	210ms	457ms
Time from all all bytes received to onLoad and DomContentLoaded event fired	993ms	49ms	262ms

Test C
This is without any styling at all. Each div looks like this:

<id="d_14">... 

Test C document size is 179Kb.

	IE9	Chrome19	FF13
Typical time until received all bytes	172ms	130ms	160ms
Typical time until DomContentLoaded event fired	468ms	175ms	170ms
Typical time until OnLoad event fired	590ms	140ms	253ms
Time from all all bytes received to onLoad and DomContentLoaded event fired	418ms	45ms	93ms

What does all this mean anyway
From the numbers we see that when it comes to comparing browsers, Chrome outperforms the others. IE seems extremely slow when it comes to rendering this particular markup. Although IE9 is credited for being much faster than earlier versions, it is clearly far behind Chrome for this specific test.

Chrome is particularly fast when it comes to rendering. It only uses about 50ms to render the page which consists of more than 7000 elements. Chrome is faster for all cases (with inline styles, with external css file or even without any styling at all).

The test also confirms that avoiding inline styles on elements will increase performance considerably. The reason seem to be not just that there is fewer bytes to transfer but that it is easier for the browser to parse the document.

Please note that our test is not representative for common web pages or for other web pages for that matter. Browsers use different algorithms and techniques for different operations such as receiving, parsing, calculating layout, drawing etc.