[Discovery] Những nguyên lý hoạt động cơ bản của hệ thống phanh trên xe hơi

banner.

Tất cả chúng ta đều biết rằng khi xe hơi đang chạy trên đường, chỉ cần bạn đạp phanh thì chiếc xe sẽ từ từ giảm tốc độ và dừng lại. Vậy thực sự điều gì đã diễn ra khi bạn đạp phanh? Lực đạp từ bàn chân bạn được truyền tới bánh xe như thế nào? Làm thế lực chân được khuếch đại đủ lớn để có thể phanh cả một chiếc xe hơi to lớn? Tiếp nối các bài viết tìm hiểu xe hơi, bài viết này sẽ cùng các bạn tìm hiểu những nguyên lý cơ bản của hệ thống phanh trên xe hơi nhằm trả lời cho những thắc mắc nói trên.

Phanh được xếp vào danh sách những hệ thống đảm bảo an toàn trên xe hơi. Dĩ nhiên là không chỉ xe hơi mà bất cứ phương tiện vận chuyển nào cũng cần phải có hệ thống giúp giảm tốc độ và dừng lại theo ý muốn của người điều khiển. Trên hầu hết các dòng xe hơi, chúng ta sẽ bắt gặp được 2 loại phanh cơ bản nhất là phanh chính (thường vận hành bằng thủy lực) phanh tay. Trong khuôn khổ bài viết này, chúng ta sẽ khảo sát dạng phanh thứ nhất là phanh chính, phanh tay sẽ được nghiên cứu sâu hơn trong một bài viết khác.

Những nguyên lý cơ bản trong một hệ thống phanh

Đầu tiên, vấn đề ở đây là nếu chỉ sử dụng lực của người điều khiển thì không thể nào dừng cả một chiếc xe to và nặng hơn rất nhiều lần, do đó, hệ thống phanh là vô cùng cần thiết. Khi bạn đạp phanh, lực sẽ được truyền từ bàn chân xuống cơ cấu phanh thông qua áp suất chất lỏng được dẫn đi qua hệ thống ống thủy lực. Để có thể tăng cường lực phanh lên tới mức cần thiết để dừng xe, hệ thống phanh đã sử dụng 2 cơ cấu trợ lực là: đòn bẩy và thủy lực. Tiếp theo, lực phanh sẽ được truyền tới bánh xe dưới dạng lực ma sát. Đồng thời, bánh xe cũng sẽ truyền lực đó xuống tới mặt đường dưới dạng ma sát giúp xe dừng lại.

Tinhte_so_do_he_thong_phanh.Sơ đồ các thành phần chính của hệ thống phanh trên xe hơi

Trước khi bắt đầu khảo sát sâu hơn các chi tiết trong hệ thống phanh, chúng ta sẽ tóm tắt lại 3 nguyên tắc cơ bản của 1 hệ thống phanh trên xe hơi:

  • Đòn bẩy
  • Thủy lực (phanh dầu), chân không, khí nén hoặc kết hợp
  • Ma sát

Về cơ bản, cơ cấu thủy lực và khí nét có hoạt động tương tự nhau nên phần sau mình sẽ chọn mô tả loại thủy lực để các bạn dễ hình dung hơn. Đồng thời, đa số xe hơi hiện nay đều sử dụng hệ thống phanh thủy lực là chủ yếu. Một số loại xe còn sử dụng kết hợp cả khí ênns

Cơ cấu đòn bẩy và thủy lực

Tinhte_don_bay. ​Trong hình minh họa bên trên, một lực F đã được tác động lên đầu bên trái của đòn bẩy. Phần bên trái dài hơn gấp 2 lần so với bên phải, do đó, lực hướng lên bên phải cũng có độ lớn gấp đôi so với lực đẩy xuống bên trái. Nếu thay đổi điểm đặt lực bên trái thì bội số cũng theo đổi tương ứng. Đó chính là nguyên tắc cơ bản của đòn bẩy mà chúng ta đều biết. Và khi kết hợp ý tưởng đòn bẩy với cơ cấu thủy lực, chúng ta có được bản chất của việc khuếch đại lực phanh trên xe hơi.

Về cơ bản, hệ thống trợ lực phanh trên xe hơi có cách hoạt động khá đơn giản: Lực được truyền từ bàn chân người lái đến điểm khác thông qua một chất lỏng không thể bị nén, thường là dầu nhớt. Bên dưới là hình minh họa cho một hệ thống thủy lực đơn giản.

Tinhte_thuy_luc. ​Các bạn có thể thấy, 2 piston (màu đỏ) được lắp vừa vặn bên trong xy lanh chứa đầy dầu. 2 xy lanh được kết nối với nhau bằng 1 ống dẫn cũng chứa đầy dầu. Nếu bạn đẩy 1 piston xuống, lực sẽ được truyền qua dầu và dẫn tới xy lanh bên kia làm nó di chuyển lên. Do tính chất của dầu bên trong ống dẫn là rất khí nén lại, nên gần như toàn bộ lực được truyền đi qua lại giữa 2 piston. Đồng thời, điểm thuận lợi của cơ cấu thủy lực là chúng ta có thể chế tạo đường ống dẫn theo bất cứ hình dạng và kích thước nào cho phù hợp với nhu cầu lắp đặt trên xe.
Tinhte_he_thong_thuy_luc_kep. ​Đồng thời, chúng ta cũng có thể chia đường ống dẫn ra, để có thể dùng 1 piston chủ truyền lực cho nhiều piston con. Và chúng ta đã bắt đầu thấy được, đạp chân tại 1 điểm nhưng lực phanh được phân phối ra tới 2 bánh xe như thế nào. Do đó, chỉ cần các kỹ sư thay đổi kích thước và dung tích của xy lanh, lực sẽ được truyền đi theo một tỷ lệ theo yêu cầu.
Tinhte_ratio_thuy_luc. ​Với hình mô tả bên trên, giả sử piston bên trái có đường kính 5,08 cm và bên phải là 7,62 cm. Với phép tính đơn giản, chúng ta sẽ có tiết diện của 2 piston bên trái, bên phải lần lượt là 20,26 cm vuông và 45,6 cm vuông. Xy lanh bên phải có tiết diện lớn gấp 9 lần so với bên trái. Điều đó có nghĩa là bất cứ lực nào tác động vào piston bên trái sẽ được nhân lên gấp 9 lần tại xy lanh bên phải. Thí dụ, nếu bạn tác động lực đẩy xuống 100N vào piston trái, thì piston bên phải sẽ di chuyển lên trên với lực có độ lớn là 900N (bỏ qua ma ma sát và các lực cản khác). Đồng thời, bạn chỉ cần di chuyển piston trái xuống 22,86 cm thì piston bên phải sẽ được nâng lên 2,54 cm.

