Server location ?

[gunni]

Thanks CarlWhat,
I will check it.
Right now I am facing problems due to this HttpS issue.
I have changed in both configuration files the #17 line and #18 lines as Rod suggested.
For some reason this caused my website flowersoaps to have problems with the database. Do not know why
as I changed only the http ->httpS
Anyway, I restored the previous configuration.php files before the change but for some reason this did not solve
the problem. I did not know what to do so I turned to my hosting company. They made a restore and the site flowersoaps
was back to normal.
But the story does not stop here...
In the same library of the server there is another site....greenpillow (dot) co (dot) il.
Although I asked the hoster specifically not to restore that directory I found out today that some files were changed.
Few hours ago I suddendly realized that the checkout_shipping page is blanc !!!
So...what does it mean ? the restore is not good ? they managed to make a good restore for the flowersoaps site...
How to solve it?
I turned to them but I need to wait for the more proffessional staff.
What should I do ?
I allready lost a sale
Sorry for the mispelling mistakes...

[DrByte]

Few hours ago I suddendly realized that the checkout_shipping page is blanc !!!

http://www.zen-cart.com/content.php?124-blank-page

[gunni]

Thanks Dr.
Succeded to find a mistake on one page but have another on the next.
Continuing to check...

[RodG]

http://www.flowersoaps.co.il/

and while i ran 0 on-line tests, currently i would say the speed is quite good.

Don't forget that this site is not only CDN enabled, it is also USA Based.

personally, i have had bad experience with cloudfare,

Can you please elaborate on this. We've now been using them for 3+ years- Never had a problem (we have now almost 120 different sites using them in one capacity or another) .

You are probably the 3rd person to have made this claim is as many years - No one seems willing to provide details

Now having said that, I'm *sure* that there would be many instances like Gunni's - where something *unrelated* to Cloudflare itself has been a problem, and if you happen to be running TOR exit note there is much heartache.

I'm not trying to place you on a spot here, but I'd really like to know what your 'bad experience' was because although *I've* had no problems so far, that doesn't mean that at some time in the future I won't - and if your bad experience is something I can mitigate against in advance of the problem happening, then so much the better.

and i gave up on it. but that is only 1 datapoint, and for me i bailed on it. and while i am a fan of CDNs, my experience is limited....

Exactly what do you mean by '1 datapoint' ? - Sorry if I appear a little dumb here - but in the context of a CDN, a 'datapoint' could relate to a .css file, a particular type of image, perhaps a javascript file?
There can be several 'gotcha''s with these filetypes and various CF options and settings, especially with the 'Auto minify', 'Railgun' and 'Rocket loader' features.

and now onto some dangerous waters :)

Possibly more dangerous than you anticipated.

rod, you are a wealth of information, and i enjoy your posts.

Training 101. Start with a compliment. <g>

however, in my experience, i have yet to encounter a reputable web host where they are hosting name servers on the same servers as hosting websites.

I shall refrain from making comment on your experience (or lack of). I shall say that *most* folk would have very little experience in this regard, simply because most folk would probably have never performed a DNS lookup for the IP addresses of the nameservers being used by any given hosting provider.

in addition, i have yet to encounter two name servers hosted on the same server (which i believe you mentioned previously in this thread; apologies if wrong on that...)

Yes, I did say that, but unlike the *very common* practice of hosting webservers and nameservers on the same host, these are actually a lot harder (if not impossible) to identify, on account of the fact that any given host can have many different IP addresses - Hhhm well, they *all* have at least 3 - There'll be the 'localhost' (127.0.0.1), there will be the LAN ip (private, internal routing 10.0.0.0/8, 172.16.0.0/20 or 192.168.0.0/16), plus *at least one* public IP address. There can be many more public IP address, and many more LAN ip addresses, for any given host/server.

with all due respect,

Training 101 - The critique :)

