I've got a reasonably-sized ASP.NET MVC/WebApi web application (~100KLOCS) that is creaking a bit under the load (about 1MM requests / day). For instance, a page typically takes 2-3 seconds to load, which is a good deal off from optimal. As I've started looking around for possible bottlenecks, I can't help but notice that Ninject, my IOC container, is rated the slowest by a very healthy margin:
http://www.palmmedia.de/Blog/2011/8/30/ioc-container-benchmark-performance-comparison
https://github.com/ninject/ninject/issues/84
Has anybody else been in this position and tried replacing Ninject for something else, e.g., LightInject, SimpleInject, or something of that ilk? Was it worth the effort? Ninject seems to be the most popular, with lots of community and framework support, and I'm not at all eager to get myself hung out on a project that's going to end up being unsupported. Beyond that, I'm not sure how test to see whether, in a real world application, the IOC container's performance will even get noticed.
Anybody out there have any real-world stories or scars worth sharing? Or suggestions about how to tell if Ninject is even a bottleneck?
I know I am a little late to the game with this question, and I'm sure you've already come to some conclusion, but this is something I find myself asking quite a lot lately. Ninject is certainly not the fastest, but it is (in my opinion), the most flexible and extensible framework I have ever used, and it is an absolute joy to work with. I have never run into an IoC problem that I couldn't resolve with Ninject.
It's a trade off really. When I am working with a client where flexibility and extensibility is key, usually internal facing line of business apps, I use Ninject. When I'm working on small focused components where performance is key, high volume external facing web services for example, I use something faster like SimpleInjector. However, I have time and again found it lacking when I need to do something more advanced, and end up replacing it eventually. As I adapt my methodologies to a micro-service style approach however, I have begun to see more value in smaller frameworks.
You would see a performance increase it sounds like with the type of volume you're seeing. But the perceived value of that performance increase is dependent entirely on how much value you place on flexibility and the other capabilities that Ninject Provides.
"Worth it" can only be decided by you. Have you run a profiler on your site to see where the worst bottlenecks are? It might not even be Ninject that's your worst offender.
Certainly, anywhere you can shave some time off will be worth it for many people. But a lot of it depends on your usage. For instance, if you're generally injecting only a few objects with a shallow dependency graph, you probably won't see much benefit. But, if you have deep dependency graphs with hundreds of objects, then you might see a lot of benefit.
SimpleInjector is not likely to be abandoned soon, as the primary developer is a well known guy.
StructureMap is another good choice, although it's middle of the pack in performance, it's well supported and has a good community.
Anybody wandering by this question again, might want to give DryIoC a try as well. Performance closer to SimpleInjector, but a bit more extensible. MS actually uses it for a few of their back end services, Azure Durable functions to name one.
Related
I'm one of those classic native programmers that has spent most of his past with .exe's and .jar's. As of the past year I've thrown my self into the world of web frameworks and technologies that seize to impress me. As of the past 1½ month I have fallen In love with Go because of it's strictness, and also how 'stand-alone' it seems to be. So now to the real question...
Go app engine application, why do we need this?
What is the difference and reasoning to choose a wrapped application (framework)?
I assume its purpose is to load some of the communication off the application to the wrapper, but sadly I can't seem to figure out (through documentation and discussion) what the specific purpose behind this modulation is.
Best regards and cyber high fives in your direction!
These really are two different questions.
1. Why GAE?
It's up to you. GAE provides cloud-based hosting that you pay rental to use. It's a bit similar to Amazon Web Services. Your Go app would be uploaded to GAE, where it provides your web service and your users can do lots of wonderful things. Meanwhile you never need to know which actual server is doing the serving at any given time - the app can migrate across their servers dynamically. GAE provides a high uptime and a low effort for you in keeping the server secure, backed up etc. It will also be elastic to cope with surges in load.
You may instead prefer to rent a private server (e.g. at Rackspace) or just a virtual machine. You'd perferably need to be a Linux expert (get lots of help at Serverfault) and you'll have to do the backup, firewall etc all yourself. It may cost (much) less. Or more.
2. Choosing a framework?
The net/http API allows you to write HTTP server code to do pretty well anything you want. But you have to do quite a lot of hard work. At the opposite extreme, frameworks like Revel make rapid server development possible, as long as it does the things you want of it. If you stray into functionality beyond what it offers, you might have to do quite a lot of digging to find out how to extend the framework.
Other interesting toolkits include Gorilla, Gocraft Web and Goji. In terms of complexity, these sit about halfway between Revel and basic net/http.
To answer your second question, here are some pros and cons of using a framework (e.g., revel) vs. something simpler like a toolkit (e.g., gorilla)
In general, the pros of using a framework are:
it provides a lot of sub-packages to handle important web-related sub-tasks like templating, generating data in specified formats like json or xml, query escaping, etc.
it handles boilerplate http handling
it (hopefully) enforces best practices like escaping strings
it helps you manage complexity by enforcing a consistent design pattern in the way you handle requests
Cons of using a framework:
frameworks tend to be "opinionated," meaning you have to buy into their general philosophy and understand their core concepts before you can make use of them; for a lot of frameworks this can be quite a bit of mental overhead
extra layer of abstraction, meaning you're another step removed from what's really going on, and there will be more stuff to understand and debug if something goes wrong
it can be brittle and hard to do something that isn't a standard use case in the framework
future maintainability: most frameworks don't tend to have a super long lifespan. Django and Rails have been around for a long time, but there's a massive graveyard of frameworks that came before them. Hindsight is 20/20, but it's hard to pick the right horse from the outset.
Recommendation
It's hard to make the call upfront. So much depends on the specifics of your problem, but I'd say in the case of Go, opt for the simpler option. Much of the value-add of frameworks in other languages is the fact that they contain useful sub-packages that handle important tasks, but Go already contains a lot of these in its standard library (e.g., encoding/json, net/http, net/url, text/template). I've built a fairly sophisticated web app using just the Gorilla toolkit and the go standard library, and it's been amazingly good, and the best part is, it's incredibly easy to understand what the code does and I can explain it to someone else without requiring them to first read through the massive About page of some third party framework.
If you want to get a sense of how other people use Gorilla, you might try looking at real-world usage examples. Compare that to how people use more sophisticated frameworks and pick whichever you like better.
I'm looking into setting up a fairly large scale image library site. I'm looking at CodeIgniter for the framework as I hear it's easy to work with and quick. What I'm looking for help on is the server set up. I've been speaking to a company about getting hosting set up as its's not something I've had much experience with.
I know a Content Delivey Network is worth thinking about, as is using something like Varnish, but don't want to start building anything only to have to redo it to take this into account.
So my question is this: What's the best way to go about setting this up? Start building the site as efficiently as possible and worry about speeding the server up later or is it something that needs sorting up before anything's built.
I recommend building a working site to meet your most basic requirements. Don't worry about features or requirements that are so far off they may never materialize. You can always refactor and improve performance, but requirements and priorities often change, especially once you have something to work with and people are actually using your site.
Having to constantly change/improve working code is often better than doing lots of planning up front, only to end up realizing later that you made a wrong assumption and have to make major changes on a code base that never worked. This is basically Agile vs Waterfall.
If you like PHP, CodeIgniter is a quick way to get started. The most important thing is to be sure to follow conventions and be consistent so that you can easily make major changes without worrying about breaking everything, or having to maintain lots of documentation.
I wouldn't worry about Varnish yet. CodeIgniter has lots of caching options built-in. You won't have millions of users over night, so if you find your growth trajectory going vertical, you can always re-align your priorities at that point. Also, explosive growth is usually tied with people giving you lots of money, so you have more options on solving that "problem".
I would start out with a CDN, as it seems like an essential part of your site. It will largely address image backup as well. Just be sure to comparison shop, because CDN services vary quite a bit. Also, for simplicity, you may want to look into origin-pull.
I have recently made the shift to a framework called the Yii Framework. Really is good to be working on a framework, solves lot of mundane work. I believe the framework will provide me the platform to build a great site but a senior developer keeps asking me these questions.
How many concurrent users can the site handle?
Is the site scalable?
What is the performance level of the website?
If you were to answer those questions about your project how would you do it?
and also how would you tackle the scalability issues once and for all.
P.S. Any references i could read upon will be greatly welcome.
Scalability is not a hole that one can plug. It is a very broad and generic topic in itself. One of the best approaches I've seen is that of youtube
while (true)
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
Having said that, database is usually the bottleneck in most of the web applications and the choice of web framework doesn't matter much. Things like number of concurrent users and performance levels will be sufficiently large for most of the frameworks.
While this answer is quite late, I hope it helps you in your future projects.
You should not look at scalability as a bandaid or a one time fix.
As the usage of your application changes, your scalability requirements will change and evolve. Also, there is no silver bullet for addressing scalability. It is a mix of various approaches like caching, replication, distribution, performance tuning, hardware upgrades etc. You should choose from those based on the context of "what you want to scale" and where will you get maximum bang for the buck!
check out this link
http://sevenoct.wordpress.com/2013/07/04/scaling-applications/
which has some good information about scalability and how not to fall into traps of "sought after" scalability mantras
Right now I'm not sure...
I'd say yes. I'm using it. I know for a fact that Universal are using it on some of their (thousands of) sites. I will add some caveats, however:
There are serious problems with setting it up, especially if you want to debug into the libraries.
The helper functions favour prototype, as opposed to the more modern jQuery. This is changing rapidly, however.
The documentation is a bit chaotic, again the Castle Team are working on that.
I'm not guaranteeing every last "out-there" feature works, but the point of the system is actually to keep it simple.
Compared to vanilla ASP.NET, it's an absolute joy. I assure you that you won't miss viewstate.
We have been building a fairly large application with it for the past year and a half. Its been nice not to have to deal with the old ASP/Page based model and use the better Model/View/Controller design pattern.
To get the new stuff you really need to work off the trunk of development because they don't do releases very often. We have a lot of tests that get the framework involved so when an update in the framework breaks something we depend on we know about it immediately.
If you have to work in .NET this beats the heck out of the alternatives.
There is an overview on the monorail forum: http://forum.castleproject.org/viewforum.php?f=6
I'm using it for an application and haven't had any big issues with it.
The biggest problem is indeed find good documentation and examples.
I've had no problems setting it up. Julian, I don't think it is constructive to say things like "serious problems" without any further clarification or example.
Debugging into the libraries is trivial. Because it's open source, you can debug into the whole thing.
I've been using MonoRail for production for ages on many projects, as an employee, as an indie contractor, and for non-work related sites.
I know I'm biased on that, however I can whole heartedly promise that my positive usage experience is what lured me into contributing to the project, not the other way around.
This is a broad question, so let me narrow it a bit. I am a graphic designer entering the world of web design. I'm not totally green in this field, but I know enough to know that I have a lot to learn. From friends and from posts on this site I realize there is often a harmful disconnect between design and development.
I'm getting ready to place a client log-in/password "portal" on my website. Nothing fancy, just enough to provide some sound mind for my clients and a space for secure download of imagery. I am only handling the look and feel of this one, nothing more. What potential pitfalls should I know about, on my end, to avoid making the development end hairy?
And of course any other nuggets of wisdom are appreciated too. Thanks!
Perhaps the worst mistake that many designers make when working with developers is to assume that developers aren't creative, and that we couldn't possibly have any good ideas or inputs into the design. The fallacy of this is obvious because what we do all day, every day, is create things. It's taken for granted that designers can raise bugs against developers when our code doesn't represent the design exactly, yet many designers get very touchy when we raise suggestions about how their design could be improved even in minor ways. Sometimes the suggestions may not be suitable, but occasionally you might be able to improve your design.
In addition, I have frequently found that designers under-estimate the capabilities of developers to achieve what they want, so will sometimes suggest a simpler alternative. By opening up the dialog and giving a couple of options like a minimum one and an ideal one, you might be surprised that you can have elements of the ideal one, or all of it, or even something better as you discuss what actually can be achieved (sometimes what seems hard to achieve to a designer seems easy to the dev, and vice versa, because they are different disciplines). Of course the converse is true and you might be aiming too high, so you need to find that out as well.
In summary - you're absolutely right that any disconnect between design and dev is detrimental both to morale and the final product. So talk to the devs as soon as you have initial designs, and keep a good two-way dialog open.
I am a web developer, so I'm answering this from my viewpoint. There is really no serious pitfall as long as developer and designer understand each other. One tries to make websites look as attractive as possible, while the other tries to make the look of the website as close to the design as possible.
So when I'm asked to do the impossible, (like replacing the browser's default scrollbar with an animated image of a cat) I'll just tell the designer that it can't be done, the reasons for that, and suggest possible alternatives (Flash ?). After that being said, I expect the designer to understand and cooperate with me to choose the best alternative, not suddenly turning into grumpy mode or something.
A little basic knowledge of the developer's work would help, too.
Some ideas that may smooth the process :
Talk to the developers directly and ask if they have any specific requirements. Different platforms have different needs and requirements. Communication is important.
Get the basics of good HTML and CSS down. There are many references but you can try A List Apart as a starting point.