|
Thanks so much for running the test. WinHost is consistently (from around the world) 2 - 10X slower.
Gary S 2021 wrote: I suggest checking out Interserver.
That's so funny, because I just (before reading your messsage) signed up for 1 month & I uploaded speedTest files & tesed & it was less than 1 second to load.
|
|
|
|
|
1.1s (winhost) vs 14.7s (sMaRtErAsP.nEt). From: PA, USA.
raddevus wrote: SmarterASP one is not doing HTTPS
This shouldn't matter unless they're using decade+ old servers; anything newer has hardware acceleration in the CPU and should see something like a 1% performance impact from HTTPS.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Run from Rockford, Illinois
Winhost: 13.496
SmarterASP: 6.489
Sincerely,
-Mark
mamiller@mhemail.org
|
|
|
|
|
Thanks for running the test & posting. WinHost does seem to be consistently 2x - 10x slower.
|
|
|
|
|
The SmarterASP loads much much faster. I am located on Borneo Island.
|
|
|
|
|
Thanks for running the test & posting. Yep, smarterasp is consistently faster. thanks
|
|
|
|
|
I didn't time it exactly but, it took WinHost quite a long time. I could see the image being rendered block-by-block. At least 6-7 seconds. The SmarterASP site was less than a second, hardly noticeable. I'm in South Carolina, USA.
|
|
|
|
|
1. There are a few page-speed-test tools out there, that will hit your page from dozens of locations on planet earth.. measuring ttfb and full load time, etc.
https://www.dotcom-tools.com/website-speed-test[^]
2. Things like HTTPS and HTTP/2 matter, hugely.
3. If you care about speed, reliability and security (incl. ddos-protection) you should really serve everything from a CDN edge-cache like Cloudflare or AWS CloudFront.
Even if your content isn't cacheable.. just using a CF endpoint as a "proxy" will have huge benefits for short-circuiting roundtrips from browser-to-server. (Just establishing a single HTTPS connection requires several sequential TCP roundtrips.)
|
|
|
|
|
I tried this twice
First Test
WinHost 7.873
SmarterASP 7.703
Second Test
WinHost 9.013
SmarterASP 7.717
I am in Northern Arizona and Frontier connection is either in Phoenix or Palo Alto
So does location and ISP provider affect the numbers?
|
|
|
|
|
Thanks for trying it out. And, I do believe that it does matter where you are physically located in relation to where my web server is located. It's a very odd thing actually & I've learned a bit about it but it is still quite confusing.
Most people saw WinHost 2x - 10x slower. But I did notice that if you are "closer" to the WinHost one it could resolve just as fast.
|
|
|
|
|
Overall, I'd say there's a huge difference (running from Redmond, WA - see below).
- 1st attempt (Edge):
- HTTP Error 503.0 - Service Unavailable
- 2nd attempt:
- 7.976 seconds elapsed during load.
- 3rd attempt (refresh):
- 0 seconds elapsed during load.
- 4th attempt (Chrome):
- 2.833 seconds elapsed during load.
- 1st attempt (Edge):
- 0.972 seconds elapsed during load.
- 2nd attempt (refresh):
- 0.001 seconds elapsed during load.
- 3rd attempt (Chrome):
- 0.982 seconds elapsed during load.
Comments
Differences could be network performance, disk performance, or caching. Edge versus Chrome variation might be at related to caching connection information or caching at the web host (where the first connection, Edge established the connection information and caused the host cache to load, then Chrome used it).
A CDN would help with both performance and DDOS attacks for static content. Larger, more established providers, often have built in DDOS defenses and CDNs, but optimizing costs may require a little more creativity.
|
|
|
|
|
raddevus wrote: Would you mind trying it and letting me know what you get for each site?
1) WinHost Site: Test Load Speed[^]
2) SmarterASP.net site: Test Load Speed[^]
Well, I didn't get such bad results.
The first, via newlibre.com
Testing Load Speed
beginTime: Tue Apr 05 2022 15:33:57 GMT-0700 (Pacific Daylight Time)
endTime: Tue Apr 05 2022 15:34:01 GMT-0700 (Pacific Daylight Time)
3.721 seconds elapsed during load. The second, via cyapass.com
Testing Load Speed
beginTime: Tue Apr 05 2022 15:33:50 GMT-0700 (Pacific Daylight Time)
endTime: Tue Apr 05 2022 15:33:52 GMT-0700 (Pacific Daylight Time)
2.036 seconds elapsed during load.
|
|
|
|
|
Actually, I have now switched (and the DNS seems to have propagated through) to amazingly fast InterServer.net web host. I believe your test (newlibre.com) probably hit the new site ip address 162.246.23.194.
Thanks very much for trying it out.
|
|
|
|
|
1st load.
WinHost: 2.556 seconds elapsed during load.
SmarterASP: 2.812 seconds elapsed during load.
2nd load:
WinHost: 0.122 seconds elapsed during load.
SmarterASP: 0.173 seconds elapsed during load.
Near Toronto, EST.
- The index and js pages appear to be different sizes on each site (larger on the second), and the favicon was not found on the first site.
- Firefox gave me a warning about loading the newlibre site.
- Be sure to optimize your images if actually using any.
|
|
|
|
|
Thanks so much for testing. At this point I have now moved the newlibre.com site to YAH (Yet Another Host - interserver.net) and it is orders of magnitude faster.
|
|
|
|
|
I got (in order):
Under 2 seconds
About 2 seconds...
|
|
|
|
|
Yep, thanks for testing. I've now moved to InterServer.net as the main web host & it is blazing fast.
Most likely when you hit the https://newlibre.com/speedTest you hit the new one. Thanks again.
|
|
|
|
|
I just had to login to a website and my password expired (password expiry is bad practice, according to the pros).
When I tried to reset my password I got an error that my new password looked too much like the previous.
To my knowledge, they can't possibly know that unless they store it as plain text as even a single letter difference should generate a completely different hash.
Am I right to not trust these guys with my password?
Not that I really have a choice in the matter, but I'd at least give them a call about their (mal)practices...
<Realization>
I'm giving these guys my old password as part of the password renewing process...
Must be a Monday 
</Realization>
|
|
|
|
|
Did they not ask you to enter the previous password before setting the new password?
If you're entering the old and new password at the same time, then it's trivial to check.
If you've entered the old one and been told that it has expired, they may be storing the old password that you entered in memory to compare to the new one. It wouldn't be great, but it doesn't necessarily mean they're storing your password insecurely.
Alternatively, they may store the salt and hash for one or more previous passwords, apply simple variations to your new password, and see if the modified password produces the same hash as a previous password.
Without seeing their code, you can't be certain that they're not doing the wrong thing; but you can't be certain that they are doing the wrong thing either. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Have +5 for Monday! 
For the kind of lob apps I write, it is mandatory that the system is able to recall passwords for end users. The passwords are simply encrypted in the database. I don't believe this practice to be a security risk...besides, we aren't protecting sensitive data.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
If you can decrypt the passwords, so can the hackers. It is safer to store the hash.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
kmoorevs wrote: I don't believe this practice to be a security risk
Well, maybe not in terms of your app, but considering people aren't always careful about using different passwords across different platforms, it might be an external security risk. i.e. if user jdoe42 has password "hello world" in your app, chances are its "hello world" for his gmail, facebook, twitter, bank, yadda yadda yadda ...
Keep Calm and Carry On
|
|
|
|
|
I think recalling passwords for users is simply wrong.
It exposes a vector of attack, and if attacked, their passwords are then known.
I cannot think of a good reason to store someone's password. If they need a new one,
let them generate it via an email link, etc.
But the number of times a site has emailed me "Thanks for signing up... Remember your password is: abc123",
and I am thinking to myself...WHY? I usually go and delete the account...
Super Long passwords, and a password manager. Done.
|
|
|
|
|
Net engendered gentleman's affairs (13)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
