|
|
-
Throttling, generally speaking, is tricky. Get the limits low and you may be prone to DoS and clients timing out trying to connect to your service in vain; Get them high and you may end up with an overloaded service that’s eating up machine resources until it crashes. There’s a sweet spot in between that will give you an optimum throughput and high availability at the same time. The ServiceThrottlingBehavior in WCF enables you to modify three important settings that you should consider tweaking to suit your application and resources. These settings are: MaxConcurrentCalls, MaxConcurrentInstances, and MaxConcurrentSessions. Since there are many considerations involved in choosing the values of these settings, and the fact that they may vary from a machine to another in a production environment, it’s recommended that you use the configuration file for your application (let it be app.config or web.config) to configure these limits. Here’s an example: | <configuration>
...
<system.serviceModel>
<services>
<service name="SampleService" behaviorConfiguration="Throttled">
<endpoint address="" binding="wsHttpBinding" contract="ISampleService">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="Throttled">
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
<serviceThrottling maxConcurrentCalls="200" maxConcurrentSessions="200" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration> | As you may have noticed I didn’t change the value of MaxConcurrentInstances and accepted the default which is 26. That’s because I set InstanceContextMode to Single, which means that there will be only one service instance. All calls are handled by this single instance and this can be a problem if the ConcurrencyMode is set to Single (the default value for this property) which means that the service is single-threaded and it can’t handle more than one call at a time, while other calls will have to wait until they get their turn or timeout. To avoid this problem, I set it to Multiple which allows the service to be multithreaded. Using multithreading comes with the usual responsibilities in design time (maintaining state consistency and avoiding synchronization problems) and in runtime (correctly throttling the service so that it doesn’t create many threads that can eat up machine resources). Back to MaxConcurrentInstances: Its value depends on InstanceContextMode: - Single: N/A
- PerSession: Equal to MaxConcurrentSessions
- PerCall: Estimated number of calls (average number of sessions * average number of calls per session)
On the other hand, MaxConcurrentSessions and MaxConcurrentCalls depend on the SessionMode of the service contract, there are 3 possible values: - Allowed: Specifies that the contract supports sessions if the incoming binding supports them. This one is tricky because it depends on the client, whether it establishes a "sessionful" binding or not. You need to estimate the mix of clients that use a session to make multiple calls vs clients that create a new session for each call.
- Required: Specifies that the contract requires a sessionful binding. An exception is thrown if the binding is not configured to support session. This one is self-explanatory.
- NotAllowed: Specifies that the contract never supports bindings that initiate sessions. Clients that create a new session for each call. Thus, number of sessions equals number of calls.
By default, all operation initiate sessions (according to the SessionMode of the service contract) but none is terminating, hence, the first call always initiates a session. If MaxConcurrentSessions is 100 and your client don’t terminate the session, your service will only handle 100 sessions then all subsequent messages will timeout. A client can close the session by calling one of the following methods: The client should be a good citizen and always close the connection, even if the operation is terminating. The advantage of the 3rd option here is the enforcement of the termination by the service contract, so even if the client didn’t behave as expected, the service sets a timer and the channel aborts the client after a certain period. Setting the IsTerminating attribute to true in an operation contract require the SessionMode of the service contract to be set to Required. The default values of MaxConcurrentSessions and MaxConcurrentCalls are 10 and 12 respectively. The higher you go with these values, the higher the throughput will be. You will need to understand the rates of resources consumption at higher throughput rates and the correlation between them (for example an exponential growth means that you have a problem). Also, the nature of the operations that your service execute play a big role too (whether they are I/O intensive or CPU intensive). On the other hand, leaving the values low makes your service prone to DoS attacks or mistakes like clients not closing the sessions. IMO, the following would help you find that sweet spot: - Profiling
- Understanding the design and nature of the operations
- Stress testing
- Dogfooding and/or beta testing in a pre-production environment
|
-
Beta 2 is here, give it a try and let us know what do you think.
|
-
In C++, if you call a virtual function form a constructor, it won’t be polymorphic, meaning that the following code won’t behave as you may have expected: | class Foo {
public:
Foo() {
whoAmI();
}
virtual void whoAmI() {
cout << "Foo::whoAmI()" << endl;
}
};
class Bar : public Foo {
public:
Bar() {
whoAmI();
}
virtual void whoAmI() {
cout << "Bar::whoAmI()" << endl;
}
};
int main() {
Bar bar;
} | This would print: Foo::whoAmI()
Bar::whoAmI() Not: Bar::whoAmI()
Bar::whoAmI() The explanation lies with the order of initialization; The base class is initialized first, hence the base class’s constructor is called first, and when it calls the virtual function, the members in the derived class are not initialized yet. By enforcing that, C++ prevents you from accessing members in the derived class that are not initialized yet!
|
-
Selection algorithms are very useful in many instances, like finding the majority. Given an array of size n that contains a majority item (an item that's repeated more than n/2 times), we can find that item in O(n). Basically, we can consider it as a voting process, each occurrence is a vote and each item is a candidate. Since there's a constant pool of votes, each candidate is winning a vote when it appears and losing a vote when another candidate is appearing instead. If the number of votes becomes 0, then it's time to pick another candidate. The candidate with a positive number of votes is the majority. Using this algorithm doesn't require extra storage like a hash to store the frequency of each item, we just need an integer for storing the frequency and a variable to store the candidate. Here's a sample in C# that prints the majority in an array of integers: using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
int[] array = new int[] { 2, 1, 5, 1, 7, 1, 9, 1 };
int candidate = array[0], freq = 1;
for (int i = 1; i < array.Length; ++i)
{
freq += (candidate == array[i] ? 1 : -1);
if (freq == 0)
{
candidate = array[i];
freq = 1;
}
}
Console.WriteLine("Majority: " + candidate);
}
}
}
|
-
Just in case you needed to, you can wrap an array into a struct/class and pass it by value to a function:
template<typename T, int N>
struct array {
T value[N];
T & operator[](int i) { return value[i]; }
};
template<typename T, int N>
void passByValue(array<T, N> a) {
cout << "Value in function:" << endl;
for (int i = 0; i < N; i++) a[i] = 1, cout << a[i] << endl; // prints 1's
}
int main() {
const int N = 5;
array<int, N > a;
for (int i = 0; i < N; i++) a[i] = 0;
passByValue(a);
cout << "Value after function call:" << endl;
for (int i = 0; i < N; i++) cout << a[i] << endl; // prints 0's
return 0;
}
|
-
One of the useful design patterns is the proxy design pattern, it allows you to control access to an object via a proxy and also saves you the startup and cleanup overheads as you instantiate only what you use upon request (lazy initialization). Take a look at the following example:
#include<iostream>
#include<string>
using namespace std;
class Base { // Interface
public:
virtual string run() = 0;
};
class Worker : public Base {
public:
string run() { return "Worker"; }
};
class Proxy : public Base {
private:
Worker* ptr;
Worker* getWorker() { return ptr ? ptr : (ptr = new Worker()); }
public:
Proxy() : ptr(NULL) {}
string run() { return getWorker()->run() + " via Proxy"; }
Worker * operator->() { return getWorker(); }
};
int main() {
Proxy obj;
cout << obj.run() << endl; // Worker via Proxy
cout << obj->run() << endl; // Worker
}
There are some points we need to note about the example. There’s an extra layer (one more class) that you need to add to be the proxy/controller. This proxy has a pointer to the actual worker object, it’s initialized to null and only instantiated upon request. That request is to be delegated to the worker to be processed while the proxy can add some logic such as pre-processing or post-processing, but it doesn’t have to because its main goal is to instantiate the worker object upon request. Using this pattern saves you the overhead of construction and destruction. Let’s assume that we have an array of 100 items, this will call the constructor 100 times and will call the destructor 100 times even if you didn’t use them. Using a proxy, you only create the object when it’s used, however there’s a slight overhead by doing that check every time you use it (whether it’s NULL or not), so it’s recommended to just create the objects and drop the check if you know that all of them are going to be used.
|
-
Just like design patterns, the use of test patterns will make your life easier. A lot of the common testing methods can be reused. Along with the benefits of reuse, using patterns makes it easier to explain to others what you are going to do in a word or a two instead of telling the whole story. Moreover, test patterns provide guidelines for solving common test design problems and define measurable actionable methods of testing. Test patterns have certain attributes that shape the pattern. It has an easy to remember name, which people agree upon and use to refer to the same test method. The pattern should be used to solve a certain problem, the same problem can be addressed by multiple problems, however, a pattern should tackle one problem and focus on its solution. Analysis of the problem addressed by the pattern is very important as it shows the various dimensions of the problem and why this pattern is the best solution for it. Test patterns are basically design patterns to solve testing problems; it has to have an algorithm or a sequence that forms the solution and shows how the test cases will be implemented. When test cases following this pattern are run, they will yield results that should be expected by the oracle of the pattern. And to make it easier for others who are going to use the pattern, it should list some examples, and how it relates to other patterns; a pattern doesn’t have to have related patterns though. To be explicit about when the pattern should be used and when it’s not suitable for the task at hand, limitations and restrictions should be listed too. Overall, these are the key attributes of a pattern, but there might be other attributes that can be added to specific patterns. Using patterns is recommended, because it’s conventional and standardized, but sometimes we face unusual problems that require unusual solutions. If a solution is so unique, specific, and is not likely to be reused, it may not be a good candidate for a test pattern. This doesn’t mean that patterns discourage innovation in problem solving, on the contrary, a pattern can get replaced by a better one solving the same problem. So, sharing the better solution among teams, or better among a community members is a good opportunity to create a new pattern. For more info: http://www.hwtsam.com and http://msdn.microsoft.com/en-us/library/cc514239.aspx
|
-
To do this, you can't call query labels with a wildcard character, you need to do the following: - Get all items blow $/Dir1 using GetItems - Loop through them calling QueryLabels on each one. Here's a code snippet:
VersionControlServer sc = tfs.GetService<VersionControlServer>();
List<VersionControlLabel> labels = new List<VersionControlLabel>(); foreach (Item i in sc.GetItems("$/Proj", RecursionType.Full).Items)
{
labels.AddRange(sc.QueryLabels(null, null, null, false, i.ServerItem, null));
}
|
-
A very handy power tool is tfpt unshelve. It’s capable of migrating a shelveset from a branch to another, it does that by performing a baseless merge, so you will need to resolve the conflicts produced. The syntax of the command looks like the following: tfpt unshelve shelvsetName /migrate /source:$/SourceBranch /target:$/TargetBranch
|
-
You can receive a daily email that has a compiled list of notifications, but you will need to subscribe programmatically:
IEventServiceeventService = (IEventService)new TeamFoundationServer("http://tfs:8080").GetService(typeof(IEventService)); string filter = "'Artifacts/Artifact[starts-with(translate(@ServerItem,\"ABCDEFGHIJKLMNOPQRSTUVWXYZ\",\"abcdefghijklmnopqrstuvwxyz\"),\"$/TeamProject/Folder\")]' <> null AND \"Committer\"<> 'DOMAIN\\YourUserName'"; DeliveryPreference dp = new DeliveryPreference
{
Address = "user@example.com",
Schedule = DeliverySchedule.Daily,
}; eventService.SubscribeEvent(@"DOMAIN\userName", "CheckinEvent", filter, dp);
|
-
-
You can run: tf diff /shelveset:shelvesetName;DOMAIN\ownerUserName Please note that this will diff the shelved changes against the unmodified version, not necessarily the latest version, just like what the you get from clicking compare in the shelveset details dialog. If you want to diff the shelved files programmatically against the latest version, you will need to write some code, please take a look at: http://blogs.msdn.com/mohamedg/archive/2009/03/08/how-to-diff-files-using-tfs-apis.aspx. If you are going to use the Difference class to launch a diff tool, you can use Difference.VisualDiffItems. If you need to get the differences in a linked list of DiffSegments, you will need to unshelve the shelved file (fileA) and download the latest from server (fileB) to disk first, then diff them using the following call: Difference.DiffFiles(fileA, FileType.Detect(fileA, null), fileB, FileType.Detect(fileB, null), new DiffOptions());
|
-
You can achieve that behavior by running:
tf hist rootItemSpec /r /version:LstartLabel~LendLabel
Here’s my scenario:
tf hist /i File.cs
Changeset Change User Date Comment
--------- -------------------------- ------------- ---------- --------
65 edit mohamedg 4/2/2009
63 edit mohamedg 4/2/2009
60 edit mohamedg 4/2/2009
59 edit mohamedg 4/2/2009
50 edit mohamedg 4/1/2009
49 edit mohamedg 4/1/2009
48 edit mohamedg 3/31/2009
47 add mohamedg 3/31/2009
tf label Rev1 File.cs;48
Created label Rev1@$/Proj
tf label Rev2 File.cs;63
Created label Rev2@$/Proj
tf hist /i File.cs /version:LRev1~LRev2
Changeset Change User Date Comment
--------- -------------------------- ------------- ---------- --------------------------------
63 edit mohamedg 4/2/2009
60 edit mohamedg 4/2/2009
59 edit mohamedg 4/2/2009
50 edit mohamedg 4/1/2009
49 edit mohamedg 4/1/2009
|
-
You can use tfpt history /followbranches to follow the history of an item across branches. We are looking into supporting this in the history dialog in the next version. You can see which versions are ported over during the merge operation if you use tf.exe: tf merge BranchA BranchB /r merge: $/mohamedg/blog/BranchA/File.cs;C663~C664 -> $/mohamedg/blog/BranchB/File.cs;C665 After the merge is done, you can look up the merge history to know what changesets were ported over, for example: tf merges BranchA BranchB /r Changeset Merged in Changeset Author Date --------- ------------------- -------------------------------- ---------- 654 655 mohamedg 4/10/2009 656 657 mohamedg 4/10/2009 658 661 mohamedg 4/10/2009 659 661 mohamedg 4/10/2009 660 661 mohamedg 4/10/2009 662 665 mohamedg 4/10/2009 663 665 mohamedg 4/10/2009 tf merges BranchA BranchB /r /format:detailed /showall Merged items: $/mohamedg/blog/BranchA;C654 -> $/mohamedg/blog/BranchB;C655 $/mohamedg/blog/BranchA/File.cs;C654 -> $/mohamedg/blog/BranchB/File.cs;C655 $/mohamedg/blog/BranchA/File.cs;C656 -> $/mohamedg/blog/BranchB/File.cs;C657 $/mohamedg/blog/BranchA/File.cs;C658~660 -> $/mohamedg/blog/BranchB/File.cs;C661 $/mohamedg/blog/BranchA/File.cs;C662~663 -> $/mohamedg/blog/BranchB/File.cs;C665
|
-
If you have an IDE that uses the MSSCCI provider, like VS 2003 or VB6, and you want to switch between TFS and VSS because you have projects on both systems, you will have to change the provider every time you switch. The thing is that setting is stored in the Windows registry, therefore, you will have to restart the IDE to enable the desired provider (just like most programs, unless they implement a registry watcher). There are some tools that can make the switch easier: http://www.codeproject.com/KB/applications/sccswitcher.aspx
http://www.sitedev.com/sccswitcher
http://weblog.kilic.net/tools/SCPSelector Or you may create your own .reg file to write to the registry.
|
|
|
|
