We’re using ElasticBeanstalk Blue/Green deployment by swapping DNS, and in front of the deployed services, there’s a company level Nginx to forward requests to different services. The TTL of DNS entry set to 1 minute, and Nginx will cache the resolved name entries until it expired. Each time after we deploy, all the requests hit the new environment after the DNS cache expired in Nginx.
React Server Render time without warming up
The response time increases a lot in the following a couple of minutes and becomes stable after 5 minutes. Because the response time impacted by upstream services, it’s better to analyze and improve react server render time which is a sync method call and not involve IO operations.
Here’s the initial reactServerRender time for Home Page and Search Result Page:
For the Home page, it took 2-3 minutes for the reactRender time reduced from 450 – 550 ms to 120 ms
We are running Node.js web services behind AWS Classic Load Balancer. I noticed that many 502 errors after I migrate AWS Classic Load Balancer to Application Load Balancer. In order to understand what happened, I added Nginx in front of the Node.js web server, and then found that there are more than 100 ‘connection reset’ errors everyday in Nginx logs.
The number of errors was increased after I migrate Classic LB to Application LB, and one of the differences between them is Classic LB is using pre-connected connections, and Application LB only using Http/1.1 Keep-Alive feature.
Recently, I worked on a task which need to collect all CloudWatch logs to a Kinesis stream. The project is using Serverless for deployment. There are some plugins to create CloudWatch Log subscription filter, but none of them using Kinesis as the destination.
Then by using the serverless-scriptable-plugin, I’m able to do this very easily. The following code find out all CloudWatch LogGroups, and create a SubscriptionFilter for each of them.
I’m working on a project which needs to fetch messages from hundreds of SQS queues. We’re using SQS long polling to reduce the number of empty responses. It was very quick to get response at first when there are only dozen queues. As we added more and more queues, the performance getting worse and worse. It takes 60 seconds to get the response when there’s 300 queues and WaitTimeSeconds set to 10 seconds.
We are using Node.js in single thread mode, and I believe that it could handle 10 thousands connections without any problem because most of the tasks are IO processing. We also created an AWS support case, but nobody clearly answered the question.
From the documentation, AWS Lambda will retry failed function on stream-based events sources.
By using Node.js, we can fail the function by many different ways, e.g. using callback to return error, throw exception directly, throw exception inside Promise, using Promise.reject. Then the questions is, what’s the proper way to let AWS Lambda know it needs a retry?
I did an quick test on following scenarios by setting up DynamoDB Stream and event mappings. It’s fun to have a guess which one will be retried and which one won’t.
For convenience, options.stdio may be one of the following strings:
‘pipe’ – equivalent to [‘pipe’, ‘pipe’, ‘pipe’] (the default) ‘ignore’ – equivalent to [‘ignore’, ‘ignore’, ‘ignore’] ‘inherit’ – equivalent to [process.stdin, process.stdout, process.stderr] or [0,1,2]
I migrated my WordPress blog to a VPS hosting recently, and after that, the first thing that came to my mind was: Backup.
There were a lot of similar posts on the Internet, but what I found was not good enough for me, so I wrote what I did in this article to help people who want to do the similar things. It would be great if you have better ideas and please feel free to let me know.
The following scripts had been tested on: Ubuntu 13.04 and MySQL 5.5. The directory and scripts may need to be changed for different Linux distributions.
First, we need to answer the questions: what do we want to backup, what do not, and where to save the backup.
What do we want to backup? everything not from the setup, which includes:
Posts, Pages and Comments. They are the most important things that we want to backup.
Uploaded Media Files. They are the same important with the posts/pages.
The Installed Themes and Plugins. I don’t want to search, install, and customize them again, especially the colors.