I'm learning system design at the moment and have really hard time getting something: say I have to design a micro-service system and have very high load/bandwidth/whatever, so I will need something like this(multiple load balancers/servers/etc):
check here
But how should exactly load balancers structure look like? My thoughts are like this: One primary(like API gateway?) -> (n) secondaries -> servers/databases
But the part that I really don't get in the whole story is... how on earth does this one(it can't grow infinitely big after all) server(the API gateway/Primary load balancer) will be able to handle the whole load? Because after all, all the traffic will come through it, in and out... What am I missing here, please?
Related
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 would like to write an upload system (photos, videos,...), which could be scaled and perform well even under heavy traffic.
I am a .Net developer therefore I am more interested in using .Net technologies to achieve this. But I am also open to other technologies that I could use for this project.
I am also thinking about Azure OS from Microsoft, If I use Azure then I probably would not need to be worried about anything, right ? it will scale itself automatically and I probably would not need to program that part, but its closed source and they can raise the prize at any time.
I am absolutely new to load balancing therefore I don't know where to start? I need to decide a system like www.flickr.com
Any ideas folks ?
Thanks.
I would look into a messaging queue like MSMQ.
I've been using PyAMF to write a backend for a flex app that will request different groups of hundreds of different images depending on what the client needs. I have been using the "simple_server" WSGI server that PyAMF supplies while developing the flex code. Now I'm ready to write a robust backend that will be able to pull images from a mySQL database and send them as fast as possible and as efficiently as possible to many concurrent clients.
The PyAMF documentation is great because they supply many examples to follow, however I am confused about what kind of backend I am trying to create.
Do I want a SocketServer or a WSGI server or something like Twisted or web2py or Tornado? Are these even all different? :) Should I be using Apache modules instead (mod_wsgi or modjy or mod_python)?
I realize that this probably touches on many open debates, so maybe you could just point me to any good summaries of these debates?
Its great to have so many options, but how do I choose?
The short answer is, of course, that it depends on the requirements of your project.
How many concurrent connections is "a lot"?
How much programmer time can you throw at the problem?
How much hardware can you throw at the problem?
...etc...
If you plan to have lots of concurrent clients, it's hard to beat Twisted in the Python world. However, you'll have to deal with your database asynchronously to avoid blocking, and depending on how complex your database interactions are, this can be a bit of a pain. You're basically limited to either using twisted.enterprise.adbapi or coming up with your own twisted-ORM integration.
If you'd rather have "easy" database code (i.e. you want to use an ORM), you're better off going with a (TurboGears/Pylons/plain wsgi) project, probably hosted using Apache and mod_wsgi. This can be a pretty scalable solution, and you get a lot of stuff for free using these frameworks, but it may be more than you need.
I would avoid using one of the many plain python wsgi servers out there (wsgiref, paster, etc.) in production if you really want high performance.
Good Luck!
We receive 5-10 improvement requests each day from our customers. Some of them are good, and some not so good. I can easily pick out the ones that I agree with, but I'd like a good way to organize the rest, so if we get a lot of similar requests we can prioritize those appropriately.
We have a large backlog of good ideas, so a request usually won't get added to the work queue unless we see a strong demand from customers. This makes it impractical , so it doesn't make sense to track them with our current work item tracking (TFS). The main goal of organizing them is so that we can see where the demand is strongest, and we can determine which features are most important to our users.
Any suggestions are welcome.
I've seen small applications that allow people to add requests and anyone can vote on them. This would show you what people using that particular system are most interested in - although depending on implementation it can be very susceptible to gaming. Look into something like UserVoice. They probably do most of the work for you.
Use a StackExchange site for letting your user's create and vote on their priorities. Another alternative would be using something similar, like UserVoice, though here on SO we've found that the SO platform seems to work better.
You might also want to compile a set of potential feature requests and use something like SurveyMonkey, Vovici/WebSurveyor, or even Google Docs Forms to collect information from your users on which items they would like to see.
Guys, I want to build an e-commerce site on asp.net. My query is: when two users simultaneously buy something, how would the two records get inserted in my database? Would there be a lock? Can anyone explain how this would be or can be handled.
Also, I want to handle peak traffic and also control the average data allotted to each user. I am thinking of using a plug-in. Any suggestions here?
Just a thought but if your just starting a new online store its highly unlikely you'll run into any problems like this for some time?
Secondly, Databases take care of themselves and your web server does all the work of handling traffic and allocating resources. You shouldn't be doing this at a web code level.
The RDBMS handles the locking for you.
Maybe a better solution is a free ecommerce solution, as it'll have a lot of optimisation for large traffic already. Is there a specific reason not to use one of the many solutions already available?