I have chosen to *not* take offence at this ("all due respect" often means "I think you are a dickhead, but......"

i would like to see some data to back up the assertion that DNS and websites are often on the same server, before i would accept that as somewhat true....

Too easy. Too common. Here's just 3 that I didn't even need to think about.

(liquid web)
potenthosting.com A 209.59.145.14
potenthosting.com NS ns1.potenthosting.com
potenthosting.com NS ns2.potenthosting.com
ns1.potenthosting.com A 209.59.145.14


(hostmantis)
odlweb.com A 144.76.109.46
odlweb.com NS ncsecns.fastcpanelserver.com
odlweb.com NS dens20.fastcpanelserver.com
dens20.fastcpanelserver.com A 144.76.109.46


(A2hosting)
vcsweb.com A 70.32.170.45
vcsweb.com NS a2ns1.a2hosting.com
vcsweb.com NS a2ns2.a2hosting.com
a2ns1.a2hosting.com A 75.98.170.45



The 1st example - is going to be contested because the site is actually busted - and the person that owns it is going to make many claims such as 'it isn't used for hosting customers sites' . I shall preempt this by saying *unimportant* - The important thing is that the website *could* be functional, and it *could* be hosting other websites and that the primary nameserver is clearly on the same host as the webserver.
Alas, I won't see these objections, and if I did, it would be pointless for me to deflect any 'objections' made.

The second example is one that I've recently done some work on - There are ~100 different websites hosted on this Server/IP

The 3rd is one of our own - The details above are about 3 weeks out of date as this domain was added to Cloudfare about 2-3 weeks ago (it is the last of our domains to have been configured to use the Cloudflare nameservers.)

So, just 3 examples - but as I say, I really didn't need to 'look' for these - This type of configuration is *very common*. To find them it is a matter of picking a domain name, doing a DNS lookup for the IP site address and its delegated nameserver names, then doing another DNS lookup for the IP address of the nameservers - If the IP addresses match, then the website and the DNS are hosted on the same server.


Training 101. You are supposed to finish with another compliment <g>

Cheers
RodG

[RodG]

By the way, the CDN present of the SSL is not so good. Because it is "shared" SSL, there is no "sign" of "trust" next
to the url address like dedicated SSL so when customers click on the no signt, they can read that it is not safe for Credit

Sorry, Gunni, but you appear to be misreading the reason why the customers are seeing the "it is not safe for Credit Cards etc" - You have made an *assumption* that it it due to the Shared SSL, and carlwhat has already told you why you are really seeing this warning. It is due to the 'mixed content'

To quote carlwhat:

"with regards to SSL, i am not seeing that problem. you do not have the ZC configure set up to use SSL; but when i manually put it in, it looks fine (i'm using chrome). it is using the cloudfare SSL, certificate, but all warnings relate to image content being loaded over http as opposed to https."

To get rid of this 'warning' you need to get rid of the 'mixed content' - and the easiest way to do this is to configure ZenCart to use 'SSL everywhere'.
You may still need to manually fix any hard-coded http:// links - This isn't a 'cloudlfare' issue. You will have the exact same issue/problem even with a dedicated and verified SSL.

Now, having said that, If you don't like the shared SSL (typically only needed for vanity reasons these days) - No problem - Create a self signed certificate (using your hostname name) - Install it onto your server (not always an easy task - often need your hosting company to do it for you. Probably needs a dedicated IP) - and then set the Cloudflare SSL setting to 'Full' - Alternatively, rather than create a self signed certificate you can also create/use cloudflares 'Origin certificate' with 'strict' SSL (uses your hostnames).

See here for more info: https://www.cloudflare.com/a/crypto/

We have sites using both methods (Full & Strict) - but most of our sites are using the 'Flexible SSL' because it doesn't require anything to be uploaded and configured on the server itself (The default is 'Flexible).

In all cases, your customers will never know which is being used, and if they *do* click on the 'padlock' icon (which no one does unless it shows an error) the 1st screen they see is the 'website security' which will clearly show that the 'website' is 'correct' for the certificate, and that the connection is 'secure'. It is only if/when they click the 'View Certificate' that they will see the SNI cloudllare "Common name" - and frankly, this won't mean anymore to most folk than the "Issued by Comodo" entry.

Putting it bluntly - Most folk don't have a freaking clue about SSL or how to read a Certificate - All that matters is that they see a 'green padlock' - and once you get rid of that 'mixed content' that is exactly what they will see when they visit your SSL enabled site.

To sum up many of my previous discussions about SSL - It doesn't really provide *security* (these days) - It provides *encryption* only. - or as I so often state- A "false sense of security". - but apparently, that is all that really matters.

Cheers
RodG

[RodG]