Nguyên lý của sự ma sát

brake-friction1.​Trên lý thuyết, ma sát là một loại lực cản xuất hiện giữa các bề mặt vật chất nhằm chống lại xu hướng thay đổi vị trí tương đối giữa 2 bề mặt. Trong một thí dụ đơn giản ở hình trên, cả 2 khối đều được ghép lại từ những viên gạch, nhưng khối bên phải nặng hơn bên trái 4 lần. Dĩ nhiên, bạn sẽ cần nhiều lực hơn để đẩy khối bên phải di chuyển. Tại sao vậy?
brake-friction2. ​Mặt dù bề mặt của những viên gạch rất trơn tru khi quan sát bằng mắt thường, nhưng khi phóng đại dưới kính hiển vi, các bạn sẽ thấy bề mặt những viên gạch không phẳng như bạn tưởng. Đồng thời, viên gạch cũng có trọng lượng và luôn được Trái Đất kéo xuống theo phương thẳng đứng. Do đó, viên gạch càng nặng, trọng lượng càng lớn cộng với bề mặt nhám sẽ giúp nó có thể bám chắc trên bề mặt.

Mỗi loại vật liệu sẽ có một cấu trúc hiển vi khác nhau. Điển hình như thép sẽ trượt trên thép dễ dàng hơn so với việc trượt cao su lên cao su. Do đó, ở đây chúng ta sẽ có khái niệm hệ số ma sát trượt, diễn tả tỷ lệ giữa độ lớn lực ma sát trượt của vật liệu và trọng lực tác động lên vật thể. Giả sử nếu hệ số ma sát trượt là 1, bạn cần dùng 1 lực 100N để đẩy 1 vật có trọng lượng 100N. Nhưng nếu hệ số ma sát trượt là 0,1, thì bạn chỉ cần dùng 1 lực 10N để đẩy vật 100N.

Đến đây, chúng ta đã nắm được những nguyên tắc vật lý cơ bản trong hoạt động của hệ thống phanh. Tiếp theo, chúng ta sẽ dễ dàng khảo sát nguyên lý hoạt động của 1 hệ thống phanh cụ thể.

Hệ thống phanh cơ bản

Tinhte_he_thong_phanh. ​Trong hình minh họa, các bạn có thể thấy khoảng cách từ cần phanh tới điểm tựa (x) dài gấp 4 lần so với khoảng cách từ điểm tựa đến xy lanh (4x). Do đó, lực đạp cần phanh sẽ được nhân lên gấp 4 lần khi được truyền tới xy lanh. Đồng thời, bạn cũng nhận thấy rằng đường kính của xy lanh cuối (3y) lớn hơn xy lanh đầu (y) gấp 3 lần đồng nghĩa với tiết diện cũng lớn gấp 9 lần. Kết hợp toàn bộ hệ thống trên, lực đạp phanh của người lái sẽ được nhân lên gấp 36 lần. Nếu bạn đạp một lực 10N lên cần phanh, một lực với độ lớn 360N sẽ ép lên má phanh.
Tinhte_phanh_chu_1. ​Khi nghiên cứu tới đây, mình cũng có thắc mắc rằng nếu dầu bị rò rỉ ra ngoài thì sao? Nếu dầu bị rò rỉ, tất nhiên là sẽ đến lúc không còn đủ chất lỏng trong xylanh và ống dầu dẫn đến hệ thống phanh sẽ không hoạt động. Để khắc phục điều này, các kỹ sư đã chế tạo một hệ thống phanh với xylanh chủ và các tổ hợp van. Chúng ta sẽ cùng tìm hiểu nhé.
Tinhte_xylanh_chu_2. ​Như các bạn có thể thấy trong hình, xy lanh dầu chủ được chia thành 2 buồng thông với nhau và sẽ cung cấp áp suất cho cả 2 hệ thống ống dẫn dầu. Khi bạn đạp cần phanh đồng nghĩa với việc đẩy piston thứ nhất chuyển động lên phía trước và áp suất dầu bên trong sẽ giảm xuống. Khi đó, áp lực giữa piston thứ nhất và piston thứ 2 sẽ đẩy piston thứ 2 tiến về phía trước. Khi đó, dầu sẽ được đẩy đi một cách bình thường đến phanh. Trong trường hợp dầu bị rò rỉ tại 1 trong 2 ống, ống đó sẽ không thể duy trì áp suất như ban đầu tuy nhiên vẫn đảm bảo áp suất trong ống còn lại đủ để truyền tới cơ cấu phanh ở bánh xe. Khi đó, người điều khiển phải nhấn cần phanh mạnh hơn, tuy nhiên, xe vẫn có thể phanh một cách an toàn.

Đến đây, chúng ta đã có thể hiểu được những nguyên lý cơ bản trong quá trình vận hành của hệ thống phanh nói chung và phanh trên xe hơi nói riêng để trả lời cho các câu hỏi đặt ra ở phần mở đầu. Dĩ nhiên, hệ thống phanh trên xe hơi còn tồn tại rất nhiều vấn đề khác như phân loại và ưu nhược điểm của từng hệ thồng phanh trên xe hơi cũng như các công nghệ hỗ trợ phanh. Tuy nhiên, trong khuôn khổ bài viết mình xin kết thúc tại phần nguyên lý cơ bản, hẹn các bạn ở những bài viết khác cụ thể về từng hệ thống phanh. Xin cám ơn các bạn đã theo dõi bài viết. Chúc vui vẻ và lái xe an toàn!

Tham khảo SDT, Overdrive, Auto (1), (2), Bosch

[Dev Tip] SignalR Performance

Design considerations

