I never really did the math before but I whacked something together real quick in Excel. At $0.30/THash BTC we can come up with some cost expectations for password lengths. Here I will use a 74 possible character password using 26 upper and lower case letters, 10 numbers and 12 symbols. Totally random of course. Using (Possible Chars ^ Password Length) as the number of combinations and guessing we will find our answer at about %50 of our guesses. (See! Super rough)
With SHA-256 it takes about $21 to crack a 6 character password.
$1500 to crack 7 characters.
$108,330 to crack 8 characters.
$7.8 million to crack 9 characters.
$561 million to crack 10 characters.
$40 billion to crack 11 characters.
$3 trillion to crack 12 characters.
$200 trillion to crack 13 characters.
Edit Note: BTC is kinda expensive per hash right now. Usually this would all be cheaper. Past 14 characters it could be 1 cent and still outrun the usual US budget for a couple years.
A big part of Bitcoin's entertaining in-fighting is due to the 'core' developers having a mindset that conflicts with many other people. Some speculate that this is because a large number of devs are paid by Blockstream, who have financial incentives to keep bitcoin congested so that their paid-for products (like their lightning implementations) have more value.
I have no bitcoins, so I have no real preference in what happens. But watching politics destroy a 'decentralised' currency is good entertainment :)
Polish is a great example of this. It looks like someone just mashed on the keyboard. There is a Polish mma fighter named Joanna Jedrzejczyk and no one has any clue how to say her last name.
"Unless you’ve goofed something up, the slowest part of your PHP-based application should be PHP itself."
Is the database not the bottleneck? Especially with the way wordpress stores "post meta data" with key and value columns it seems that the joins could get a bit ugly.
Most of the large, healthy PHP-based sites I’ve worked on spend 5-20% of their average request time in the database. Which means PHP is chewing 80-95%. Which makes PHP the slow bit.
Not because PHP is bad: That’s a pretty reasonable figure for platforms based on Ruby, Python, PHP, etc. (Less so for Java and .NET.)
It's a really good rule of thumb: If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed.
You’ve probably hit a database scalability limit, or tried to get the database to do something silly. (And hey, that’s easy to do with MySQL, which is fast primarily because it’s dumb.)
(By the way: WordPress, out of the box, doesn't spend much time in the database at all.)
I'm going to have to backup jdub on this. The "IO/database should be" classic wisdom has not really held up to my experience doing a stint providing managed support for LAMP(P as in PHP) servers at a hosting company. Most of the time there were performance issues it was PHP taking up the CPU's. We had a lot of success mitigating this for people with some proper varnish configs.
Very rarely was the issue with the databases. I've had people not want to normalize data and create some generally disgusting tables and code because "joins bad"... On tables that will only ever have a few 10k records. If you have the proper indexes and queries in place, your database is just traversing btree's in memory and it will be blazing fast.
> If you’re spending more time during each request doing database work rather than PHP work, then you’ve got a problem that needs to be fixed.
For most webapps, I/O typically should be the bottleneck. This holds especially true for wordpress, which has nothing computationally heavy to do, and is...rather liberal with the way it queries the database. Certainly the large installations I've managed spent most time doing I/O (either in the database or memcached.)
This is completely correct. On smaller sites, we're usually seeing 1% of total time spent in database, the rest being PHP. With larger sites, this increases a bit to around 5% because larger databases take longer to return queries.
It is, absolutely. And Wordpress is notoriously liberal with its queries and use of storage in relational database (unless something monumental has changed in the last year). There's a reason there are 8 million caching plugins.
If PHP is the slowest part of your application, you're probably in good shape. If your Wordpress application is slow, replacing PHP with Hack is like putting a souped up engine in a car with no gas in the tank.
PHP scaled poorly at Facebook not because it was PHP, but because it was Facebook. They would have run into the same (or worse) performance issues with most dynamically-typed languages.
HHVM was needed at Facebook because it's a dynamic app with rapidly changing content.
WordPress sites are typically static content that are perfectly fit for static caching with a CDN - it really shouldn't matter how many milliseconds you are able to save on the server if your site is only being hit once every two hours from the CDN.
The 8 million caching plugins are unnecessary when you can just sign up for cloudflare.
8 million caching plugins is a total exaggeration. As far as I can tell there's only two options: WP Super Cache (which seems to have been abandoned by the author) and W3 Total Cache which is a spammy mess of nag screens to join New Relic and MaxCDN. (No wonder it was banned by WP-Engine.) If I wasn't busy on other projects, I would take on W3 Total Cache--it's the worst UI I have ever seen and it doesn't even work. I had to mostly disable it today because my CPU went from 100% to 600% after installing it.
FYI, WP Super Cache is not really abandoned. The plugin author works for Automattic (as do I). I would say more that it has been so popular that support has been hard to keep up with and there hasn't been much focus on new features recently. Patches are always welcome: https://github.com/Automattic/wp-super-cache/
Cloudflare is - in this example - just one of the 8 million (albeit as a CDN, a far wiser choice).
Ultimately that sacrifice comes down to real-time dynamic site versus having some content be static or conditionally dynamic. None of that is a symptom of PHP as the backend (unless you have a LOT of traffic).
Yep. I double-checked that I hadn't borked the PHP install because I was surprised at the result. I'm not sure what it was doing to make the big difference since the inconsistencies with real PHP behavior were enough to write it off as a drop-in replacement, so I didn't continue experimenting much more, but it seemed promising.
I agree that the database is the bottleneck. I wrote a DB caching drop-in for WordPress and got pretty deep into the various queries that are running. There really aren't any nasty joins, but the problem is that the stock WordPress install with the default theme and no plugins runs nearly 30 DB queries per page. If you install once of the really slick commercial themes then WordPress will run upwards of 100 queries on every single page view.
Even a small site with a low level of traffic can bring a modest DB server to it's knees without caching of some type. It's really ridiculous but just due to the modular nature of WordPress.
I agree. And that's just fine for 99% of the bloggers that will never reach 1 million pageviews/month. Most of those queries are unnecessary. But rather than fix the root of the problem, we put the whole database in memory. Run out of memory? No problem, move to a solid state drive! LOL.
With a caching plugin like W3 Total Cache you should not be hitting the database very often. I take this a step further and cache the entire site (not just resources) on CloudFront.
In my opinion site-wide caching (like Cloudfront) is the best answer. The fewer plugins the better. Ideally WP is just the publishing backend for whatever CDN-type solution you use.
It shouldn't be. If it is, it's because you missed a cache result. Even for highly dynamic sites, the DB should never be the slowest part of your app because you rarely hit it.
I did some server engineering for a large media property based on WordPress. The New Relic graph normally indicated > 80% of request turnaround was spent in PHP. An average request (there was a frontend caching layer in place) that hit the app would normally take ~700ms, of which ~550 would be spent in WordPress. I attributed it mostly to WordPress being WordPress though. A lean PHP API can turn a typical request around on similar machinery in 1/10 the time.
That doesn't discount that the database is ridiculously ugly, though.
"I attributed it mostly to WordPress being WordPress though."
One of the unfortunate issues with Wordpress is their continued support for outdated PHP versions. Wordpress is compatible with as far back as PHP 5.2.4, which was released back in 2007. There have been many performance improvements to PHP since the early versions of 5.x. The fact that Wordpress is eating up so much CPU on trivial CRUD logic is probably attributed to the sheer amount of technical debt/cruft in the code base, but also compounded by the need (insistence?) to support legacy systems, thus not being able to take advantage of newer features of PHP.
The conservative choice of PHP 5.2 as the minimum requirement for WordPress doesn't stop performance sensitive sites using later versions of PHP, or HHVM, or Phalanger, or whatever floats their boat.
Indeed, only 30% of WordPress installs use PHP 5.2.
Runtime features are not a problem for WordPress users.
If you think the minimum requirement is limiting potential for optimisation, what are some relevant language and library features in subsequent versions that the WordPress team can’t use?
In that example, I bet WordPress on its own would have spent less than 550ms without having to replenish your cache layer. Also how much of that time was actually PHP vs. PHP waiting for MySQL? I bet if you scattered microtimers throughout WordPress, you would see 99% of your 550ms would be waiting for the disk and MySQL.
WordPress wasn't updating the cache; I mention that because 700ms is painfully slow, once all the JS and ads run load time can cross 2 full seconds. The cache becomes the only acceptable way to run it in production.
New Relic actually provides a breakdown of how much time was spent in each function; while I don't remember offhand what that was, there wasn't any low-hanging fruit that could be optimized.
how long are we talking?