Right now I am facing problems due to this HttpS issue.
I have changed in both configuration files the #17 line and #18 lines as Rod suggested.
For some reason this caused my website flowersoaps to have problems with the database. Do not know why
as I changed only the http ->httpS

I really must stress - if that is all you did, then you wouldn't be having this problem. *something else* got changed or obliterated at the same time.

HTTP/HTTPS will *not* cause a DB problem.

Cloudlfare caching will NOT cause a DB problem either.

Cheers
RodG

[carlwhat]

rod,
i will attempt to reply to things that i think relevant. unfortunately, i do not think this is the place nor the forum to address a number of your issues. i am on this forum to give back to some ZC people that are looking for help on their sites. unlike many people here (and i do not mean to include or not include you here), i rarely question their reasoning for attempting to do what they want to do. if i think i can help, i try to help... without judgement.... perhaps not always successful... but i try...

without even doing any tests, it is, IMHO, logical to host a website close to its customers. period. if there are 2 comparable hosts (a difficult assertion i admit), proximity to customers should be considered.

as i previously stated, i am not opposed to CDN, and when properly implemented i think they are, no doubt, a benefit.

with regards to cloudfare, i had problems with their DNS, and not getting timely lookups from the cloudfare DNS servers. the hosting company included cloudfare as part of the package and i could not get it to work to the point that i gave up. and this was on a simple non-ZC site. so i opted to not even give it a whirl on the ZC sites that i support.

the cloudfare support was not at all timely so i gave up. i am not sure if it was because it was included in the hosting as opposed to paying cloudfare directly.... whether i gave up and it was me (probably), i only have a limited amount of time in the day... and i found my site down due to DNS far more frequently than it should be.... so it was probably my setup, but i could not get any support.... so again, i gave up.

when i say it is 1 datapoint, i am referring to my experience with cloudfare. you say i am the 3rd person to have a negative experience on cloudfare. that is 3 data points; hardly a statistically significant sample size to say cloudfare is bad; similar to you saying cloudfare is good. it's just 1 datapoint. that is what i meant....

and with regards to datapoints on hosting companies, you have provided 3. in my mind, this is hardly a statistically significant sample size to make gross accusations about hosting companies (of which i am not a huge fan...)

liquidweb and hostmantis seem to be a problem. the name servers (ns1. and ns2.) resolve to different IP addresses. but they are on the same subnet, which is not considered good practice in setting up name servers. whether their websever is on the same physical host is up to debate (port forwarding no doubt could come into play); but i do concede that the webservers liquidweb.com and hostmantis.com do resolve to the same ip address as ns1.

a2hosting has both of their name servers on different subnets as well as the web hosting on a separate subnet. so i would suggest that this example disproves your assumption.

i provide digitalocean.com, linode.com and dreamhost.com where their two name servers and the hosting companies website resolve to different IP addresses on different subnets. so that is 3 new datapoints on this discussion. (i and not recommending or disparaging any of these hosts, and i merely provide them as datapoints contrary to your assertion...)

and until i see a study that examines a statistically significant sample size of hosts, i would suggest to people that your assertions are merely your experience and can not be extrapolated to all the hosts on the web.

finally rod, allow me to quote you:

