Is there a way to use protobuf-net to improve viewstate (size and serialization/deserialization speed) or decrease size of data cached in Page.Cache?
I honestly haven't tried. I have looked at cache/session-state, but to be frank view-state is something I've always turned off, or avoided via MVC. So I lack some of the familiarity! I suspect, however, that it is rather key-heavy; with those keys being fundamental to retrieval and not fixed. This makes it very hard to package efficiently as protobuf (which works best when the data is predictable ahead of time).
My gut says "not a good fit". And then it says "meh, horrible view-state is".
Related
I want to compare the performance of some web frameworks (Ruby on Rails and ASP MVC3) but I don't know how to get started... Should I measure how fast each framework renders e 10k long loop or how fast its renders 10k lines of html? Are there maybe programs that can help you with this? Also how can the server load be monitored? Any help is appreciated!
Thijs
With respect, this is an unanswerable question. Is a Porche faster than a Prius? Well, no, not when the Porche is in the shop :-).
The answer depends on what you're trying to accomplish, how you do it, and how you code it. For example, Rails goes out of its way to transparently cache as much as it can, and then makes it trivially easy to cache stuff on your command. Of course there's a way to do the same in ASP MVC3, but is it as easy?
Can you find, hire, and train a suitable team in that knows how to use the framework? What's the culture of the organization (Windows or Unix?). I could write a really fast application in MS-Access and the same application poorly in Rails against a high-performance database and the MS-Access app would win. It's far from a given that an application will be written well, optimized, or whatever.
These days, a well-written application is typically performance bound on data I/O, and if this is the case, then it's which database you use that might matter. The loop-test you propose would test almost nothing, unless you're writing an application that calculates pi to the billionth place, or something.
I am sure there are published benchmarks of application frameworks available, but again, they need to make assumptions about what the application actually has to do.
The reality is that any reasonable framework (which includes both of the two you mention) is likely to be as fast as necessary for most scenarios, and again, what you do, and how you architect and implement it are the far more likely culprits for performance problems.
Once you do choose, there's a great (awesome) tool called NewRelic RPM which works with several frameworks -- I use it with Rails, and it gives you internal metrics at a level of detail that is beyond belief.
I don't mean to be glib, or unhelpful. But this is a little bit of a sore spot for me -- in so many cases people say "we should use foo instead of bar because foo's faster", and weeks go by as bar is replaced by foo. And then there are little incompatibilities. And an unexpected bug. And then, well, for some reason the new one is a little slower. And then after it gets optimized, it's finally just as fast.
I'll step down from my soapbox now :-)
Prior to using ORMs we always performed object caching in our service layer. This gave us the ability to switch between different data layers without having to change our caching implementation.
Nowadays we use both Entity Framework (mainly code first) and NHibernate. NHibernate seems to have much better caching features with several 2nd level cache providers available.
Another problem I am faced with is that for both of the above ORMs we make use of lazy loaded properties. So if we are retrieving an object from the cache we normally have to reattach it to the current ObjectContext/ISession, something we can't really do in our service layer.
So should I really be looking at implementing caching at the repository/data layer; and is it likely that I will find a common solution that will work for EF and NH?
Thanks
Ben
Have you looked at the CQRS pattern? Because caching is policy, I'm suspicious of trying to automate these decisions with a "one size fits all" cache like a second layer cache. E.g., if what you really want to cache is the HTML for your site home page, then a second layer cache is just a waste of memory and an invitation to bugs.
CQRS turns these mechanical considerations into policy decisions. And it's ORM-agnostic.
My experience is that 2nd level cache provided by the ORM will cache the data based on the actual resultset retrieved from the database. This can give you a lot of overhead because the object instantiation and data population is pretty costly.
The advantage is that lazy loading etc will work fine, but big results will still use up a lot of resources when repopulating the objects.
We use a combination of 2nd level cache and the ASP.NET cache in our webapplication because of the costly overhead, which in rare cases saves us as much as several seconds (!), but with the drawback of not being able to lazy load collections or update the entities.
This is based on NHibernate only, I have never worked with entity framework but I'm guessing all ORM frameworks suffer from this.
In a sense NHibernate seems convenient because it leads to less typing, and then propably less errors.
I think NHibernate can be used in every size of application because it is really easy to use (especially with FluentNHibernate) and you it does much work for you like generating SQL
queries, mapping values to objects and so on. Even in typical small applications you need to put a great part of the whole effort on the data persistence layer, so why don't let NHibernate do the work for you?
Best Regards,
Oliver Hanappi
It is tough to judge what you are looking for based on the terseness of your question, as there is really a lot of nuance in an answer to this.
In many ways, as the others here say, it depends on your project and your knowledge of nHibernate. But it also depends on a lot of other factors as well...
If you think your small project might grow into a large project someday that could make a better argument for it as you then have a strong foundation on which to grow.
If your goal is learning nHibernate (or another ORM) then a small project may be the best place to get your feet wet and try it out. (Also try Linq2SQL, and other ORMs as well and go with what you find works the best for you.)
I personally use nHibernate for all of my projects large and small (where possible due to other constraints). But I've also been working with it for a while and a good base of code that I can reuse. So that factors into the time part of an answer. nHibernate has a pretty steep learning curve so if you need something done quick nHibernate may not be optimal.
I hope that helps, if you can refine your question and your goals a little more in your question it will assist the rest of us in getting you some better feedback and ideas to help you.
It depends what you mean by small, and how accomplished you are with Hibernate. I'd find that the extra overhead of getting set up would not make using it a good option on a little project personally. I'd say the same about other frameworks like Spring too, they are far more useful on larger projects with lots of developers.
It's not if you have a strong knowledge of NH, if you have some model generator, if you use some DBMS other than SQL Server.
I think that if you have a DB on SQL server, you're quin in a hurry, you are knowledgeable on LINQ, LINQ2SQL might be a good choice. Fast and RAD.
I agree with Oliver but would add the caveat that it is only easy to use once you know how (and that may take awhile). If you haven't gotten on top of the learning curve and need a simple app, NHib will slow you down; otherwise use it on anything that isn't completely trivial or a throw away! So your simple but effective app has one more sound piece of infrastructure as it scales and adapts to requirement changes.
HTH,
Berryl
Currently I am using HttpWebRequest to pull json data from an external site, and the performance was not good. Is wcf much better?
I need expert advice on this..
Probably not, but that's not the right question.
To answer it: WCF, which certainly supports JSON, is ultimately going to use HttpWebRequest at the bottom level, and it will certainly have the same network latency. Even more importantly, it will use the same server to get the JSON. WCF has a lot of advantages in building, maintaining, and configuring web services and clients, but it's not magically faster. It's possible that your method of deserializing JSON is really slow compared to what WCF would use by default, but I doubt it.
And that brings up the really important point: find out why the performance is bad. Changing frameworks is only an intelligible optimization option if you know what's slow, and, by extension, how doing something different would make it less slow. Is it the server? Is it deserialization? Is it network? Is it authentication or some other request overhead detail? And so on.
So the real answer is: profile! Once you know what the performance issue really is, you can make an informed decision about whether a framework like WCF would help.
The short answer is: no.
The longer answer is that WCF is an API which doesn't specify a communication method, but supports multiple methods. However, those methods are normally over SOAP which is going to involve more overheard than a JSON, and it would seem the world has decided to move on from SOAP.
What sort of performance are you looking for and what are you getting? It may be that you are simply facing physical limitations of network locations, in which case you might look towards making your interface feel more responsive, even if the data is sluggish.
It'd be worth it to see if most of the latency is just in reaching the remote site (e.g. response times are comparable to ping times). Or, perhaps, the problem is the time it takes for the remote site to generate and serve the page. If so, some intermediate caching might be best.
+1 on what Isaac said, but one thing I'd add is, if you do use WCF here, it'll internally use the HttpWebRequest in most places, so you're definitely not gaining performance at all. One way you may unintentionally gain in performance -- however -- is in how WCF recycles, reuses, pools, and caches most transport objects internally. So it ultimately goes back to Isaac's advice on profiling.
I've been having a brief look at NHibernate and Linq2Sql. I'm also intending to have a peek at Entity Framework.
The question that gets raised, when I talk of these ORM's is "They can't scale", so can they? From Google I get the impression they're able to scale well, but ultimately I suppose there must be a price to pay, Is it worth paying for a richer simpler business layer.
This is a good question, and IMHO they can scale just as well as any custom DAL. I've only used nHibernate so I will focus only on it and the features it has which can help scale a system.
Lazy Loading - Since it supports lazy loading you can avoid loading any unnessecary items. Of course you need to watch out for the Select n+1 problem however there are things in the system to prevent this.
Eager Fetching - There are various ways to eagerly fetch objects which you might need allowing you to avoid extra trips to SQL.
Second Level Cache - nHibernate has support for a second level cache which can be used to increase the scalability by reducing trips to the DB. There are various backing providers available which give you some flexibility.
Write your own SQL - In nHibernate you can call stored procedures, or provide the SQL query inline that will return your entities. This will let you use your own SQL when the generated sql doesn't cut it. For example eager loading a self joining tree using a recursive query.
Now with that said, I think it is easier to initially tweak a custom DAL layer because your are intimate with its construction and can fine tune it; however, a good ORM will provide plenty of hooks that allow you to optimize quite a bit. You just need to spend some time learning it.
I also feel that if you have a performance critical area of code and you can't get your ORM to work within your requirements then for that tiny area of your application you can custom build your own DAL layer. If you're using a decent design pattern such as a Repository created by a factory, then all you need to do is swap out the implementation of your repository
Hibernate Shards is being ported to NHibernate, which will allow for horizontal scaling.
There are also some very cool hacks like this one to implement sharding.
So the answer is yes, NHibernate can scale, in a persistance-ignorant and fully-transparent way.
It's simply incorrect to say that apps built in an ORM do not scale well. Certainly it has happened before that careless or lazy devs abuse an ORM by writing code that generates horribly inefficient SQL. Building performant apps means understanding something about what all the lovely abstractions actually do under the hood. It does not take much to stay out of this trap however. Using an ORM doesn't mean never opening SQL profiler or NHibernate Profiler.
And regarding the claim that SPs are just a whole lot faster, read this and this. And besides, ORMs (NHibernate, at least) give you pretty easy ways to use SPs if you ever need to.