0 Comments
  •   Posted in: 
  • DNS

Sometimes we have to change the IP in the DNS records to a site. As I did not want to enter IP multiple times I researched the simplest way to define DNS records. You only have to define the IP once. The other records (for instance subdomains hosted via the same IP) you can define as CNAME records. Use wildcard DNS records to minimize the list of records you have to define. With wildcards for subdomains you can route the user to your site even if the user misspelled the subdomain – let your application handle the mistake and still answer the request properly.

That way I reduced our DNS records to two: one A record with the IP, and one CNAME wildcard record pointing to the A record. If I need to change the IP again I will only have to do that at one point.

example.com    A     192.0.2.1
*.example.com CNAME example.com

0 Comments

We use TeamCity on our servers to run unit test, performance tests and deployments. By now we rely heavily on the processes which we configured in TeamCity. In case we lose a server, we would like to have backup of all the configuration of TeamCity on that server.

To create daily backups we use TeamCitys REST API. There is an endpoint for Data Backup. I found a script written by Ivan Leonenko, which encapsulates the API call in a powershell script. If you want to then create a repeated Task Scheduler task, here is a step-by-step blog post on how to do that. Since we do all our backups with SyncBack, I created a repeated runner there which executes the powershell script. After that JungleDisk takes care of copying the backups to Amazon S3, where we would find our backup copy in case the server and its data is lost.

0 Comments

We decided to look into performance issues of our discoverize portals. We used online tools like WebPageTest, PageSpeed Insights, Website Grader, Pingdom Website Speed Test and GTmetrix to analyze the responses to web requests to our portals. Enabling browser caching and bundling JavaScript files were among the most important tasks. We took a look at PageSpeed Module which takes care of many these performance problems, and decided to give it a try.

After installing and configuring PageSpeed Module on a NGINX server we started to route discoverize portals through the NGINX proxy server.

I started with the core filters in PageSpeed Module and added a few which I deemed necessary. Here is our filter configuration:

pagespeed on;
# CoreFilters is default and enables multiple filters
pagespeed RewriteLevel CoreFilters;
# add additional filters
pagespeed EnableFilters defer_javascript,insert_image_dimensions;

And yes, we improved the performance of our portals. Especially for users which visit us frequently and request many pages of the portal. For instance for Caravanmarkt.Info our PageSpeed Insight score went from 76 to 86 (start page), 72 to 81 (search page), 71 to 86 (detail page). The other tools reported similar results. I also tested Glamping.Info, with similar results – this portals’ PageSpeed Insight score was lower to begin with, but improved  by the same amount. The page load time also decreased, but we do not have reliable measurements for that, and it is just one time measurement out of many which have an impact on the user experience.

2015-11-16_16h52_28

Looking at some of the analyses, there is is – of course – further room for improvement. For now we will leave it that way. Next year we will look into the remaining performance issues, for instance first byte time. Now we have a good setup with PageSpeed Module to address many performance issues.

Of course I also ran into some problems. Many filters were not easy for me to understand, since this was the first time we looked into the performance of our websites, and I was new to many concepts. One problem particularly kept haunting me: every five minutes PageSpeed did not bundle the JavaScript files and requested all resources anew. Seems that was due to changing ETags in the headers (bouncing between two ETags). Luckily that only concerns one portal, so for now we can live with that.

0 Comments

Today I went to the Global Day of Coderetreat 2015 in Berlin. What is Coderetreat? In one sentence: It is a day-long event where you meet with strangers and pair program with a few of them in whatever language you want, doing TDD.

I stayed for four sessions, programming twice in C#, once in PHP and once in Java. It was a nice experience, but I probably will not attend another Coderetreat. It was well organized (ok, the promised breakfast was missing). We were about 50 people gathered in the offices of Wooga.

In the end it was about talking with others about how to approach the same problem over and over again, and practicing test driven development. It got old pretty fast. We always tried to implement Game of Life.

I know I should program at work more in the TDD style, yet I mostly know how to do TDD. Today I only learned few new things, if any. I think the time would be better spend if I used it to delve deeper into other areas, like Angular, MVC, EntityFramework or the like. Or create a site from scratch. That is why I did not stay for the last two sessions.

Coderetreat may be a good possiblity to get to know TDD and test out pair programming. Or attend it if you like to meet other programmers from diverse backgrounds.

0 Comments

To optimize the performance of our discoverize portals we decided to try out the PageSpeed Module. Since we already have a little experience with NGINX, we decided to install NGINX(version 1.8.0) with the PageSpeed Module (version 1.9.32.10) on our CentOS 6 and CentOS 7 servers.

Installation:

  1. use guide: https://developers.google.com/speed/pagespeed/module/build_ngx_pagespeed_from_source
    1. ngx_pagespeed was not saved as .zip file, but without file extension – adjust the unzip command accordingly
    2. if needed add other modules to the NGINX configuration before installing NGINX, for instance the ngx_http_ssl_module:
        ./configure --add-module=$HOME/ngx_pagespeed-release-${NPS_VERSION}-beta --with-http_ssl_module
    3. If you install with the http_ssl_module you may have to install OpenSSL libraries first. yum install openssl will probably not suffice, yum install openssl-devel will be needed (you may wonder why ./configure states that OpenSSL is not available even though it is installed – what it really needs is openssl-devel).
    4. if only over-installing nginx, do not forget to restart the nginx service (reload will do nothing)
  2. create NGINX init script: https://www.nginx.com/resources/wiki/start/topics/examples/redhatnginxinit/
    1. adjust folder paths in that script:
      1. nginx="/usr/local/nginx/sbin/nginx" (line 22)
      2. NGINX_CONF_FILE="/usr/local/nginx/conf/nginx.conf" (line 25)
    2. give init script sufficient rights: rwxr-xr-x
  3. create log rotation script: http://www.scalescale.com/tips/nginx/how-to-rotate-nginx-logs/

Uninstall:

There is no uninstall parameter in make for NGINX. Just remove the folders and files: sudo rm -f -R /usr/local/nginx && rm -f /usr/local/sbin/nginx && rm -rf /etc/init.d/nginx

Configuration:

  1. configure NGINX as proxy for web site
    1. there are many guides out there, for instance: https://www.nginx.com/resources/admin-guide/reverse-proxy/
    2. proxy_set_header has to be set, so backend server knows which application should reply
    3. proxy_http_version has to be set to 1.1 – otherwise only parts of page may be transferred
  2. enable the module: https://developers.google.com/speed/pagespeed/module/configuration
    1. use tmpfs for the caching folder: https://developers.google.com/speed/pagespeed/module/faq#tmpfs 
  3. configure filters for PageSpeed Module: https://developers.google.com/speed/pagespeed/module/config_filters
    1. let PageSpeed take care of compressing the response: do not activate gzip, PageSpeed will automatically configure it

    2. try out the filters which are not automatically enabled with the RewriteLevel CoreFilters

All in all it is not an easy task to get the PageSpeed Module working, but in the end it is surely easier and faster to let it optimize your web site responses instead of implementing all the different optimizations.

Since our backend server are Windows server we briefly considered using the IISpeed wrapper for the PageSpeed Module, but went with NGINX. Maybe IISpeed is easier to install and to configure. If you have experience using IISpeed, I would like to read a comment about ist usability.