I am getting confused between the functionalities of Workload management and the resource management. Can anyone clarify this with a real life example?
And, as much as i understand by the concepts, Cgroups can be used in resource management, but is there a role of Cgroups in Workload management? if yes, then how?
Thank you!!!
Related
I have an internship and they gave me a project about ms sql in memory database.End of the internship, we loaded database lots of data.
My task is to take any file in minimum time.I researched the topic on the internet especially on microsoft site.But there is no implementation part on the internet.How can I do this task.Can anyone help me?I cannnot understand actually what I need to do?
Actually I understand the concept of in memory database.Microsoft added a new feature into system which is called Hekaton.It increases the speed.
The company asked me that How can we use this feature implementing into our system which can be integrated with erp programs.
They will load into db lots of things.I need to get anything from db while using the in-memory database.How? Where I need to start to implement this?
Hekaton is a solution for very specific problems, so I wouldn't just say "It increases the speed". To make sure your project has a chance to succeed, you should really spend time on understanding what Hekaton is and what problems it can solve. There's plenty of videos available for example in Channel 9, SQLPass.org and Youtube.
If the problem really is just the implementation, there are also code samples available.
MS SQL In-Memory OLTP
MS SQL In-Memory OLTP – Common Workload Patterns and Migration Considerations
Background
Professional Services departments provide add-on services to customers of a product.
A lot of these projects are small (4-10 hours) and need to be turned around quickly. Additionally, these are important projects as they are enhancements that customers rely on for their business.
Some challenges are:
There is a good amount of rework or feature changes as customers often change their mind or make tiny additional request. Aside from the obvious that this is a mangement issue (managing scope creep etc.), the fact remains that often there are minor tweaks that need to be implemented after the project is "live".
Sometimes something breaks for whatever reason and issues need to be handled with expedience. Again, these are in-production processes that customers rely on.
Currently, our release management is very ad hoc:
Engineers manage the projects from soup to nuts, including scoping, customer relationships, code development, production deployment, and project support (for any subsequent issues).
We have dev servers and we have production servers. The servers exist on-site in a server farm. They are not backed up ever, and they have no redundancy because they are not in the colo - they kind of get second class service from operations.
They Engineers have full root(linux)/admin(windows) access to the dev and prod servers. They develop on the dev servers, and when the project is ready, deploy to prod (basically, just copy the files up). When issues come up, they just work directly on the servers.
We use svn for source control but it's basically just check out to dev, work on the project, check in as necessary, and deploy to prod just by copying files up to the server.
The problem:
The problem is basically number 2 above. The servers are not treated with the same reverence by operations that our product servers (in the colo) are treated. We need the servers to be first class citizens for operations. However their proposal is to put them in the colo, which makes them untouchable. If we do that, we will need to go through operations to get projects deployed. Basically it will be the same arduous and painful process that the product engineers go through when releasing an update to our software product.
This would take away all our agility in responding to these tiny projects and the issues that arise that need immediate attention.
The question
How should we solve this problem?
Should we put the servers in colo and just work with the formal release process?
How should this situation be handled?
Any help making this question better is welcome!
The servers exist on-site in a server farm. They are not backed up
ever, and they have no redundancy because they are not in the colo -
they kind of get second class service from operations.
So you want these servers to be self-serviceable by your PS engineers, yet have good redundancy, backup etc without having to go through formal ops processes. Can't you move them from the on-site server farm to the cloud (ec2 or other)? btw, #3 & #4 are accidents waiting to happen but that is not material to the main question here.
This is an old question but sounds very similar to our company in that production team requires a lot of small changes.
I'm having a hard time understanding the question but I'll attempt an answer.
You should not place development servers in the colo because it will slow down your development process. If operations is not able to give you the support you need in development could you designate a developer or bring on someone that can support your teams needs when it comes to server management/requirements. Ideally a build engineer, release manager, or even say a QA resource. Unfortunately it sounds like a political management issue. In that case you need to clearly layout you issues and address them with management. If I completely missed the mark let me know.
I want to host multiple WCF services in windows service but I am unsure if hosting multiple WCF services is an expensive process? Can someone please guide?
It depends on the complexity of the service itself, but generally, they are not resource intensive.
It will also depends of the number of connected clients and requests you will get.
The rule is very simple here. You need to decompose your system requirements into the right level of granularity that minimizes the cost of implementation versus the cost of integration. Too many services and your integration costs will suffer. Too few services and your implementation costs will suffer. My personal experience is that if any service has more than 10 methods you really need to start looking into your design and the methodology you have used to design it like that. Also please note that services with too many methods do not scale that well neither.
I'm working on a new application at work, and a manager is really pushing the concept of a business rules management system (BRMS) and a workflow management system, and I'm trying to figure out the best way of integrating these types of tools.
With regard to these types of systems, I don't know what I don't know, so I'm trying to get other perspectives and information.
The thing the manager is looking for is the ability for business users to change business rules or process flows without the need for developer time (or with minimal developer time).
A BRMS is easier for me to understand when I think about how it would fit into code. It's pretty straightforward, and I can see how the logic could reside completely outside of an application. Since I haven't done much with these types of systems, I would appreciate any info on good products that integrate with .NET, or info on experiences. (We're looking at InRule, Blaze Advisor and ILOG Rules)
What I'm less sure of is the workflow part.
Workflow Foundation makes sense to me, as it's a known, defined workflow that's integrated into application code, but the manager isn't looking for a foundation, he wants a tool that lets business users define and update workflows. Any type of system that allows end users to dynamically create workflows makes less sense to me.
I was asked to look at WorkflowGen as an example of a workflow engine. To me, it looks like it's completely self-contained unless a developer writes .NET code to interface with back-end systems.
I can understand a workflow system that allows users to define specific, limited actions, like "e-mail so and so" and "require so and so to approve," but I have no idea how a workflow system that's supposed to dynamically define application flow can be integrated in to an application, or even how the more simplistic system I just described can display and update back-end data.
I'm pushing for use cases so I can better understand what my manger is looking for in terms of moving these types of logic outside of application code, but in the meantime, I'd appreciate any info anyone has on these types of systems. As I said, I don't know what I don't know, and our business users seem to think our new application should support these types of tools. I want to make sure I'm limiting our functionality due to my lack of knowledge.
Thanks for any information or advice.
If you work in .NET: .NET Workflow Foundation. It's complex, true, but it's free and has everything your manager asks for. Business rules part will require some getting used to, the workflow will need some initial investment in building your own "environment" but, when you look at all this from above, WF.NET still gives more than what others has to offer. InRule is a cheap product that can't really do much, Blaze is way too complex, way too expensive and not really for "non-programmers"; ILOG is, too, not for "business users".
I am developing AMF Flash gateway on FlourineFx application for deployment on Windows Azure and I want to use Azure SQL.
I use NHibernate 2.1 + NHibernate.Linq 1.0 + FluentNHibernate 1.1
There will be two or more instances of this FlourineFx gateway and only 1 database.
I am planning on implementing memcached as 2nd level cache later (as Windows Azure WorkerRole), but is it necessary?
(I don't mind performance, but I do mind consistency)
I don't know if 2nd level cache solves some transaction-related problems or just makes it faster
The main point of the L2 cache is to avoid database hits and I wouldn't say that the L2 cache solves transactions-related problems; It might just be involved (and thus make the whole process a bit more complicated), if fully transactional caches are supported by NHibernate.
Personally, I tend to limit the use of L2 caching to read-only (or mostly read) objects, that's where the L2 cache gives all its power. Caching read-write entities is trickier, especially in a clustered environment, and the cache provider must support the Cache Concurrency Strategy required by your application for a given entity (read-only, non-strict-read-write, read-write).
I'm not sure this really answers the question, but at least it might give you some hints.
References
17.2. The Second Level Cache
Chapter 23, NHibernate.Caches
The cache won't help you with consistency. Of course it will help with performance, and you should use a distributed one, like memcached, if running multiple instances, as you correctly inferred.
That said, NHibernate does have features to help with consistency. Check:
5.1.7. version
10.4. Optimistic concurrency control
No, you don't.
But, how you guys helped me point to the right direction, it will help with performance.
So I will definitely run some instances of memcached and investigate concurrency control further.
Thanks.