This section describes patterns that can be implemented during the design of a SignalR application, to ensure that performance is not being hindered by generating unnecessary network traffic.

Throttling message frequency

Even in an application that sends out messages at a high frequency (such as a realtime gaming application), most applications don’t need to send more than a few messages a second. To reduce the amount of traffic that each client generates, a message loop can be implemented that queues and sends out messages no more frequently than a fixed rate (that is, up to a certain number of messages will be sent every second, if there are messages in that time interval to be sent). For a sample application that throttles messages to a certain rate (from both client and server), see High-Frequency Realtime with SignalR.

Reducing message size

You can reduce the size of a SignalR message by reducing the size of your serialized objects. In server code, if you’re sending an object that contains properties that don’t need to be transmitted, prevent those properties from being serialized by using the JsonIgnore attribute. The names of properties are also stored in the message; the names of properties can be shortened using the JsonProperty attribute. The following code sample demonstrates how to exclude a property from being sent to the client, and how to shorten property names:

.NET server code that demonstrates the JsonIgnore attribute to exclude data from being sent to the client, and the JsonProperty attribute to reduce message size


using Newtonsoft.Json; 
using System; 
public class ShapeModel
{
[JsonProperty("l")]
    public double Left { get; set; }
[JsonProperty("t")]
    public double Top { get; set; }
    // We don't want the client to get the "LastUpdatedBy" property
[JsonIgnore]
    public string LastUpdatedBy { get; set; }
}

In order to retain readability/ maintainability in the client code, the abbreviated property names can be remapped to human-friendly names after the message is received. The following code sample demonstrates one possible way of remapping shortened names to longer ones, by defining a message contract (mapping), and using the reMapfunction to apply the contract to the optimized message class:

Client-side JavaScript code that remaps shortened property names to human-readable names


function reMap(smallObject, contract) {
    var largeObject = {};
    for (var smallProperty in contract) {
        largeObject[contract[smallProperty]] = smallObject[smallProperty];
    }
    return largeObject;
}
var shapeModelContract = {
    l: "left",
    t: "top"
};
myHub.client.setShape = function (shapeModelSmall) {
    var shapeModel = reMap(shapeModelSmall, shapeModelContract);
    // shapeModelSmall has "l" and "t" properties  but after remapping
    // shapeModel now has "left" and "top" properties
};
     

Names can be shortened in messages from the client to the server as well, using the same method.

Reducing the memory footprint (that is, the amount of memory used for the message) of the message object can also improve performance. For example, if the full range of an int is not needed, a short or byte can be used instead.

Since messages are stored in the message bus in server memory, reducing the size of messages can also address server memory issues.

Tuning your SignalR server for performance

The following configuration settings can be used to tune your server for better performance in a SignalR application. For general information on how to improve performance in an ASP.NET application, see Improving ASP.NET Performance.

SignalR configuration settings

  • DefaultMessageBufferSize: By default, SignalR retains 1000 messages in memory per hub per connection. If large messages are being used, this may create memory issues which can be alleviated by reducing this value. This setting can be set in the Application_Start event handler in an ASP.NET application, or in theConfiguration method of an OWIN startup class in a self-hosted application. The following sample demonstrates how to reduce this value in order to reduce the memory footprint of your application in order to reduce the amount of server memory used:

    .NET server code in Startup.cs for decreasing default message buffer size

    
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Any connection or hub wire up and configuration should go here
    		GlobalHost.Configuration.DefaultMessageBufferSize = 500;
    		app.MapSignalR();
        }
    }
             

IIS configuration settings

  • Max concurrent requests per application: Increasing the number of concurrent IIS requests will increase server resources available for serving requests. The default value is 5000; to increase this setting, execute the following commands in an elevated command prompt:
            
    cd %windir%\System32\inetsrv\
    appcmd.exe set config /section:system.webserver/serverRuntime 
            /appConcurrentRequestLimit:10000
        
    
  • ApplicationPool QueueLength: This is the maximum number of requests that Http.sys queues for the application pool. When the queue is full, new requests receive a 503 “Service Unavailable” response. The default value is 1000.

    Shortening the queue length for the worker process in the application pool hosting your application will conserve memory resources. For more information, see Managing, Tuning, and Configuring Application Pools.

ASP.NET configuration settings

This section includes configuration settings that can be set in the aspnet.config file. This file is found in one of two locations, depending on platform:

  • %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet.config
  • %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet.config

ASP.NET settings that may improve SignalR performance include the following:

  • Maximum concurrent requests per CPU: Increasing this setting may alleviate performance bottlenecks. To increase this setting, add the following configuration setting to the aspnet.config file:
    
    <?xml version="1.0" encoding="UTF-8" ?>
    <configuration>
        <system.web>
            <applicationPool maxConcurrentRequestsPerCPU="20000" />
        </system.web>
    </configuration>
                 
  • Request Queue Limit: When the total number of connections exceeds the maxConcurrentRequestsPerCPUsetting, ASP.NET will start throttling requests using a queue. To increase the size of the queue, you can increase the requestQueueLimit setting. To do this, add the following configuration setting to the processModelnode in config/machine.config (rather than aspnet.config):
            
    <processModel autoConfig="false" requestQueueLimit="250000" />
                
    

Troubleshooting performance issues

This section describes ways to find performance bottlenecks in your application.

Verifying that WebSocket is being used

While SignalR can use a variety of transports for communication between client and server, WebSocket offers a significant performance advantage, and should be used if the client and server support it. To determine if your client and server meet the requirements for WebSocket, see Transports and Fallbacks. To determine what transport is being used in your application, you can use the browser developer tools, and examine the logs to see what transport is being used for the connection. For information on using the browser development tools in Internet Explorer and Chrome, see Transports and Fallbacks.

Using SignalR performance counters

This section describes how to enable and use SignalR performance counters, found in theMicrosoft.AspNet.SignalR.Utils package.

Installing signalr.exe

Peformance counters can be added to the server using a utility called SignalR.exe. To install this utility, follow these steps:

  1. In your Visual Studio application, select Tools, Library Package Manager, Manage NuGet Packages for Solution…
  2. Search for signalr.utils, and select Install.

  3. Accept the license agreement to install the package.
  4. SignalR.exe will be installed to <project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/tools.