I have chosen to *not* take offence at this ("all due respect" often means "I think you are a dickhead, but......"

all due respect, to me, does NOT mean what you suggest. psychology 101 suggests that is what you think it means.... i never called you such, and your assertion is more of a reflection on you...

frankly, i listen to what you write; but i can not say i always agree with it. perhaps it was months ago, you stated that getting a VPS may not increase your web server performance over being on shared server. and while i listened, i can not say my current experience mirrors that assertion. but again, it is only 1 datapoint. perhaps i had a bad shared hosting company and a good VPS company...

and please excuse me if i choose to not respond to further inquiries on this post. my opinion with regards to the OP was clearly stated that, all other things being equal, i think a server should be located close to its customers.

best.

[RodG]

Gunni, carlwhat, and anyone else interested.

The SSL 'mixed content' issue/warnings.

It turns out that CF actually has a solution for this - I've never had reason to try it until short while ago, but it seems to work well.

Although the correct/ideal solution is to change any/all http:// links to SSL, there is a settng n CF called ' Automatic HTTPS Rewrites
It defaults to 'off' - but when enabled it does exactly what it says - If it finds an 'http://' link in the site it is serving - it will automatically re-write them to use 'https'.

No more mixed content warnings - No website updates needed. Problem solved.

Magic!

Cheers
RodG

[gunni]

Thanks Rod,
Now you're telling me no website update needed... ??? After such a trouble I had until one hour ago...
and after lost one sale
But that's not your fault (and I think not mine). Don't know what happened...
Suddenly found problems in PHP files which were OK before...
and that is after the hosting company made a restore...
OK now...

By the way Rod, if enable at Couldflare the option of minify CSS, Java etc' - will it be OK or can make me a problem again ?
One of the problem I faced now was that there two many blanc lines on the end of a PHP file. Strange...
So I want to be sure minify will not make me problems...

[RodG]

it is, IMHO, logical to host a website close to its customers. period.

It is logical only if you equate distance with speed, and assume that all links are the same speed.

For example:

A fast USA based server can easily give faster page loads than a slow Aust based server. The server itself being the limiting factor.

Another example:
Two servers - same speed - one located in Perth/Australia, the other located in Califonia/USA.

A customer located in Sydney/Australia could/will get a faster load time from the Californian server than the Perth server - even though it is further away and in a different country - There is a high speed link directly from Sydney to California that will actually out perform the slower links from Sydney, thorugh Melboune, up to Adelades, and finally across to Perth.

if there are 2 comparable hosts (a difficult assertion i admit), proximity to customers should be considered.

Only if you assume that all paths are of an equal speed, and ignoring the 'losses' incurred if the packets have to traverse multiple (or additional) routers rather than a 'single hop' direct link.

as i previously stated, i am not opposed to CDN, and when properly implemented i think they are, no doubt, a benefit.

Not really happy with the 'properly implemented' comment - I think 'not fully utilised' would be a more apt phrase to use.

At its core, the CDN is little more than a globally distributed cache, where the contents of the cache is served from the server closest to the user, so bringing your closer is better back into the discussion - The sites we have hosted in USA have *most* of their content being served from a server located in Melbourne - IOW, we *effectively* now have an Australian based server. On this same token we now effectively have servers based in UK, Germany, several states of the USA, plus who know where.

with regards to cloudfare, i had problems with their DNS, and not getting timely lookups from the cloudfare DNS servers. the hosting company included cloudfare as part of the package and i could not get it to work to the point that i gave up.

Well, there's a large part/all of your problem right there - You may have noted that I have on several occasions stated that Cloudlfare isn't something that needs to be 'supported' by the webhost. I've not gone into any detail about the hosts that offer 'cloudlflare' via their cPanels (as many do these days), and I would not in a zillion years recommend this option to anyone.
Why you may ask? Glad you did.
By implementing CF via the cPanel you are *not* getting the DNS gains provided by their distributed/anycast nameservers - You do get the web caching benefits - but you are also 'crippling' the DNS lookups - The reason for this is that the domains remain delegated to the hosting providers name servers - So when hostname DNS lookups are performed, first the TLD servers are queried for the domain name NS records, then the host query is made is made to the defined server (the webhost), which then returns the IP address for the CF caching server.

In contrast, when a site is delegated to the CF servers, the same lookup will again query the TLD servers, which will return the *cloudlflare* nameservers for the host query,

Hopefully you can see the difference here?

Putting this another way - The DNS issues that you had attributed to the CF servers were actually a problem with your hosts Servers - Cloudflare had pretty much nothing to do with the problem.

I say 'pretty much' because cloudflare uses a very short TTL for the hostname 'A' records (just a few minutes rather than several hours) and this in turn causes a lot more lookups due to the records expiring, and this in turn increases the load on the nameservers, and if the host provided nameservers aren't up to the task (and many aren't) then the problem you experienced are pretty much par for the course. Unfortunately.

We have found that across the board, the CF namerservers have been *significantly* faster than any of the nameservers provided by the webhosts host we've used so far.

I'm sure I've said this before, but it is the DNS gains that are/were the driving force for us to use CF for all of the domains we host - even though many of the domains aren't using the web caching aspect.

and this was on a simple non-ZC site.

Sorry, by I don't see any relevance of this whatsoever. Nameservers (CF or host provided) have no idea or concept as to what is actually being hosted on the site - There may not even be a website - It could be mail only, or there could be hundreds of sites hosted on the same server - it really isn't going to make any difference to the DNS.

so i opted to not even give it a whirl on the ZC sites that i support.

