0

HTTP Strict Transport Security (Enable with CAUTION)

As Google is encouraging use of HTTPS on whole website so its good time to force whole website on HTTPS, typically you can do it by a simple redirect from your web-server but now you can do it even more efficiently at client level by passing an additional HSTS header.

Nginx:

add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

Apache:

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

This will tell the browser that the site should be accessible only via HTTPS so in-case you type http://yourdomain the browser itself redirect it to https://yourdomain (Once the header is received and browser stored the information locally for future use).

You can also submit your domain to include in HSTS Preloading list. This service will submit your domain for the inclusion in the Chrome list which is also followed by other major browsers. HSTS is supported by all mainstream browsers and you can find full compatibility matrix here. This list is hard-coded into browsers so the browser will automatically use HTTPS for domains included in that list.

So far all good so where is the CAUTION!

If you want to use HSTS then you must be sure that you will be supporting HTTPS on whole site for a long period and specially when you are submitting it for HSTS Preloading. Those lists are hard-coded in browsers and does not have any method to de-list your domain and even if you are able to submit the de-list request then it may take months to take effect as this involves approval of request, update list in newer version of browsers, release of newer version of browser etc, but this is still not enough until your visitors /users have the newer browser version installed.

So whenever your are going to use HSTS put special attention on “max-age”, “includeSubdomains”, “Preloading” and “HSTS Preload Submission” otherwise you will be in big trouble if you want to stop use of HSTS on your site or don’t want to use HTTP on any sub-domain etc, also if your certificate is bad i-e expired, bad_cert_domain etc then browser won’t allow you to bypass or proceed for HSTS enabled sites.

0

Magento Performance Tips [Rare]

By now you must have gone through tons of optimization tips related to Magento but here I am going to share my personal experience of fighting with Magento and these tweaks really helped me to improve overall Magento performance and good thing is most are also applicable to most of other PHP+Mysql based applications.

I was stuck with performance issues and I tried almost all the common suggestions spread over different sites and forums but I was still not able to achieve and fix some of issues. So what I did?

  1. Get a faster clock speed per core and latest generation CPU. Believe me no of cores and amount of Memory sound good on paper but they will only help you when you have to handle more no of visitors at given time but if you want to decrease PHP page generation time then only faster clock speed core will help you as normal visitor’s request is handled by only a single core so a faster core can only finish the job in lesser time.
  2. No one can beat the power of a Physical server so always go for a Dedicated server instead of Cloud or VPS or any type of virtualized server if you can design a reliable Disaster Recovery plan.
  3. If you have enough computing power on your web server then always go for local Mysql instance as it will provide you better performance compare to remote Mysql server.
  4. Move Magento ‘cache’, ‘full_page_cache’ and ‘session’ folder on a ‘tmpfs’ based RamDisk. I was having random high IOPS issues and moving them to RAMDisk sorted it.
  5. If you seeing high percentage of Mysql temporarily tables created on disk despite keep increasing ‘tmp_table_size’ and ‘max_heap_table_size’ values then most probably your application is using much TEXT and BLOB columns so allocating more memory won’t help you and in that case you can try moving Mysql ‘tmpdir’ to a RAMDisk (with caution).
  6. Play with XFS or EXT4 filesystems and see which work best with your environment.
  7. Upgrade PHP to 5.5 and use OPcache instead of APC or APCu.
  8. Upgrade Mysql to 5.6
  9. In case of Apache move all .htaccess rules to virtual host, you can try with ‘AllowOverride None’ altogether.
  10. Disable Mysql slow query log and binlog.
  11. Disable PHP slow_log.
  12. Disable Magento System and Exception logs as well as Profiler.
  13. You can also try mounting Mysql ‘data’ directory and ‘/var/www/’ with ‘noatime’ option.
  14.  Prefer using “Unix Socket” for PHP-FPM and Mysql over TCP/IP. Same applies to ‘Redis’ and “Memcached”.
  15. Create all unix sockets in RAMDisk (tmpfs) instead of disk.
  16. If you are seeing random 502, 499 errors in nginx (while CPU, Memory, I/O, database etc looks stable) with PHP-FPM “Unix Socket” then switch to TCP/IP or increase listen.backlognet.core.somaxconn and ulimit values.
  17. Try newer PHP Mysql driver ‘mysqlnd’ over ‘libmysql’.
  18. Try PHP memcached driver over memcache
  19. Setup “Parallel Downloads” for different type of content.
  20. Setup HTTP/2 or SPDY to improve HTTPS performance.
  21. Use external Analytics like GA.
  22. Properly setup robots.txt and block bad bots and private areas of site and define a crawl delay.
  23. Replace regular Search and Layered Navigation from Solr or Sphinx, I personally using Algolia.
  24. Setup scheduled “Magento Log Cleaning”.

