尼欧のメモ帳

# Diagnostic timeout exceptions in StackExchange.Redis for Azure Redis Cache ## Problems  >Timeout performing HEXISTS XXX.YYY:OAuthTokenStorages:AccessToken, inst: 267, mgr: Inactive, err: never, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 0, ar: 0, clientName: RD__________F9, serverEndpoint: Unspecified/xxx.redis.cache.windows.net:6380, keyHashSlot: 1758, IOCP: (Busy=0,Free=1000,Min=1,Max=1000), WORKER: (Busy=45,Free=32722,Min=1,Max=32767) (Please take a look at this article for some common client-side issues that can cause timeouts: http://stackexchange.github.io/StackExchange.Redis/Timeouts) ![Picture-02](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIXtx8dOfcuMK6suzswKbCU59eUVEX28TjoRhnwq9xyGm...

There are two SPs perform complicated commands on the same table in our product. Our DBA said he didn't know how to reduce the deadlocks. After Google the key word 'minimizing deadlocks', I found this official document: Key-Range Locking According to above document and this  example , if I select data rows by parameter on non-unique index and then perform some operations, I will only lock these rows. Need some tests......

Reference We should set the scale mode according to the using of app service plan or work pool of ASE. For example, we have many webjobs in a work pool, and we use service bus messages to trigger webjobs. Under this condition, we should use message counts as scale in/out rule. To be continued...

According to these references, we can get telemetry data from virtual machine by these steps: Install Application Insights Status Monitor on Windows Server (VM). Update it to latest version. Run 'lusrmgr.msc' and add the IIS AppPool account(s) into 'Performance Monitor Users' group. Reset IIS. Reference: Instrument web apps at runtime with Application Insights Reference: Application insight monitor doesn't send data to portal due to insufficient permission

After we deployed the OAuth of our product to Azure, we found that we have to spend more than 2000ms (on Azure VM) or 5000ms (on Azure app service) to complete the authentication flow. So these two days I was focus on tuning the performance of authentication. The codes was written by a senior, and after many times of requirement modification or adding, it became a terrible monster. First we read the two specifications of log-in flow, and the codes of 'OAuthAuthorizationServerProvider.GrantResourceOwnerCredentials'. Then we re-organized the log-in flow, and find some obvious performance issues: Hit database more than 15 times. Misuse the method of modifying customer information. It will check some unique fields, such as email, phone, QQ, wechat and nickname. There is even no index created on the column of 'wechat'. Check the customer's device. The codes here query the member devices many times. We should reduce it to one time, or pass the current log-in dev...