I wouldn't either - if the caching gains are going to be negated by the host provided DNS servers.

This is why it has taken us almost 3 years since 1st 'testing the water' to the time we decided to use the CF DNS for all of our domains (and those we host). (slowly adding various domains over the years, as needed)

With a little over 100 clients - Not a single one has reported any problems or issues - We have however had *many* make comment that their sites have been noticeably faster and asking if we'd moved them to a different host, again (as we tend to do when the servers get overloaded or the support turns to crap).

the cloudfare support was not at all timely

Agreed - 2 - 3 days - not good. However, the only time(s) I've needed their support were back when I didn't understand how it all worked, or needed to either combine (or separate) accounts (for various reason). Hardly a day to day occurrence.
Nonetheless - the support *is* very poor (although they do seem to eventually answer all queries and questions). They prioritise their paying customers 1st. Quite understandable.

so i gave up. i am not sure if it was because it was included in the hosting as opposed to paying cloudfare directly....

For the cPanel implementation, the support queries should be to ISP (we were told this by the folk at cloudflare).
For the cloudlare 'direct' (my terminology) implementation then cloudlare can and do provide the support. For *prompt* cloudlare support then a paid plan is required.

whether i gave up and it was me (probably), i only have a limited amount of time in the day... and i found my site down due to DNS far more frequently than it should be.... so it was probably my setup, but i could not get any support.... so again, i gave up.

I can only repeat/stress, that with the cPanel implementation any DNS issues you had were/are a problem with your hosting provider. You aren't even using the CF nameservers with this set up - Which is also the reason they direct most support queries back to the hosting provider - They (cloudflare) aren't in any position to solve DNS issues with the configuration you had.

Yes, I know you can/will say that you never had DNS issue before, or since you tried this - but as I suggested, that is because your hosts name servers could be severely stressed due to the extra demand from the very short TTL's.

when i say it is 1 datapoint, i am referring to my experience with cloudfare.

Which, being a DNS issue, not related to the cloudflare DNS servers, has clearly left you with a sour taste. I can appreciate that.

you say i am the 3rd person to have a negative experience on cloudfare. that is 3 data points; hardly a statistically significant sample size to say cloudfare is bad; similar to you saying cloudfare is good. it's just 1 datapoint. that is what i meant....

It is also highly probable that the other two had made the same 'mistake' you had, and with the same issues? Can't rule it out.

So, how many 'datapoints' do you want? As I say, we now have a little over 100 domains delegated to cloudlflare. The websites themselves spread across four different reseller accounts (Hostmantis, A2hosting, Dotster and TPPwholesale).
We have had zero complaints from any of these clients/customers. Surely that says something doesn't it?

At this stage, I will again repeat, that I have no association with CloudFlare other than being impressed at the benefits it has given us and our clients. Why would I be spending all this time encouraging folk such as yourself from using realising these same benefits? Well, I suppose I could be encouraging you all to implement a buggy/troublesome system and causing DNS issues so that you lose customers with the hope they come to us, but if that were the case, why would *we* be using the same troublesome system.

Like/Believe it or not - I am actually trying to *help* people here - I'm really getting nothing else out of this.

and with regards to datapoints on hosting companies, you have provided 3. in my mind, this is hardly a statistically significant sample size to make gross accusations about hosting companies (of which i am not a huge fan...)

You doubted that I could provide just one example of where the DNS and webserver were hosted on the same server. I provided three off the top of my head.

liquidweb and hostmantis seem to be a problem. the name servers (ns1. and ns2.) resolve to different IP addresses. but they are on the same subnet, which is not considered good practice in setting up name servers.

You really don't want to get me started on this tangent - There was a time that this wasn't even *allowed* - The fact that it is allowed makes me cringe. Yet it is so common these days it is considered to be 'standard practice' <grrrrrr>

whether their websever is on the same physical host is up to debate (port forwarding no doubt could come into play); but i do concede that the webservers liquidweb.com and hostmantis.com do resolve to the same ip address as ns1.

You do raise a valid point about the port forwarding - in fact we do this ourselves - I run a nameserver for a couple of domains on my own computer, and out of necessity I need to port forward from out public IP address to one of our LAN servers), so I can't discount this possibility. What I *can't* discount is that over the years, with many sites using the single host configuration is that whenever the webserver has had hardware failure the NS hosted on the same IP address has also failed. Sure, it *could* be a coincidence, but each and every time?