Installing performance counters with SignalR.exe

To install SignalR performance counters, run SignalR.exe in an elevated command prompt with the following parameter:


SignalR.exe ipc
    

To remove SignalR performance counters, run SignalR.exe in an elevated command prompt with the following parameter:


SignalR.exe upc
    

SignalR Performance counters

The utilites package installs the following performance counters. The “Total” counters measure the number of events since the last application pool or server restart.

Connection metrics

The following metrics measure the connection lifetime events that occur. For more information, see Understanding and Handling Connection Lifetime Events .

  • Connections Connected
  • Connections Reconnected
  • Connections Disonnected
  • Connections Current

Message metrics

The following metrics measure the message traffic generated by SignalR.

  • Connection Messages Received Total
  • Connection Messages Sent Total
  • Connection Messages Received/Sec
  • Connection Messages Sent/Sec

Message bus metrics

The following metrics measure traffic through the internal SignalR message bus, the queue in which all incoming and outgoing SignalR messages are placed. A message is Published when it is sent or broadcast. A Subscriber in this context is a subscription on the message bus; this should equal the number of clients plus the server itself. AnAllocated Worker is a component that sends data to active connections; a Busy Worker is one that is actively sending a message.

  • Message Bus Messages Received Total
  • Message Bus Messages Received/Sec
  • Message Bus Messages Published Total
  • Message Bus Messages Published/Sec
  • Message Bus Subscribers Current
  • Message Bus Subscribers Total
  • Message Bus Subscribers/Sec
  • Message Bus Allocated Workers
  • Message Bus Busy Workers
  • Message Bus Topics Current

Error metrics

The following metrics measure errors generated by SignalR message traffic. Hub Resolution errors occur when a hub or hub method cannot be resolved. Hub Invocation errors are exceptions thrown while invoking a hub method.Transport errors are connection errors thrown during an HTTP request or response.

  • Errors: All Total
  • Errors: All/Sec
  • Errors: Hub Resolution Total
  • Errors: Hub Resolution/Sec
  • Errors: Hub Invocation Total
  • Errors: Hub Invocation/Sec
  • Errors: Transport Total
  • Errors: Transport/Sec

Scaleout metrics

The following metrics measure traffic and errors generated by the scaleout provider. A Stream in this context is a scale unit used by the scaleout provider; this is a table if SQL Server is used, a Topic if Service Bus is used, and a Subscription if Redis is used. Each stream ensures ordered read and write operations; a single stream is a potential scale bottleneck, so the number of streams can be increased to help reduce that bottleneck. If multiple streams are used, SignalR will automatically distribute (shard) messages across these streams in a way that ensures messages sent from any given connection are in order.

The MaxQueueLength setting controls the length of the scaleout send queue maintained by SignalR. Setting it to a value greater than 0 will place all messages in a send queue to be sent one at a time to the configured messaging backplane. If the size of the queue goes above the configured length, subsequent calls to send will fail immediately with an InvalidOperationException until the number of messages in the queue is less than the setting again. Queueing is disabled by default because the implemented backplanes generally have their own queuing or flow-control in place. In the case of SQL Server, connection pooling effectively limits the number of sends going on at any one time.

By default, only one stream is used for SQL Server and Redis, five streams are used for Service Bus, and queueing is disabled, but these settings can be changed through configuration on SQL Server and Service Bus:

.NET Server Code for configuring table count and queue length for SQL Server backplane

