The Denial of Service Application



  • The Denial of Service Application (DoS) was created by a developer who had created a FoxPro application that was to be converted to an ASP.NET web application.  He was the lead developer of the ASP.NET project.   He knew nothing about web app development.  I will give you a few highlights of what I came to call the DoS application and why I call it that.

    The DoS application has one style sheet that is 13,886 lines long and is 217k on disk.   It is linked into every page on the application.  The main page of the DoS application has a single C# code behind file that is 5600+ lines long and is over 230k on disk. That means that the page and its style sheet is well over 400k not including ViewState. The source code of the main page has essentially no HTML and very little JavaScript, it is all ASP.NET source code.  What I mean is that all layout was done with ASP.NET source rather than standards-based HTML.   There were about 30-40 text boxes (and many other ASP.NET controls totalling well over 150 ASP.NET server controls on a single page.  ASP.NET Ajax was being used and there were update panels nested several deep.  I think that each text box was nested inside its own update panel.  Why would someone do such a thing?  Well this so-called developer was doing a ToUpper conversion on every singleTextBox, not on the client with JavaScript but on the server.  That meant each time he did a ToUpper conversion, there was a postback to the server.  That is why I called his application a Denial of Service (DoS).  That application would literally bring a web server to its knees.    The DoS application is what I would call an ultra-thick client.

    The application was to be used by several hundred widely scattered users.  The application was not doing anything to manage the concurrency of data between multiple users. What I mean is that nothing was being done to lock records or keep users accessing the same record from overwriting each others data. When I asked the developer about this he first said "I thought that ASP.NET would handle it automatically".  When I pointed this out to the manager, he said "I think that there is a very small chance of that happening (multiple users accessing the same record)".   The application was a critical application and corrupted data could result in doing great harm to the individual whose data was corrupted. My response was "if it happens even one time, that is one time too many". My advice shortly before leaving the organization was "dont deploy this application."

    The developer described himself as an experienced developer.  My response was, "if all of your experience is in doing something wrong, what good is your experience?".  



  • @blackweb said:

    The DoS application is what I would call an ultra-thick client.
     

    I like it.

    @blackweb said:

    The main page of the DoS application has a single C# code behind file that is 5600+ lines long and is over 230k on disk. That means that the page and its style sheet is well over 400k not including ViewState.

    Waitwhat?

    It gets compiled to a DLL of some indeterminate size and is not downloaded. Why are you adding the source code size to the total page download size?

    Also CSS is cached.

    Not that a 14,000 line CSS isn't batshit insane, but just saying.

     



  • @dhromed said:

    @blackweb said:

    The DoS application is what I would call an ultra-thick client.
     

    I like it.

    @blackweb said:

    The main page of the DoS application has a single C# code behind file that is 5600+ lines long and is over 230k on disk. That means that the page and its style sheet is well over 400k not including ViewState.

    Waitwhat?

    It gets compiled to a DLL of some indeterminate size and is not downloaded. Why are you adding the source code size to the total page download size?

    Also CSS is cached.

    Not that a 14,000 line CSS isn't batshit insane, but just saying.

     Ok you make a good point about the size of the source file vs. the size of the compiled code.   I am giving you a relative measure of size based upon the size of the source file.   My point is that the .aspx and .cs files are both waaay to freaking big.  In order to determine the actual size of the compiled code you would have to look at a page trace and see how big it is when loaded into the server memory.   For the aspx file, you would have to look at the source code on the browser including the ViewState.   After seeing the size of the files in terms of lines of code and on disk, I didnt even bother looking at how big they were on the server and the browser.   There is such a thing as TMI.  You are right that the .css file is cached.   However, I did not tell you about the rest of the pages on the website.   He linked that massive css file into every page, even those that did not need most of the code in it.   So, lets say an admin role logs in and wants to see an admin page.   He is still going to get that massive .css file.   Yes, its cached but it never should have been loaded to begin with.

     I did ask him why he made such a large .css file.   His response "it seemed convenient at the time".   I think that what he did was build all of the web pages in the designer, then cut and paste all of the generated inline styles into that css file, then patted himself on the back for using .css.   Almost all of the code was absolute size, layout and positioning styles like you get when you drag and drop and then drag page elements into position in the designer.

     From a performance standpoint, the worst thing he did was creating all of those postbacks to the server then attempt to hide them using update panels.



  • This is not a wtf on an embedded device



  • TRWTF: This post is not in the WTF forum.



  • @Sutherlands said:

    TRWTF: This post is not in the WTF forum.

     Heh?


Log in to reply