[QUOTE=carlwhat;1325845]
i provide digitalocean.com, linode.com and dreamhost.com where their two name servers and the hosting companies website resolve to different IP addresses on different subnets. so that is 3 new datapoints on this discussion. (i and not recommending or disparaging any of these hosts, and i merely provide them as datapoints contrary to your assertion...)


I'm not really sure the point you are trying to make here. I never claimed that *all* hosts have this abortion of a configuration. You doubted that I could provide even one example. I did that by providing three. What more do you want? I'm really not seeing what you are trying to get at, other than you have given 3 that aren't.

and until i see a study that examines a statistically significant sample size of hosts, i would suggest to people that your assertions are merely your experience and can not be extrapolated to all the hosts on the web.

I never said that. I never implied it. I stated it was pretty common practice. You doubted the claim and asked for an example.

finally rod, allow me to quote you:

all due respect, to me, does NOT mean what you suggest. psychology 101 suggests that is what you think it means.... i never called you such, and your assertion is more of a reflection on you...

Just me huh?
http://www.urbandictionary.com/defin...0due%20respect

frankly, i listen to what you write; but i can not say i always agree with it. perhaps it was months ago, you stated that getting a VPS may not increase your web server performance over being on shared server. and while i listened, i can not say my current experience mirrors that assertion.

Yup. I would have said that, and I am happy to repeat it, over and over again - simply because it is fact.

I'll give an example:

Site on shared hosting starts to get too busy for a shared server - hosting provider suggests a VPS. Site owner, not knowing any better, gets the cheapest VPS they can find. 1mb RAM.

Now you and I both know that this isn't enough for a zencart site - but the typical site owner doesn't know that - They now have a VPS that barely functions - but it is still a VPS - . Ergo, I can positively and definitely state for a fact, that this VPS for this customer is is going to give worse performance than the shared host they were on.
I'll even go as far to say they could probably find another shared host where they won't be exceeding the allowed resources.

I'm not, and will never will state that *all* VPS's will decrease performance over a given shared server as that would be absurd.

What I am saying is that *many* folk* have gone this route - not being any the wiser. No one seems to tell them any different - until its too late - then they get the 'upsell' to a VPS with more RAM and more cores. In many cases their best and cheapest option is to simply find a different shared host.

If you've taken this *any other way* then you've totally missed the point.

but again, it is only 1 datapoint. perhaps i had a bad shared hosting company and a good VPS company...

Or perhaps because you know that a VPS with (say) 4Gb RAM is still no match for a shared server with 64Gb ram (albiet, not all avialble to all clients at all times)

and please excuse me if i choose to not respond to further inquiries on this post. my opinion with regards to the OP was clearly stated that, all other things being equal, i think a server should be located close to its customers.

That is still a broad statement that holds true only if you ignore the fact that the servers have a major affect (a fast o/seas server can easily outperform a slow local server, and ignoring the fact that not all links have the same speed (up to 1000x difference in some hops), and ignoring the fact that a CDN 'brings the server to the customer' , or the fact that if the merchant sells over seas as well as locally, it is impractical to deploy thier own server in every country they wish to sell, or the fact that in some countries (ie: Australia) we need to pay ~4 times the cost for an Aust based server than for a similar specced o/seas server - with no observable benefits (to the customers), so yes, if you ignore all of these facts, then having a local based server is indeed the thing to do.

Anyway, I too am out of this discussion (other than queries from Gunni).

As I say - I've found CF to provide nothing but positive gains. Am I wrong in wanting to share this with others? (apparently yes, else I wouldn't be fending of arguments against.

You had a bad experience when you used the cPanel implementation of cloudflare (you didn't know any better - neither did we when we first went this route), but I don't see how *our* mistake in this regard should become a hindrance to others. I've seen nothing but positive benefits when I took the *right* approach. I fear that you are probably in the 'once bitten, twice shy' category. Quite understandable. Alas, I fear that no matter what, there is no way I will ever convince you to even try it the right way *use the cloudflare nameservers* I feel that this is your loss

My final word, is a screenshot - Analytics from a single host.

https://www.dropbox.com/s/n06h1roili...screenshot.png

Now multiply this by the 100+ hosts.

Cheers
RodG