A social media update that includes an image will be clicked much more then one without. Most updates today includes thumbnails to make the update more attractive for the end-user. When a blog, or other web site, shares content via share links or automatic updates the receiving site uses different methods to draft up the update layout. Most sites use the Open Graph protocol to do this, and the implementations differs a bit from site to site. LinkedIn however makes different implementations each time it seems.
Before you start doing any search engine optimization (SEO) work on your site you should implement tracking on your site. If you don't track events on your site you will not be able to target your SEO efforts and follow up on the results. If you haven't read my SEO Basics post you should take some time and do that. In that post I talk about tracking in two different ways, both tracking your visitors (or traffic) as well as "tracking" your site content behavior via Google Webmaster Tools. In this post I will explain more about the tracking part of SEO.
So the new issue on the board is shellshock? Not really it has been around for 20 years but hasn't been a problem until now. Same with heartbleed, was there for over two years before it was discovered. I will show you how to check if your effected and how to stay safe.
The heartbleed vulnerability dropped like a bombshell, a large majority of web servers on the internet was sharing there memory with the world. The even bigger bombshell was that the vulnerability had existed for over two years. Most people consider open source more secure then proprietary code since anyone can verify that it's safe. The problem is that most people think that someone else already done that!
Running WordPress on Google App Engine is possible but different from any other hosting you ever used. Stability and performance are really great but it comes at the price of flexibility. In return you get a highly scalable and robust solution for your website. After running a few months on Google App Engine platform I switched again and in this article I will tell you why.
Structured data helps Google Bot and other web crawlers to understand and interpret your data. By tagging your data with structured data tags like MicroFormats h-entry Google can index all relevant information. The tags also affects your search appearance, i.e. what your site looks like in the Google search results. You can also be sure that this will effect your page rank!
The Amazon EC2 Linux instances comes without swap. Sooner or later this will be a problem with service hangups or crashes as a result because you run out of memory. I found a lot of instructions on the web about how to add a swap file but no one takes the storage into concern and you may end up paying a lot for a very little performance gain. This article will guide you through swap files on Amazon EC2 linux hosts.
To be honest I had limited knowledge about SEO (Search Engine Optimization). Haven't really spent much time or reflected about it at all. But then I started looking through my Google Analytics info for this site and realized that most of my traffic isn't from referrers, like links or articles I wrote on other sites, but from Google Search. That put it in an whole other perspective for me, and also I started receiving a lot of traffic, upgraded my servers, and realized that some Google Adsense would be in place to pay for the servers. So my thought was to do a series of articles about improving SEO for this site.
Where to start?
If you start searching for SEO on Google you get a lot of information but also a lot of BS. The golden rule here is if anyone promises a specific ranking they are not for real. You can do all you can about SEO but at the same time your competitors might have done a better job. Start by reading the Official Google Optimization Starter Guide.
You should also, if you haven't already, implement Google Analytics on your site. It's an easy way to track you visitors and views and find room for improvement as well as follow your sites progress.
Google provides information and recommendations without telling us exactly how the ranking works. The internet is overflowing of people claiming to know something you don't but as I sad before if it sounds to good to be true it probably is! Instead go to the source of the information, Official Google Webmaster Blog.
There are a lot of settings that you can tweak to get higher performance out of your Microsoft SQL Server. The most basic one is IO performance, i.e. disk performance. Usually when I talk to people about this I get the response that this is an art form and something that most techs don’t know about or feel that they don’t understand. Most people rely on the SAN team to take care of this but if you don’t understand this and can inform the SAN team what you need you will get the standard. Most SAN system are optimized for There are always more tweaks that can be applied but in most cases the further you come along this line the smaller impact the changes have. In this article I would like to point out the most basic, and important, performance issues with Microsoft SQL Server that are easy to address. These are independent of size of the solution or underlying hardware e.g. local attached discs or SAN.
To understand why this is so important you need to know a little about how Microsoft SQL Server reads from the disk. To simplify Microsoft SQL Server reads pages, pages contains a number of rows with you corresponding data. The pages with extents are 64kb in size. So the goal here is to read (or write) the page with as few disc IO’s as possible.
Stripe Unit Size
The stripe size is the smallest chunk of data that can be addressed within the RAID. So make sure you are using at least 64KB stripe size. If it’s a larger number like 128KB or 256KB that only means that you can write several more pages in the same stripe, this can actually benefit performance of the read ahead function in Microsoft SQL Server.
File allocation unit size / Disc cluster size
This setting is on the file system level. Microsoft SQL Server is designed for the NTFS file system and the default NTFS disc cluster size is 4KB. Again this should be 64KB for best performance, it enables SQL server to do less IO than a smaller cluster size does. There is a correlation between cluster size and stripe unit size that needs to be meet for optimal performance:
Stripe Unit Size ÷ File Allocation Unit Size = an integer
If possible you should try to meet this formula. However that isn’t always possible due to different storage systems. The most important thing for performance in that case is to use the 64KB cluster size! The formula for partition alignment below is however not optional for performance!
Partition alignment (partition offset)
When I have been talking to people about this most people look at me like I’m crazy. A system that was setup from a clean install of Microsoft Windows Server 2008 and later doesn’t suffer from this, these versions do an automatic alignment of the partition. If the partition isn’t aligned your server will end up splitting the read and write IO into two or more IO’s. This is very bad for performance.
Role of thumb here is:
Partition Offset ÷ Stripe Unit Size = an integer
Old systems prior to Microsoft Windows Server 2008 could end up with a 31.5KB offset (63 hidden sectors * 512b sectors). Doesn’t matter what stripe unit size you have 4,8,16,32,64,128…. It will never make the equation spit out an integer! Therefor bad for performance!
So if your system is prior to Microsoft Windows Server 2008 or have disk partitions created by an earlier version, check the partition offset! It’s easily done by running this command:
wmic partition get BlockSize, StartingOffset, Name, Index
To check the stripe size you have to refer to your storage controller. Standard offset in Microsoft Windows Server 2008 and later is 1024KB and it doesn’t really matter what stripe unit size you have, you will still end up with an integer.
For SQL server log files you should use RAID 1 both for best read/write performance but also for the extra data security. In a raid one you can lose 50% of your disks without losing data, neither RAID 5 or RAID 10 can guaranty this data safety. It will however cost you half of the storage space.
Do you want to read more?
Written by Jimmy May, Denny Lee and goes deeper into the techniques.
Why not run WordPress on Google App Engine? You will get performance and stability while only paying for the resources you actually use. Reading the official Google tutorial "Running WordPress in App Engine" it gives you a fare idea what you are in for. But if you want to migrate a currently running site then you have to do some tweaking. So here is a run down on how to do it!