I guess by "real" servers you mean actual hardware servers and not "virtual" - anyway... I use PIA and Air, PIA on our business systems and a mixture of Air and PIA on my personal systems and networks. PIA uses only "real" servers, actual hardware servers to the tune of well over 3000 of them. Before we chose PIA as our business VPN we verified they only use actual hardware servers and none virtual. The issue is not with the VPN service really, most is simply the nature of the beast and business necessity;
All OpenVPN based VPN networks have an immediate impact on 'connection speed' when you connect to them. 'connection speed' is actually the wrong term to use as its actually 'throughput' and not 'connection speed', what speed test sites are actually measuring is bandwidth which is not the same as throughput. There is really no such thing as 'connection speed'; The invented term was coined many years ago by ISP's as a selling point for their services because selling 'bandwidth' was a verifiable thing they could be held responsible for providing. Instead ISP's would call it 'connection speed' knowing that was not truly verifiable to the masses and get away with excuses for different 'connection speeds' or lack of it. Thus there were no legal grounds for service contract disputes based upon 'connection speed' and they could not be sued for not providing it. Anyway, then internet speed test sites supported and paid for by the ISP's appeared to reinforce the selling point concept of 'connection speed', people started commonly calling it 'connection speed' because that's how their ISP's sold their internet service to them and how the speed test site presented it, and others followed in the same way with other internet speed test sites using the same term 'connection speed', and today we have internet speed test sites calling their testing results 'connection speed' when it really isn't. So, doing this type of stuff for a living i'm going to use the actual correct term "throughput" in the rest of this.
1. The throughput impact imposed by OpenVPN based VPN networks on the users connection throughput is 10-15% on average for connections due to design considerations, 25-75% on average for router based connections. For the majority of users in reality its around 50% (variable depending on the gateway and number of users). Most OpenVPN based VPN services don't admit this, but its true. Most OpenVPN based VPN network providers don't even consider it fully, some don't know about it, or consider it an issue because they can't fully quantify it via correct testing, and only a few have ever tested it correctly or at all and to date the only OpenVPN based VPN service i've seen come out and admit it publicly is PIA (and now AirVPN - see paragraph 7 below) which is the honest thing to do for the good, faith, and trust of its customers. We do network compliance testing for various companies, some of which use various OpenVPN based VPN services so we also have to test those as well (within our scope of the target network testing) to ensure networking compliance. PIA (since it was mentioned) is a quality VPN service (not defending them, just telling it like it is from my professional experience) but this is not to say that AirVPN or some of the other VPN services are not quality VPN services as well, there are many quality VPN services around that strive to give the best service they can.
2. Most systems connecting to OpenVPN based VPN services are not, lets called it, "tuned" for the use. There are many factors on the system end that may detrimentally affect the throughput one gets via an OpenVPN based VPN service such as processor speed and bandwidth, memory capacity - speed - bandwidth, bus speed and bandwidth, the network interface, etc... and, aside from the computer its self, also includes routers and networking configurations, and any hardware that touches or interacts with the connection, and software that interacts with the connection. The worse thing to use on VPN is a wireless connection at any point in a network (including home networks) or for the interface to the wireless ISP or any device that interacts with the VPN connection directly (e.g. wireless routers) as wireless inherently has greater amounts of frame issues and packet drops and loss and generally higher variable latency rates on VPN leading to lower throughput overall and the average user would never know it unless they could put actual measuring instrumentation on line so they want to blame the VPN service.
3. Most OpenVPN based VPN services supply a 'client' and software (e.g. tap adapter etc...) which is "designed" (intended) for the 'lowest common denominator' in a one-size-fits-all manner. This is a business decision that may work well for some systems and not so well for other systems, particularly if the client is 32 bit and the system and OS is 64 bit (yes, there is actually a performance hit which can affect connection throughput detrimentally using 32 bit VPN software on 64 bit systems contrary to what people think, but that's another post and another time discussion).
4. Changing from one OpenVPN based VPN to another really does nothing to throughput, they are all just about equal (it varies a little) in terms of loss through the VPN network. Throughput is only relative to the end point and never relative to the origination point (your system) (yeah, I know its a difficult concept to grasp for some but when you finally get it about 99.9999999999999% of the questions you ever had about 'connection speed' will be answered). Throughput changes with each connection to an end point (a web site, or for the folks torrent-ing the IP of the person/entity being used to get that torrent item, etc...). As bandwidth is consumed (filled, think of bandwidth as a pipe some smaller and some larger, bandwidth is not throughput and they are two different things) the closer one gets to the half power point and it is not a linear change. As one approaches the half power point (which is in the range of 35% to 50%, variable, of allotted bandwidth on a server or ISP, e.g. VPN gateway, no, you do not get all that gateway bandwidth claimed and its divided among all the users of that gateway and the division is never equal - and also includes that half power point of your system) the more your throughput begins to average out instead of maintain a peak throughput. So your throughput actually begins to decline the closer it gets to that point then it becomes more of how well your system handles the throughput and not the VPN service network. As you keep approaching that point and your throughput begins to decline sharply and settles at much lower levels that is less than 40% of your ISP allotted bandwidth its an indication that your system does not handle the connection very well due to other variables (read further below).
5. Throughput is only relative to the end point and never to the origination point (your system), so the throughput is going to be different for each end point (also sometimes for each packet to the same end point) but what you will see on your end will be the average of what the total path (internet, and including your system) allows. If for example you go to site XYZ.com and it has a big fat pipe of 10 Gbps that is not the throughput you will get or can use. What you will see is an average of what the path to that site (end point) will allow and the path may have many other servers your connection passes through to get there and if those servers, or even one of those servers, has less bandwidth available then you will reach the bandwidth half power point more quickly (see # 5 above) and thus see lower throughput than you might have expected. Once you lose throughput to an end point you do not magically get it back because you are using a VPN gateway server with a big fat pipe, its gone. It amazes me sometimes that people who discuss this subject do not seem to understand this correlation and their first thought or post is something (or similar) along the lines of "My ISP 'connection speed' is <insert internet speed test site result here> and the gateway is <some big pipe bandwidth Mbps here> but when I connect to site XYZ.com (or torrent, etc...) I only have <some lesser amount of 'connection speed' here> so the VPN is not working and is giving me lower speed' ", well duh .... the answer is throughput is only relative to the end point only and its not the VPN in the complaint.
6. Internet speed test sites do not really test throughput, what they are really testing (or trying to test, and not really doing a good job at it) is bandwidth and using the assumption that the faster one fills the pipe (the bandwidth) the faster the connection is - sounds logical, and there is even math to back it up, only one little issue and that is this is not really true as there is actually no direct correlation between bandwidth and throughput. Instead, after all the various "tests they run" (ping, jitter, upload. download, etc...) they only end up estimating what they think your 'connection speed' should be based upon that assumption and the math developed for it. Sure, you need bandwidth to have throughput but having lots of bandwidth does not mean lots of throughput. The only way for the individual user, aside from having a controlled test with actual instruments, to measure throughput on a system connection is at the system its self by timing hard file downloads/uploads (actually down loads are all that's needed 99% of the time). An internet speed test site wants to send 'data' to your browser to 'simulate' a 'hard file' send/receive (via what ever method they base their test on, e.g. flash, java, html5 etc...) and its the timing (response) of the browser being used which is different from system timing with actual hard files. So your throughput is always going to be different than what the internet speed test site shows, it could actually be higher or lower than what the internet speed test site tells you by a lot more. So internet test sites should not be believed or relied on to begin with as any type of quantification for throughput. Plus there is the thing that, if the VPN service is worth a damn,on VPN your system is not actually an end point for the internet speed test site test and bandwidth measurement (what the speed test sites are wrongly calling 'connection speed') requires the system be an end point in the test the same as throughput tests require the system to be the end point for the test which they are not on VPN for an internet speed test site even if it could actually test throughput. However, you don't want to know how much bandwidth you have, you want to know your throughput. When we test networks for compliance sometimes we run into a "internet speed test jockey' network admin we have a conversation with and it goes something like this; admin: "<what ever the issue is for the network not meeting compliance> ...that's because the connection speed is lower than it should be right now and I think something in the network is acting up." - us: "lets see your test data and we will take a look so we can compensate and take that into account" - admin: "oh, just go to <name of internet speed test site here> and take a look" - at this point we suppress our laughter and move on.
7. It does not help the situation that ISP's and the internet speed test sites tell you that what you are getting is 'connection speed', it causes a lot of confusion. For example, your ISP connection to begin with does not get what your ISP said was 'connection speed', what ISP's actually sell you is bandwidth (which is also rated in the same units as throughput, e.g. Gbps or Mbps) and not 'connection speed' but they are pretty good with the sales pitch of 'connection speed' and have duped generations now into thinking they get 'connection speed' of, for example, "300 Mbps" and the speed test sites will show something similar because they are actually measuring bandwidth and bandwidth is what you actually pay for from your ISP so things seem to match up because both the ISP and the internet speed test sites say their services are giving you 'connection speed' when it never was to begin with. Then people want to compare this on VPN with (or similar) "My ISP connection speed is <insert speed here> but on VPN I only get <insert 'connection speed' here> of that according to <insert internet speed test site here>" and sometimes they include a "your service sucks!" or similar sentiment; These make me laugh sometimes because they were never really comparing 'connection speed' to begin with and they don't know it but they are all serious about it because an internet speed test site said so and the speed test site was lying to them to begin with - this is (partially) the reason quality, honest, reliable, VPN services don't seem to 'improve connection speed' for their users after numerous complaints, because they do actual quantifiable testing and that testing shows a different picture that they are properly compliant with their metrics, design, and operation criteria, in other words they know the issue is not with them. It also confuses people when they see gateway (or other) servers rated in the same units as connection throughput (e.g Gbps, Mbps); The server rating is not throughput for the user, its bandwidth, so a server rated at, for example, 1000 Mbps is not going to provide 1000 Mbps throughput but rather has 1000 Mbps bandwidth meaning the "pipe" size and not the throughput. People often look at this and say, for example, "the gateway has a speed of 1000 Mbps" which is not correct. Consider that some VPN's limit the throughput per connection due to physical limitations, other design, or business, or financial considerations, of their VPN networks, for example, where its stated that (paraphrased) "...In general, our infrastructure and above all our prices/business plans are designed to reliably provide 40-160 Mbit/s per client (i.e. 20-80 on the client side) ...and 16 Mbit/s (server side).... worst case .... (i.e. if everybody connects at the same time AND requires maximum bandwidth constantly) .... however, you can easily reach (as you have experienced) 300-400 Mbit/s (which translates into 150-200 Mbit/s on the client side)... with some care to pick a properly "not heavily loaded" server." (note: 300 Mbit/s is 37.5 MB/s - Megabits per second - 150 Mbit/s is 18.75 MB/s) by a member of the AirVPN staff at https://airvpn.org/topic/22340-top-transfer-speed/#entry59918. As can be seen indicated in the link there is 50% difference less in throughput for the client, which is just about (it varies some - see paragraph 1 above) what all OpenVPN based VPN services provide in reality thus its another of those things that makes quality VPN services about the same at their basics. Such design considerations/limits are basically necessary to ensure service to all users but there is also the business financial consideration as well. The complaint of slower throughput on VPN is not a new one, its common to all OpenVPN based VPN networks no matter who the provider is. Its nice, and decently honest, that a VPN service publicly tells of such a throughput limitation instead of running people around in circles making them jump through hoops with doing this or that, its one of those things which are part of that 'quality' factor for a VPN and another thing which makes quality VPN services the same at their basics.
8. When a person says "I changed from ABC VPN to XYZ VPN and got better speeds with speed test site <insert speed test site name here>", well, nope they didn't actually. What they got was gateway servers that are in different locations in relation to the internet and the servers the speed test site uses so those paths changed a little (because the test server was closer to the internet facing gateway exit point) and lessened the path latency to the speed test site server path thus the throughput seemed to have improved, in reality their throughput is still basically the same overall but they will argue and swear on their mothers grave they get better throughput according to the speed test site. Latency and throughput are inverse to each other (latency goes up and throughput goes down), the path to the end point is fixed at the time of a packet traversing the path and reaching the end point and not at the time the connection is established, the variation in the latency between the packets arriving at the end point is called Packet Delay Variation (PDV) which is commonly known as 'Jitter'. Your system is also part of the path, people never think about that, and so is its latency. Your system path latency is more of a constant, e.g. its only going to process data sent and received at a certain rate depending on the conditions imposed on it with the connection parameters (encryption, compression, etc...), the difference between the ideal and what happens in the system data processing introduces latency at the connection as well which is seen in your overall path latency (e.g. you do a ping to a site, part of that result is actually also your system latency which is something people never think about). Then there is the matter of, primarily, packet loss and drops and frame issues at the system which is something people never considered and 99.9% of users never know about, on VPN these increase in the system and depending on how well your system handles this it can also affect your throughput but people will go out to a speed test site and want to blame the VPN service because their throughput dropped on VPN.
9. Then to top all this off, no OpenVPN based VPN service or system is perfect. Sometimes they may just be having, to use a term, "a bad day" (or month, or year). There may be an abnormal amount of users on your favorite gateways, or there may be some maintenance going on, or the data center where the gateway server is located might be having an issue, or even your ISP is having an issue, or your own system is having an issue at the time with processes consuming resources. The point here is that conditions are always variable and should always be considered. However, while speaking of ISP's having "a bad day" affecting your connection - Yes, your VPN connection does pass through and use your ISP connection and ISP's are notorious for 'adjusting' connection bandwidth by 'borrowing' some from others to serve their capacity requirements. For example, one ISP we use (we use three) has a business class service we use and when that class needs bandwidth they "borrow" from the residential service. Another notorious thing about ISP's is most (actually all, it varies at times, sometimes its all the time) do not recognize heavily encrypted traffic (like VPN's) very well so the VPN connection gets a lower priority in the ISP network than non-encrypted traffic so its gets shunted off through servers in the ISP network that have variable non-stable bandwidth (or lower bandwidth) and higher latency before its launched into the internet void from the ISP network which in turn makes a persons connection throughput on VPN lower on average plus these are generally transparent and not seen on testing like routing or tracert or ping tests unless special testing procedures are used so you never know about them, so one can not really test throughput off VPN and compare that to the throughput they get on VPN because the connection is going to be taking a different route through the ISP network on VPN than it does off VPN.
10. Oh, and did I mention the 'upteenhundreds' of other variables completely out of the user or the VPN service control that affect throughput? OK, I will not do so at this time, its a lot, so maybe another post with some at a later time
So, make of this what you will but the long and short of it is for any OpenVPN based VPN service you will get what you get for throughput and that's it and its overall really no different at the basic level between the various quality OpenVPN based VPN services and you really can't compare one to the other in this aspect, sure, there are some of them that are not so quality focused and are crap and poorly designed, established, and run so in some cases you can blame the VPN service. Its not easy establishing and running a quality OpenVPN based VPN service that pleases everyone all the time, and its the same if its AirVPN or PIA or any other quality OpenVPN based VPN service, they vary some in "features" and client and software used but they are all basically the same.
(note: before anyone posts "oh, I use my torrent client to test my 'connection speed' " - no, one can not measure throughput with a torrent client. Additionally, one can not actually measure throughput with an internet speed test site browser environment either, so the thing about "comparison" in terms of throughput is really useless for quantification when these are used. I tried to be brief yet explanatory, yep I know its confusing for some, sorry 'bout that.)