Obviously along with above suggestion you still need to apply all those tweaks and tips which you already know most.

0

How To Get The Most Out of AWS Free Tier | Free VPS Server

Today I will explain how to make efficient use of AWS EC2 Free Tier. I was using DigitalOcean 512M server for my blog and paying them $5 each month and it was working absolutely fine for my site. I then realized why should not try AWS Free Tier.

AWS Free Tier is providing 12 month free service with some limitations mainly 750 hours of “t2.micro” EC2 instance (1G memory) which make it a whole month, 30GB General Purpose SSD or Magnetic storage (EBS), 15 GB of bandwidth and many other free services like RDS, S3 etc which we discuss later. To see what included in Free Tier you should read below before start deploying any thing.

http://aws.amazon.com/free

To get start you just need to sign-up for new AWS account and for it you just need a valid Credit Card, Phone no and email address. Once you finished setting up and verifying the account make sure to confirm whether you are eligible for Free Tier or not by visiting “Billing & Cost Management” where you should find You are eligible for the AWS Free Usage Tier. See the Getting Started Guide AWS Free Usage Tier to learn how to get started with the free usage tier. under “Alerts & Notifications”.

Now the tricky part is how to distribute the limited resources we have and design a good architecture which provide decent performance, capacity and basic disaster recovery. Below is my configuration which I used to start with.

  1. “Ubuntu Server 14.04 LTS (HVM), SSD Volume Type” based “t2.micro” EC2 instance. (HVM perform slightly better then PV)
  2. 20GB General Purpose SSD for Root volume which also hold your application data. (/var/www)
  3. 10GB General Purpose SSD as BACKUP disk where we store on-site backups.
  4. “db.t2.micro” instance for RDS with 20GB database storage.
  5. 20GB of backup storage for RDS database backups / snapshots.
  6. Mount 5GB S3 bucket (different region then server) for off-site backups.

This type of configuration is a good start for small sites or personal blogs etc which provide decent performance, capacity and reliable disaster recovery while ensuring you still fall under Free Tier limits.

Now most you are also looking for a static IP for your server so good news is that you can also allocate an EIP and attach it with your instance and Amazon wont charge you for it unless it is associated with a running instance. As you are done with setting up the server its time for one more step and this involve requesting Amazon to white-list your EIP and create relative rDNS record so you can send emails from your application and server.

https://aws.amazon.com/forms/ec2-email-limit-rdns-request?catalog=true&isauthcode=true

Lastly an important point is to keep your eyes on your AWS account billing and make you nothing is adding to your bill. You can do it by going to “Billing & Cost Management”.

Tools I used for backups are below.

On-Site Backup: mysqldump & rsnapshot

Off-Site Backup: S3backer, duplicity, s3cmd

Note that do not take EBS Snaphots as Amazon is providing only 1GB snapshot storage for free. EBS Snapshots are crucial for your DR but unless your are ready to pay don’t use them.

UPDATE:

You can also create a CloudWatch monitor which will send email notification to you when your monthly cost for any service will be higher then $0. Again you need to visit “Billing & Cost Management” and under “Alerts & Notifications” you will find a message Your account is enabled for monitoring estimated charges. Set your first billing alarm to receive an e-mail when charges reach a threshold you define.So just click on Set your first billing alarm and setup a Alarm with ‘0’ value and your email address, Voila.