Holding those connections really tight.



  • So I work on an app that had the misfortune of having consultants "fix" it (before I got there). But first, let me give some background to none asp.net people. SessionState is an area used to store things accross requests; by default it is stored in the app server's ram. It uses a key (string), value(anything) system. The value for a given key is unique for each user; because of this using SessionSate is generally not recommended as it makes the app difficult to scale (it's hard on memory).

    The consultants made extensive use SessionState, they put EVERYTHING in there. There is literally not one variable that doesn't go into sessionstate. And when I says EVERYTHING, I really mean it. They also had the bright idea of storing all the database connections they use in SessionState. Basically, each user has two connections that will never be closed, well not at least until they are logged out a mounth later...

    Good thing our server doesn't crash once a day... oh wait...



  • I'll bet this app exhibits interesting behavior when you right-click on a link and choose "Open in a New Window" and then proceed to interact with both browser windows.



  • @Jaime said:

    I'll bet this app exhibits interesting behavior when you right-click on a link and choose "Open in a New Window" and then proceed to interact with both browser windows.



    Kinda... there are no links (yes, it's a web app with no links)... :'(



  • @this_code_sucks said:

    using SessionSate is generally not recommended as it makes the app difficult to scale (it's hard on memory).
     

    1. is there a way of disabling it server-side? i.e. refuse to run code that uses SessionState?
    2. what's the alternative (in .NET) and is this now recommended "best-practice"?

     

    I only ask because I know of PHP's session ID stuff, and I also know it's possible to blacklist certain PHP statements. Just wondered if it's possible to do this in .NET



  • @Cassidy said:

    @this_code_sucks said:

    using SessionSate is generally not recommended as it makes the app difficult to scale (it's hard on memory).
     

    1. is there a way of disabling it server-side? i.e. refuse to run code that uses SessionState?
    2. what's the alternative (in .NET) and is this now recommended "best-practice"?

    I only ask because I know of PHP's session ID stuff, and I also know it's possible to blacklist certain PHP statements. Just wondered if it's possible to do this in .NET



    You can disable sessionstate, but I'm pretty sure that would break the app; It's a mess. Best practice is to design the UI in a way where you don't need state/have a minimal amount of values in the query string. Next resort is to use ViewState which is similar to POST in php, but different... it's one big hash. Of course, if appropriate you can use the actual values in the form elements. You also can use cookies, but that's a last resort for reasons you already prbly know.

    I usually manage to make do with just one id in the querystring, I almost never use ViewState, and use SessionState even more seldomly. When I do uses session state, I usually just put a reference id instead of an actual object. 



  • @this_code_sucks said:

    You can disable sessionstate, but I'm pretty sure that would break the app; It's a mess.
     

    yeah.. figured that last bit. Bit late in the day now, but was just wondering if design considerations could state "SessionState is disabled - the code CANNOT rely upon it".

    @this_code_sucks said:

    Next resort is to use ViewState which is similar to POST in php, but different... it's one big hash

    That the thing that bloats a page with a massive hex field? I have encountered it, yes.

    @this_code_sucks said:

    I usually manage to make do with just one id in the querystring

    Ditto, or have that value stored in a cookie client-side. Erm.. I'm explaining PHPSESSID. I'll stop now.

     



  • @Cassidy said:

    @this_code_sucks said:

    You can disable sessionstate, but I'm pretty sure that would break the app; It's a mess.
     

    yeah.. figured that last bit. Bit late in the day now, but was just wondering if design considerations could state "SessionState is disabled - the code CANNOT rely upon it".

    @this_code_sucks said:

    Next resort is to use ViewState which is similar to POST in php, but different... it's one big hash

    That the thing that bloats a page with a massive hex field? I have encountered it, yes.

    @this_code_sucks said:

    I usually manage to make do with just one id in the querystring

    Ditto, or have that value stored in a cookie client-side. Erm.. I'm explaining PHPSESSID. I'll stop now.



    Actually, if you really understand the asp.net event model and you don't use tellerick controls that viewstate bloat won't usually happen in the first place, even with it on by default.
    Pro-tip: If you do your intitializations in the Page_Init event, you don't get bloat. Problem with asp.net is most people who use it don't actually know how to use it.



  • @Cassidy said:

    @this_code_sucks said:

    Next resort is to use ViewState which is similar to POST in php, but different... it's one big hash

    That the thing that bloats a page with a massive hex field? I have encountered it, yes.

    That's view state. Different thing altogether.

    @Cassidy said:

    @this_code_sucks said:

    I usually manage to make do with just one id in the querystring

    Ditto, or have that value stored in a cookie client-side. Erm.. I'm explaining PHPSESSID. I'll stop now.

    That's how ASP.net session state works by default. There is a config option to store it in the URL as a virtual directory, or you can roll your own session state provider if you're really ambitious.



  • @Jaime said:

    That's how ASP.net session state works by default. There is a config option to store it in the URL as a virtual directory, or you can roll your own session state provider if you're really ambitious.



    I think you might be confusing the sessionId with the actual data



  • @this_code_sucks said:

    Actually, if you really understand the asp.net event model
     

    I'll freely admit I don't.

    @this_code_sucks said:

    Problem with asp.net is most people who use it don't actually know how to use it

    I'll freely admit the useless twunts responsible for building our company webshite fall into this category, hence my hatred of viewstate:content ratios of Pareto proportions.



  • @Cassidy said:

    @this_code_sucks said:

    Actually, if you really understand the asp.net event model
     

    I'll freely admit I don't.

    @this_code_sucks said:

    Problem with asp.net is most people who use it don't actually know how to use it

    I'll freely admit the useless twunts responsible for building our company webshite fall into this category, hence my hatred of viewstate:content ratios of Pareto proportions.



    You should look into asp.net mvc. It's great, especially for public facing content sites. The good thing about it is that it's a little more difficult to get it to work at all if you don't know what you're doing. Where as asp.net webforms was made especially to make things easy for programmers who don't understand http.



  • @this_code_sucks said:

    @Cassidy said:

    @this_code_sucks said:

    Actually, if you really understand the asp.net event model
     

    I'll freely admit I don't.

    @this_code_sucks said:

    Problem with asp.net is most people who use it don't actually know how to use it

    I'll freely admit the useless twunts responsible for building our company webshite fall into this category, hence my hatred of viewstate:content ratios of Pareto proportions.



    You should look into asp.net mvc. It's great, especially for public facing content sites. The good thing about it is that it's a little more difficult to get it to work at all if you don't know what you're doing. Where as asp.net webforms was made especially to make things easy for programmers who don't understand http.
     

    +1

    I've always refused, as much as humanly possible, to touch anything using WebForms.  But working with MVC3 is a delight.  It's actually possible to design a web application that is sane with it.

    But you're right, you kinda have to know how HTML, HTTP, etc. work if you're using MVC3.  Not good for drag-and-drop "developers."

     



  • @this_code_sucks said:

    You should look into asp.net mvc
     

    Possibly if I was doing web-dev still, but

    • I grew up in the Unix world, so perl/bash/JS/java are more my preferred weapon of choice,
    • most lil projects I do tend to be a bit of PHP hackery - due to familiarity with those languages and LAMP stack
    • most web stuff I do these days involve dropping & modding some COTS (Wordpress, etc).
    Probably going to regret saying this, but at this stage of life investing time and effort into .net stuff won't provide me with much in the way of returns.


  • @ShatteredArm said:

    @this_code_sucks said:

    @Cassidy said:

    @this_code_sucks said:

    Actually, if you really understand the asp.net event model
     

    I'll freely admit I don't.

    @this_code_sucks said:

    Problem with asp.net is most people who use it don't actually know how to use it

    I'll freely admit the useless twunts responsible for building our company webshite fall into this category, hence my hatred of viewstate:content ratios of Pareto proportions.



    You should look into asp.net mvc. It's great, especially for public facing content sites. The good thing about it is that it's a little more difficult to get it to work at all if you don't know what you're doing. Where as asp.net webforms was made especially to make things easy for programmers who don't understand http.
     

    +1

    I've always refused, as much as humanly possible, to touch anything using WebForms.  But working with MVC3 is a delight.  It's actually possible to design a web application that is sane with it.

    But you're right, you kinda have to know how HTML, HTTP, etc. work if you're using MVC3.  Not good for drag-and-drop "developers."



    I def like working with MVC3 a lot better, BUT webforms still has its advantages. For example, if you are doing an internal application that is mostly form based, especially if you use ajax to change the form mid stream, it is so much quicker. UpdatePanel rules. Now of course there are always exceptions, if you have a bunch of different forms that share elements, MVC3 comes back superior again. It's really hard to share form element in webforms.

    I know this is a bit wtfy, but I've always thought it would be awesome to some how integrate MVC3's data annotions with Webforms. Not for a public facing site of course, but for a complex from heavy internal app. But for me the crappiest thing for me about webforms is the garbage script/tags that get thrown in >:(



  • @this_code_sucks said:

    But for me the crappiest thing for me about webforms is the garbage script/tags that get thrown in >:(

    Why? They make development easier, and the end-user never seems them (unless you're doing something very wrong.) I've heard this attitude from tons of developers and frankly I don't get it. Machine code looks pretty fucking garbage-y too, but I never see developers getting annoyed at it and trying to rewrite their app to avoid it.



  • @this_code_sucks said:

    if you have a bunch of different forms that share elements, MVC3 comes back superior again. It's really hard to share form element in webforms.
     

     

    Isn't that what frames user controls are for?  Not that I've had occasion to do a lot with them myself.

     



  • @emurphy said:

    Isn't that what frames user controls are for?  Not that I've had occasion to do a lot with them myself.

    Yeah, although I'm wondering if this_code_sucks is referring to something else...



  • @this_code_sucks said:

    The value for a given key is unique for each user; because of this using SessionSate is generally not recommended as it makes the app difficult to scale (it's hard on memory).
     

    No, it doesn't make the app difficult to scale if it is used correctly.  In fact, you may find it difficult to scale your app without it.  

    Obviously, the best practice is to limit the amount of state data in general.  Open DB connections certainly don't belong there; this is why connection pooling exists - apparently your consultants didn't know about connection pools.  Large objects are bad too - I'm sure people throw excessively large rowsets returned from queries in these things at times.    It should be small bits of state data when possible.

    With ViewState, for EACH request, there is the amount of viewstate data transmitted to/from the server and the decrypt/decompress/deserialization and serialization/compress/encrypt that needs to be done.  This is potentially a lot of overhead.  You've saved memory at the expense of CPU usage and more network data transfer.  Sometimes this is ok.

     

    SessionState stays on the server side and you can configure it to go to a centalized memory storage server called the StateServer (like memcached in the PHP world....Facebook makes extensive use of memory based key/value pair databases for speed).  You can also send it to a SQL server, which has its own set of issues too.  (http://msdn.microsoft.com/en-us/library/ms178586.aspx)  You're now just dealing with serialization/deserialization and data transfer over a much higher bandwidth local network segment as overhead.  Less processing overhead per request means less hardware needed to scale.  

    The idea is to make your app able to add or remove application servers without affecting the users sending requests.   ViewState would allow you to do this, but you may compete with page controls filling it with excessive data.  At some point, the overhead of dealing with ViewState will exceed the overhead of dealing with SessionState.  But by that point you're going to have a hard time figuring out that you need to switch to SessionState.

     

     

    mod: added a quote bit because you otherwise it's just a random reply in the middle of nowhere. —dh


  • ♿ (Parody)

    @ooblek said:

    mod: added a quote bit because you otherwise it's just a random reply in the middle of nowhere. —dh

    OK, but was that better or worse than the posts above that quoted way too much.



  • @boomzilla said:

    OK, but was that better or worse than the posts above that quoted way too much.
    Was what better or worse than what?

    It's better now.


  • ♿ (Parody)

    @dhromed said:

    @boomzilla said:

    OK, but was that better or worse than the posts above that quoted way too much.
    Was what better or worse than what?

    It's better now.

    Was not quoting at all better than this?

    @this_code_sucks said:

    @ShatteredArm said:

    @this_code_sucks said:

    @Cassidy said:

    @this_code_sucks said:

    Actually, if you really understand the asp.net event model
     

    I'll freely admit I don't.

    @this_code_sucks said:

    Problem with asp.net is most people who use it don't actually know how to use it

    I'll freely admit the useless twunts responsible for building our company webshite fall into this category, hence my hatred of viewstate:content ratios of Pareto proportions.



    You should look into asp.net mvc. It's great, especially for public facing content sites. The good thing about it is that it's a little more difficult to get it to work at all if you don't know what you're doing. Where as asp.net webforms was made especially to make things easy for programmers who don't understand http.
     

    +1

    I've always refused, as much as humanly possible, to touch anything using WebForms.  But working with MVC3 is a delight.  It's actually possible to design a web application that is sane with it.

    But you're right, you kinda have to know how HTML, HTTP, etc. work if you're using MVC3.  Not good for drag-and-drop "developers."



    I def like working with MVC3 a lot better, BUT webforms still has its advantages. For example, if you are doing an internal application that is mostly form based, especially if you use ajax to change the form mid stream, it is so much quicker. UpdatePanel rules. Now of course there are always exceptions, if you have a bunch of different forms that share elements, MVC3 comes back superior again. It's really hard to share form element in webforms.

    I know this is a bit wtfy, but I've always thought it would be awesome to some how integrate MVC3's data annotions with Webforms. Not for a public facing site of course, but for a complex from heavy internal app. But for me the crappiest thing for me about webforms is the garbage script/tags that get thrown in >:(



  • Since I use Stylish to give quote blocks a light grey colour, I can instantly distinguish them from fresh text, so yeah, a quote-less post that is not directly below the post it replies to is definitely worse than a wall of quote. I also have my monitor portrait, so combine the two and even your example superquote doesn't make me blink.

    Not that people should wallofquote. I frown upon that practice. If you're not suffering from Chrome/CS nor weren't aware you can select-quote easily, then you're just a lazy fuck and I hate you.

     

    In semi-seriousness, I recommend that Alex change the CSS so that blockquote has a lightgrey background.



  • @dhromed said:

    In semi-seriousness, I recommend that Alex change the CSS so that blockquote has a lightgrey background.
     

    Gets my vote, but I don't think Alex reads the forums much these days - many forum suggestions have slipped under his radar.


  • Considered Harmful

    @this_code_sucks said:

    @Jaime said:

    That's how ASP.net session state works by default. There is a config option to store it in the URL as a virtual directory, or you can roll your own session state provider if you're really ambitious.



    I think you might be confusing the sessionId with the actual data

    ViewState != Session state



  • @ooblek said:

    With ViewState, for EACH request, there is the amount of viewstate data transmitted to/from the server and the decrypt/decompress/deserialization and serialization/compress/encrypt that needs to be done.  This is potentially a lot of overhead.  You've saved memory at the expense of CPU usage and more network data transfer.  Sometimes this is ok.

    SessionState stays on the server side and you can configure it to go to a centalized memory storage server called the StateServer (like memcached in the PHP world....Facebook makes extensive use of memory based key/value pair databases for speed).  You can also send it to a SQL server, which has its own set of issues too.  (http://msdn.microsoft.com/en-us/library/ms178586.aspx)  You're now just dealing with serialization/deserialization and data transfer over a much higher bandwidth local network segment as overhead.  Less processing overhead per request means less hardware needed to scale.  



    I said earlier, the amount of data in the ViewState should be minimized as well. You only get those absurdly large viewstates if you do your intitializations in Page_Load. I also think you might be confussing SessionState with Cache. The Cache, NOT the viewstate and NOT the sessionstate is where you can store things to optimize speed/scalling. The difference between the data cache and sessionstate is if you are running low on memory things in the cache will automatically be removed in order of their importance. The cache also stays serverside so it avoids the coding/decoding penalty of viewstate. And if you have a lot of users, but each of them has a lot of time between requests, ViewState is indeed better.... now if each user has a lot of requests per minute that changes things.

    Every app needs to be optimized differently, but devs need to STOP using sessionstate, viewstate, and cookies to cahce thing, that is what cache is for.



  • @blakeyrat said:

    @this_code_sucks said:
    But for me the crappiest thing for me about webforms is the garbage script/tags that get thrown in >:(

    Why? They make development easier, and the end-user never seems them (unless you're doing something very wrong.) I've heard this attitude from tons of developers and frankly I don't get it. Machine code looks pretty fucking garbage-y too, but I never see developers getting annoyed at it and trying to rewrite their app to avoid it.



    You are 100% correct when it comes to internal applications or apps that are for limited users. But for a general public application, all the requests to get scripts can really increase page load time, especially on phones.



  • @emurphy said:

    @this_code_sucks said:

    if you have a bunch of different forms that share elements, MVC3 comes back superior again. It's really hard to share form element in webforms.
     

    Isn't that what frames user controls are for?  Not that I've had occasion to do a lot with them myself.



    Yes, but it's much easier to share model/data annotations. This is because usually, the form is similar but not exactly the same. Often it's less work to make a completly new form than to make the usercontrol flexable enough to deal with all those different situations. Models are much easier to share becuase you can tweak the ui at will. Also, I'm not sure if this "Best Practice TM" but you can also use inheritance to express the subtle differences between two similar models.  


Log in to reply