var connectionString = "(your connection string)";
var config = new SqlScaleoutConfiguration(connectionString) { 
	TableCount = 3,
	MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseSqlServer(config);

.NET Server Code for configuring topic count and queue length for Service Bus backplane

string connectionString = "(your connection string)";
var config = new ServiceBusScaleoutConfiguration(connectionString, "YourAppName") { 
	TopicCount = 3,
	MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseServiceBus(config);

A Buffering stream is one that has entered a faulted state; when the stream is in the faulted state, all messages sent to the backplane will fail immediately until the stream is no longer faulting. The Send Queue Length is the number of messages that have been posted but not yet sent.

  • Scaleout Message Bus Messages Received/Sec
  • Scaleout Streams Total
  • Scaleout Streams Open
  • Scaleout Streams Buffering
  • Scaleout Errors Total
  • Scaleout Errors/Sec
  • Scaleout Send Queue Length

For more information on what these counters are measuring, see SignalR Scaleout with Windows Azure Service Bus.

Using other performance counters

The following performance counters may also be useful in monitoring your application’s performance.

Memory

  • .NET CLR Memory# bytes in all Heaps (for w3wp)

ASP.NET

  • ASP.NET\Requests Current
  • ASP.NET\Queued
  • ASP.NET\Rejected

CPU

  • Processor Information\Processor Time

TCP/IP

  • TCPv6/Connections Established
  • TCPv4/Connections Established

Web Service

  • Web Service\Current Connections
  • Web Service\Maximum Connections

Threading

  • .NET CLR LocksAndThreads\# of current logical Threads
  • .NET CLR LocksAnd Threads\# of current physical Threads

Other Resources

For more information on ASP.NET performance monitoring and tuning, see the following topics:

[Dev Tip] SignalR Scaleout with SQL Server

In this tutorial, you will use SQL Server to distribute messages across a SignalR application that is deployed in two separate IIS instances. You can also run this tutorial on a single test machine, but to get the full effect, you need to deploy the SignalR application to two or more servers. You must also install SQL Server on one of the servers, or on a separate dedicated server. Another option is to run the tutorial using VMs on Windows Azure.

Prerequisites

Microsoft SQL Server 2005 or later. The backplane supports both desktop and server editions of SQL Server. It does not support SQL Server Compact Edition or Windows Azure SQL Database. (If your application is hosted on Windows Azure, consider the Service Bus backplane instead.)

Overview

Before we get to the detailed tutorial, here is a quick overview of what you will do.

  1. Create a new empty database. The backplane will create the necessary tables in this database.
  2. Add these NuGet packages to your application:
  3. Create a SignalR application.
  4. Add the following code to Startup.cs to configure the backplane:
public class Startup
{
    public void Configuration(IAppBuilder app)
    {
    	    // Any connection or hub wire up and configuration should go here
    	    string sqlConnectionString = "Connecton string to your SQL DB";
    		GlobalHost.DependencyResolver.UseSqlServer(sqlConnectionString);
            app.MapSignalR();
    }
}

This code configures the backplane with the default values for TableCount and MaxQueueLength. For information on changing these values, see SignalR Performance: Scaleout Metrics.

Configure the Database

Decide whether the application will use Windows authentication or SQL Server authentication to access the database. Regardless, make sure the database user has permissions to log in, create schemas, and create tables.

Create a new database for the backplane to use. You can give the database any name. You don’t need to create any tables in the database; the backplane will create the necessary tables.

Enable Service Broker

It is recommended to enable Service Broker for the backplane database. Service Broker provides native support for messaging and queuing in SQL Server, which lets the backplane receive updates more efficiently. (However, the backplane also works without Service Broker.)

To check whether Service Broker is enabled, query the is_broker_enabled column in the sys.databases catalog view.

SELECT [name], [service_broker_guid], [is_broker_enabled]
FROM [master].[sys].[databases]

To enable Service Broker, use the following SQL query:

ALTER DATABASE YOUR_DATABASE SET ENABLE_BROKER

If this query appears to deadlock, make sure there are no applications connected to the DB.

If you have enabled tracing, the traces will also show whether Service Broker is enabled.

Create a SignalR Application

Create a SignalR application by following either of these tutorials:

Next, we’ll modify the chat application to support scaleout with SQL Server. First, add the SignalR.SqlServer NuGet package to your project. In Visual Studio, from the Tools menu, select Library Package Manager, then select Package Manager Console. In the Package Manager Console window, enter the following command:

Install-Package Microsoft.AspNet.SignalR.SqlServer 

Next, open the Startup.cs file. Add the following code to the Configure method:


public class Startup
{
    public void Configuration(IAppBuilder app)
    {
    	    // Any connection or hub wire up and configuration should go here
    	    string sqlConnectionString = "Connecton string to your SQL DB";
    		GlobalHost.DependencyResolver.UseSqlServer(sqlConnectionString);
            app.MapSignalR();
    }
}

Deploy and Run the Application

Prepare your Windows Server instances to deploy the SignalR application.

Add the IIS role. Include “Application Development” features, including the WebSocket Protocol.

Also include the Management Service (listed under “Management Tools”).

Install Web Deploy 3.0. When you run IIS Manager, it will prompt you to install Microsoft Web Platform, or you can download the intstaller. In the Platform Installer, search for Web Deploy and install Web Deploy 3.0

Check that the Web Management Service is running. If not, start the service. (If you don’t see Web Management Service in the list of Windows services, make sure that you installed the Management Service when you added the IIS role.)

Finally, open port 8172 for TCP. This is the port that the Web Deploy tool uses.

Now you are ready to deploy the Visual Studio project from your development machine to the server. In Solution Explorer, right-click the solution and click Publish.

For more detailed documentation about web deployment, see Web Deployment Content Map for Visual Studio and ASP.NET.

If you deploy the application to two servers, you can open each instance in a separate browser window and see that they each receive SignalR messages from the other. (Of course, in a production environment, the two servers would sit behind a load balancer.)

After you run the application, you can see that SignalR has automatically created tables in the database:

SignalR manages the tables. As long as your application is deployed, don’t delete rows, modify the table, and so forth.

Note: With LocalDB, you absolutely can use this guide.

[Dev Tip] SignalR Scaleout with Redis

In this tutorial, you will use Redis to distribute messages across a SignalR application that is deployed on two separate IIS instances.

Redis is an in-memory key-value store. It also supports a messaging system with a publish/subscribe model. The SignalR Redis backplane uses the pub/sub feature to forward messages to other servers.

For this tutorial, you will use three servers:

  • Two servers running Windows, which you will use to deploy a SignalR application.
  • One server running Linux, which you will use to run Redis. For the screenshots in this tutorial, I used Ubuntu 12.04 TLS.

If you don’t have three physical servers to use, you can create VMs on Hyper-V. Another option is to create VMs on Windows Azure.

Although this tutorial uses the official Redis implementation, there is also a Windows port of Redis from MSOpenTech. Setup and configuration are different, but otherwise the steps are the same.

Overview

Before we get to the detailed tutorial, here is a quick overview of what you will do.

  1. Install Redis and start the Redis server.
  2. Add these NuGet packages to your application:
  3. Create a SignalR application.
  4. Add the following code to Startup.cs to configure the backplane:
public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Any connection or hub wire up and configuration should go here
            GlobalHost.DependencyResolver.UseRedis("server", port, "password", "AppName");
            app.MapSignalR();
        }
    }

Ubuntu on Hyper-V

Using Windows Hyper-V, you can easily create an Ubuntu VM on Windows Server.

Download the Ubuntu ISO from http://www.ubuntu.com.

In Hyper-V, add a new VM. In the Connect Virtual Hard Disk step, select Create a virtual hard disk.

In the Installation Options step, select Image file (.iso), click Browse, and browse to the Ubuntu installation ISO.

Install Redis

Follow the steps at http://redis.io/download to download and build Redis.

wget http://redis.googlecode.com/files/redis-2.6.12.tar.gz
tar xzf redis-2.6.12.tar.gz
cd redis-2.6.12
make

This builds the Redis binaries in the src directory.

By default, Redis does not require a password. To set a password, edit the redis.conf file, which is located in the root directory of the source code. (Make a backup copy of the file before you edit it!) Add the following directive toredis.conf:

requirepass YourStrongPassword1234

Now start the Redis server:

src/redis-server redis.conf

Open port 6379, which is the default port that Redis listens on. (You can change the port number in the configuration file.)

Create the SignalR Application

Create a SignalR application by following either of these tutorials:

Next, we’ll modify the chat application to support scaleout with Redis. First, add the SignalR.Redis NuGet package to your project. In Visual Studio, from the Tools menu, select Library Package Manager, then select Package Manager Console. In the Package Manager Console window, enter the following command:

Install-Package Microsoft.AspNet.SignalR.Redis 

Next, open the Startup.cs file. Add the following code to the Configuration method:

public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Any connection or hub wire up and configuration should go here
            GlobalHost.DependencyResolver.UseRedis("server", port, "password", "AppName");
            app.MapSignalR();
        }
    }
  • “server” is the name of the server that is running Redis.
  • port is the port number
  • “password” is the password that you defined in the redis.conf file.
  • “AppName” is any string. SignalR creates a Redis pub/sub channel with this name.

For example:

GlobalHost.DependencyResolver.UseRedis("redis-server.cloudapp.net", 6379,
    "MyStrongPassword1234", "ChatApp");

Deploy and Run the Application

Prepare your Windows Server instances to deploy the SignalR application.

Add the IIS role. Include “Application Development” features, including the WebSocket Protocol.

Also include the Management Service (listed under “Management Tools”).

Install Web Deploy 3.0. When you run IIS Manager, it will prompt you to install Microsoft Web Platform, or you candownload the intstaller. In the Platform Installer, search for Web Deploy and install Web Deploy 3.0

Check that the Web Management Service is running. If not, start the service. (If you don’t see Web Management Service in the list of Windows services, make sure that you installed the Management Service when you added the IIS role.)

By default, the Web Management Service listens on TCP port 8172. In Windows Firewall, create a new inbound rule to allow TCP traffic on port 8172. For more information, see Configuring Firewall Rules. (If you are hosting the VMs on Windows Azure, you can do this directly in the Windows Azure portal. See How to Set Up Communication with a Virtual Machine.)

Now you are ready to deploy the Visual Studio project from your development machine to the server. In Solution Explorer, right-click the solution and click Publish.

For more detailed documentation about web deployment, see Web Deployment Content Map for Visual Studio and ASP.NET.

If you deploy the application to two servers, you can open each instance in a separate browser window and see that they each receive SignalR messages from the other. (Of course, in a production environment, the two servers would sit behind a load balancer.)

If you’re curious to see the messages that are sent to Redis, you can use the redis-cli client, which installs with Redis.

redis-cli -a password
SUBSCRIBE ChatApp

[Dev Tip] Introduction to Scaleout in SignalR

In general, there are two ways to scale a web application: scale up and scale out.

  • Scale up means using a larger server (or a larger VM) with more RAM, CPUs, etc.
  • Scale out means adding more servers to handle the load.

The problem with scaling up is that you quickly hit a limit on the size of the machine. Beyond that, you need to scale out. However, when you scale out, clients can get routed to different servers. A client that is connected to one server will not receive messages sent from another server.

One solution is to forward messages between servers, using a component called a backplane. With a backplane enabled, each application instance sends messages to the backplane, and the backplane forwards them to the other application instances. (In electronics, a backplane is a group of parallel connectors. By analogy, a SignalR backplane connects multiple servers.)

SignalR currently provides three backplanes:

  • Windows Azure Service Bus. Service Bus is a messaging infrastructure that allows components to send messages in a loosely coupled way.
  • Redis. Redis is an in-memory key-value store. Redis supports a publish/subscribe (“pub/sub”) pattern for sending messages.
  • SQL Server. The SQL Server backplane writes messages to SQL tables. The backplane uses Service Broker for efficient messaging. However, it also works if Service Broker is not enabled.

If you deploy your application on Windows Azure, consider using the Azure Service Bus backplane. If you are deploying to your own server farm, consider the SQL Server or Redis backplanes.

The following topics contain step-by-step tutorials for each backplane:

Implementation

In SignalR, every message is sent through a message bus. A message bus implements the IMessageBus interface, which provides a publish/subscribe abstraction. The backplanes work by replacing the default IMessageBus with a bus designed for that backplane. For example, the message bus for Redis is RedisMessageBus, and it uses the Redispub/sub mechanism to send and receive messages.

Each server instance connects to the backplane through the bus. When a message is sent, it goes to the backplane, and the backplane sends it to every server. When a server gets a message from the backplane, it puts the message in its local cache. The server then delivers messages to clients from its local cache.

For each client connection, the client’s progress in reading the message stream is tracked using a cursor. (A cursor represents a position in the message stream.) If a client disconnects and then reconnects, it asks the bus for any messages that arrived after the client’s cursor value. The same thing happens when a connection uses long polling. After a long poll request completes, the client opens a new connection and asks for messages that arrived after the cursor.

The cursor mechanism works even if a client is routed to a different server on reconnect. The backplane is aware of all the servers, and it doesn’t matter which server a client connects to.

Limitations

Using a backplane, the maximum message throughput is lower than it is when clients talk directly to a single server node. That’s because the backplane forwards every message to every node, so the backplane can become a bottleneck. Whether this limitation is a problem depends on the application. For example, here are some typical SignalR scenarios:

  • Server broadcast (e.g., stock ticker): Backplanes work well for this scenario, because the server controls the rate at which messages are sent.
  • Client-to-client (e.g., chat): In this scenario, the backplane might be a bottleneck if the number of messages scales with the number of clients; that is, if the rate of messages grows proportionally as more clients join.
  • High-frequency realtime (e.g., real-time games): A backplane is not recommended for this scenario.

Enabling Tracing For SignalR Scaleout

To enable tracing for the backplanes, add the following sections to the web.config file, under the root configurationelement:

<configuration>
  <system.diagnostics>
    <sources>
      <source name="SignalR.SqlMessageBus">
        <listeners>
          <add name="SignalR-Bus" />
        </listeners>
      </source>
      <source name="SignalR.ServiceBusMessageBus">
        <listeners>
          <add name="SignalR-Bus" />
        </listeners>
      </source>
      <source name="SignalR.ScaleoutMessageBus">
        <listeners>
          <add name="SignalR-Bus" />
        </listeners>
      </source>
    </sources>
    <switches>
      <add name="SignalRSwitch" value="Verbose" />
      <!-- Off, Critical, Error, Warning, Information, Verbose -->
    </switches>
    <sharedListeners>
      <add name="SignalR-Bus" 
          type="System.Diagnostics.TextWriterTraceListener" 
          initializeData="bus.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>
  . . .
</configuration>

[Discovery] Lợi ích không ngờ khi con người tức giận

Chúng ta thường cho rằng việc tức giận có thể đánh thức phần “con” bên trong mỗi con người và có sức tàn phá khủng khiếp. Tuy nhiên, mọi cảm xúc sinh ra đều có lý do riêng của nó. Các nhà khoa học đã phát hiện ra thực chất việc nổi đóa lại có thể mang tới những “lợi ích” không ngờ.

