Re: Same question - Why use a DataTable in ASP .NET?
- From: Arne Vajhøj <arne@xxxxxxxxxx>
- Date: Mon, 11 Aug 2008 22:21:02 -0400
jehugaleahsa@xxxxxxxxx wrote:
Imagine you are pulling out about 20 DataTables per user in an
application. Even if I pull out one record per user, that is 20
records overall. If I have 30 users, then I have 20*30 records. More
realistically, I will have a lot more records active per session. If
our applications have any major loads, it will be a lot more than 30
users. When a good deal of memory is consumed, the web server starts
paging a lot more. We might even need to get a database server to
handle our session data. For small web applications that don't get
many hits, it is fine to use DataTables willy nilly. When you write
software that is meant to work for enterprise applications that may
have millions of hits a day, they are a huge risk.
> You forgot another option (5) not at all. I don't think these are the
> same question. There are definite differences between storing an
> integer and storing a 500B DataTable. I guess I pulling from my
> experience making high load web applications. I have also made low
> load applications. Unfortunately, once you start thinking "high load"
> it is hard to ever go back.
There is a small company that stores a bit of data and have a few
hits per days that allegedly stores all data in memory.
It's name is Google.
Look at my reasoning above. I don't want to write software assuming
that it will only be used in an environment with a 100 users. There is
a big difference being able to afford memory and having a system
capable of supporting it. There is little point in 10TB of hard drive
space if the operating system can only manage 4GB page files. No
operating system I know of can support more than a few GB of RAM. In
other words, a database would have to be the back-end and that can be
costly in terms of licencing and support.
"a few GB" ??
A p595 can take 4TB.
OK - that will not run ASP.NET, but you can get a SuperDome with 1 TB
that will run Windows.
All I am saying is that in large-scale web applications, the better
you can manage to reduce memory requirements, the shorter you can keep
memory alive on the server, the better you will be. We have a rule
where I work - "Don't store anything you can retrieve otherwise." In
other words, if you have a primary key, store it in the session, not
the record itself. If you have a parent record foreign key, store it,
not the child records. And so forth...
Other find that adding more memory and caching is providing much
more bang for the buck.
Obviously the usage pattern has some impact on the optimal decision.
Arne
.
- Prev by Date: Re: CSV(comma separated values) files
- Next by Date: Re: CSV(comma separated values) files
- Previous by thread: Re: Why NetworkStream ( Newbie )
- Next by thread: Suggestion
- Index(es):
Relevant Pages
|
Loading