1. Giận dữ giúp ích trong cuộc thương lượng

Bạn cho rằng, trong cuộc thương lượng chỉ cần đến sự bình tĩnh và tỏ rõ sự thông minh hơn đối phương? Nhưng sự thật không hoàn toàn như vậy.

Tất cả những tương tác cá nhân đều hoạt động trên một mức độ cảm xúc và trí tuệ nhất định. Nghiên cứu chỉ ra rằng, đôi khi nổi giận cũng có thể đem đến lợi ích không ngờ.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 1
Bởi lẽ chúng ta có xu hướng thận trọng hơn khi có ai đó nổi giận. Do vậy nếu bạn có thể thể hiện thái độ không hài lòng và bực mình một tẹo, điều này sẽ khiến đối phương cố gắng đưa thêm những quyền lợi và nhượng bộ bạn hơn.

Tuy nhiên không phải lúc nào sự giận dữ trong lúc thương lượng cũng đem đến hiệu quả. Thứ nhất, điều này chỉ hiệu quả khi bạn làm việc với người châu Âu và châu Mỹ, các nền văn hóa châu Á coi việc giận dữ là biểu hiện của sự thô lỗ. Mất bình tĩnh rất dễ dẫn đến đổ bể cuộc thương lượng.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 2
Thứ 2, nếu có ý định giận dữ, bạn phải thưc sự nổi cơn tam bành. Nếu đối phương phát hiện bạn chỉ đang giả vờ, họ sẽ càng đưa ra thêm những yêu cầu khác. Những cơn giận giả tạo chỉ khiến người khác mất lòng tin vào bạn và họ sẽ càng tỏ ít thái độ hợp tác hơn mà thôi.

2. Sự giận dữ có lợi cho sự nghiệp của bạn

Nhiều nghiên cứu chỉ ra rằng, người hay thể hiện sự tức giận ra ngoài thường có sự nghiệp và cuộc sống tốt đẹp hơn những ai kìm nén cảm xúc vào bên trong.

Một số nghiên cứu đã chỉ ra rằng: khi bạn tỏ thái độ giận dữ, mọi người sẽ nghĩ bạn xứng đáng với vị trí tốt hơn và mức lương cao hơn… nhưng chỉ khi bạn là nam giới.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 3
Theo đó, cả đàn ông và phụ nữ đều chung một quan điểm rằng, người đàn ông hay giận dữ đều đáng được khen thưởng. Trái lại, cả 2 phái công nhận, những cô nàng hơi tí lại nổi điên lên chỉ thể hiện sự kém cỏi của bản thân mà thôi.

Quy tắc này cũng có thể áp dụng khi bạn đi phỏng vấn xin việc, cho dù mức độ cao thấp của vị trí đó tới đâu, chỉ cần tỏ “thái độ”, bạn hoàn tòan có cơ hội được nhận.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 4
Theo nghiên cứu, mức lương trung bình của những quý ông hay cáu là 38.000 USD (khoảng 790 triệu VND) trong khi con số này ở các quý bà chỉ là 23.000 USD (khoảng 478 triệu VND).

Bên cạnh đó, khoa học cũng chỉ ra rằng, khi phụ nữ giải thích lý do cáu giận, họ sẽ được mọi người nhìn nhận một cách công bằng hơn. Tuy nhiên nếu các quý ông làm vậy thì sẽ bị dánh giá là người yếu đuối.

3. Giận dữ giúp bạn sống lâu hơn

Ít ai ngờ rằng, những cư dân Ý sôi nổi và người Tây Ban Nha nóng nảy lại có tuổi thọ trung bình cao hơn 2 năm so với dân Anh điềm tĩnh. Từ đó có thể suy ra rằng, việc hay giận dữ thực chất lại có lợi cho sức khỏe của bạn.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 5
Nghiên cứu cho thấy những người hay nén sự tức giận và thất vọng thường dễ chết hơn bởi việc làm này khiến huyết áp của bạn tăng cao. Huyết áp cao làm tăng nguy cơ mắc tất cả các loại bệnh, từ bệnh tim cho tới ung thư.
Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 6
Những người có mức độ cáu giận vừa phải có nguy cơ đau tim giảm một nửa và nguy cơ đột quỵ thấp đáng kể so với những quý ông ít tỏ ra cáu giận.

4. Giận dữ giảm tỉ lệ tội phạm

Các nhà tâm lý học và phụ huynh đều cho rằng, những trò chơi bạo lực sẽ làm tăng xu hướng bạo lực ở trẻ. Tuy nhiên chứng minh cho thấy trò chơi điện tử thực tế lại có thể làm giảm khả năng phạm tội.

80% nam sinh trung học chơi các trò bạo lực đẫm máu và cũng trong cùng thời gian đó, tỷ lệ tội phạm có dấu hiệu giảm. Số lượng thanh thiếu niên phạm tội giảm hơn một nửa kể từ năm 1994. Trong khi đó, doanh số bán ra của các các trò chơi điện tử được cho là “đục khoét tâm hồn” lại tăng gấp đôi kể từ năm 1996.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 7
Một nghiên cứu khác còn chỉ ra rằng, những tháng có tỉ lệ tội phạm thấp nhất lại là những tháng mà doanh số bán ra của trò chơi bạo lực đạt mức cao nhất. Vậy những trò chơi này đã giúp kìm chân những tên phạm tội trong nhà hay thực sự mở ra con đường giải thoát cho bản tính hung hãn của con người?

Nghiên cứu tập trung vào đối tượng trẻ em có dấu hiệu trầm cảm đã phát hiện ra rằng trò chơi điện tử bạo lực có tác dụng nhẹ trong việc giúp con người trở nên bình tĩnh hơn, làm gảm xu hướng bạo lực và các hành vi bắt nạt.

Các nghiên cứu khác cho thấy trò chơi điện tử thực chất không làm giảm tính vị tha của con người. Vậy tại sao lại có rất nhiều bài báo cáo buộc trò chơi điện tử? Đó là bởi trò chơi quá khó có thể khiến chúng ta tức điên lên, đây là lý do tại sao mà nhiều người đánh đồng chơi điện tử bạo lực đồng nghĩa với việc người chơi có xu hướng trở nên hung hãn hơn.

5. Giận dữ giúp tăng tính sáng tạo

Bạn gặp khó khăn trong việc đưa ra ý tưởng sáng tạo? Hãy thử nổi điên lên và bạn có thể tư duy khác với lối mòn thông thường. Con người khi tức giận sẽ nảy ra những ý tưởng độc đáo nhanh hơn khi chúng ta ở bất kì trạng thái cảm xúc nào khác.

Tuy nhiên quá trình kích thích khả năng sáng tạo này sẽ không kéo dài lâu.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 8
Các nhà khoa học cho rằng, nhờ việc phát triển khả năng tức giận mà người cổ đại có thể đưa ra những giải pháp nhanh chóng và sáng tạo khi phải đối mặt với những tình huống nguy hiểm trong cuộc sống.

Việc cáu giận vừa có thể tiếp thêm sức mạnh và mang lại cho con người một quá trình suy nghĩ linh hoạt và bớt cứng nhắc. Về cơ bản, trạng thái giận dữ sẽ khiến bạn giải quyết cùng một vấn đề nhưng với phương pháp hoàn toàn khác so với khi bình tĩnh.

Chính vì vậy, việc giận dữ và không thể suy nghĩ một cách rõ ràng, thông suốt đôi khi lại là một điều tốt.

6. Tranh cãi tốt cho mối quan hệ của bạn

Hãy quên đi những chân lý như tình yêu là phải tha thứ và quên đi lỗi lầm. Theo các nhà nghiên cứu tại trường ĐH bang Florida, tức giận đôi khi lại là liều thuốc tốt nhất.

Trong sức khỏe tâm thần tồn tại một cách tiếp cận có tên gọi “tâm lý tích cực”. Theo đó, một mối quan hệ tốt nên có các yếu tố “tha thứ, lạc quan, tốt bụng, suy nghĩ tích cực”, tuy nhiên, điều này trong thực tế lại gây ra những rắc rối nghiêm trọng.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 9
Đôi khi việc tha thứ không thể chữa lành nỗi đau mà chỉ khiến sự việc trở nên tồi tệ hơn. Các nhà nghiên cứu cho biết nếu bạn vô tư ban phát sự tha thứ của mình cho mọi người thì dù muốn hay không, một trong số đó sẽ lợi dụng điều này và tiếp tục đối xử tệ với bạn.

Những người nổi điên lên sẽ cho đối phương biết rằng, hành vi của họ là không thể chấp nhận và họ cần chấm dứt việc đó. Những cặp đôi giận ở trong lòng lại có khả năng chết sớm cao gấp đôi. Chính vì vậy việc cãi nhau không có gì là xấu cả, điều đó thực ra lại có lợi cho bạn.

7. Giận dữ thu hút những cô gái hơn

Khoa học cũng phải thừa nhận rằng, đàn ông tồi lại thu hút nhiều quý cô. Hai nghiên cứu đều cho thấy, những người sở hữu các tính cách được coi là “bộ ba đen tối” bao gồm bệnh thái nhân cách, chứng quá yêu bản thân và xảo quyệt lại thường có nhiều bạn gái.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 10
Dù biết rằng những tính cách này không đem lại ích lợi gì cho xã hội nhưng các cô gái khờ dại vẫn đâm đầu vào lưới tình. Khoa học cho biết các cô gái thường bị thu hút bởi những người đàn ông hay tỏ ra buồn rầu, ủ rũ trong khi một chàng trai vui vẻ lại bị bỏ quên.

Nguyên nhân thực sự vẫn chưa được lý giải nhưng lý do có thể nằm ở nội tiết tố nam. Phụ nữ thường bị thu hút bởi những quý ông có tiết tố nam cao và những người này lại thường có tính đàn áp. Tuy nhiên hãy cẩn thận vì tuýp đàn ông này thường có thiên hướng nói dối và khó có thể xây dựng một mối quan hệ ổn định lâu dài.

8. Cơn giận giúp bạn giải phóng đầu óc

Thử tưởng tượng một nhóm người đang nói xấu bạn thân của bạn, lúc đó bạn cảm thấy thế nào? Đầu tiên bạn sẽ nổi điên lên nhưng cuối cùng cảm giác còn lại chính là sự lạc quan.

Khi bạn phải đối mặt với một tình huống căng thẳng, việc giận dữ sẽ giúp bạn có cảm giác mình đang nằm trong tầm kiểm soát và thấy lạc quan hơn về tương lai.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 11
Tức giận có hiệu quả tích cực hơn là sợ hãi, nếu bạn phản ứng bằng sự lo sợ, bạn sẽ chỉ càng cảm thấy chán nản và điều này không giúp bạn giải quyết được vấn đề.

Điều này có thể áp dụng cho cả đàn ông và phụ nữ, những người phản ứng lại một cách giận dữ sẽ cảm thấy chắc chắn và kiểm soát được tình huống tốt hơn.

Sự tức giận mang lại cho chúng ta sức mạnh và có khả năng giải quyết được những trường hợp cực kì căng thẳng. Tuy nhiên bạn cũng không nên quá lạm dụng nếu không muốn trở thành người dễ dàng nổi cáu.

9. Và cuối cùng, điều đó giúp bạn lạc quan hơn

Nghiên cứu từ ĐH Carnegie Mellon cho thấy, khi bạn ở một tình huống căng thẳng, một chút giận dữ sẽ giúp bạn giữ mọi thứ trong tầm kiểm soát và cuối cùng sẽ giúp bạn lạc quan hơn trong tương lai.

Lợi ích chẳng ai ngờ khiến chúng ta muốn tức giận 12
Đó thực sự là cách phản ứng có lợi cho sức khỏe hơn là chỉ biết sợ hãi. Và nó hiệu quả trên cả nam giới lẫn nữ giới. Một nghiên cứu khác được thực hiện chỉ ra, những người thể hiện thái độ tức giận từng trải qua cảm xúc chắc chắn và kiểm soát. Giận dữ có thể giúp chúng ta xử lí tốt trong những tình huống cực kì căng thẳng.

Theo MASK online