
As the author of the above picture
voiced very correctly, many beginners (and not very beginners) are faced with the problem of a high input threshold for knowledge and understanding.
I do not understand?
So, to me, as an inexperienced young man with an idea that will turn the world around, it is not clear: how to get all these quantities of GET, POST, INSERT, and most importantly CPU.
There are lots of solutions to this problem.
For example, to publish standard cases like “a website on WordPress with 10k hosts per day generates such a download profile”. Conveniently? Yes. Simple and inexpensive for a hoster? Yes. Widely applicable, the accuracy of the assessment is sufficient? As one of the participants in the discussion in the previous post noted, “one module in WordPress can increase the load on the processor by a factor of ten.”
')
You can give a demo access (or, on the other hand, buy a
glass of seeds from a cloud hoster
to drive an inexpensive entry-level option). Simply? Relatively. Widely applicable? Yes, because the site can be moved there entirely and loaded test ab'om. Conveniently? Far from it.
And here a thought came to me that had long knocked Klaas’s ashes on my heart
And if you create a virtual server on the hoster, upload the entire site there and set a stress tester on it, but not from the outside, but from the inside? If you feed the stress tester is not an abstract list of URLs and rules, but a live web server log?
For the site, such a test will not differ from the actual download: you can not even turn off DoS protection, bathing the “voracious” addresses - after all, the stress server can pretend for the site as a whole Internet.
This stress test will not load the external channels of the host (and testing the client’s future website), modeling not a spherical horse in a vacuum, but a real herd in a vacuum of “superfast channels”, because in the context of the task under discussion, we do not need a stress test. endurance ", and the amount of resources eaten by real customers on a real site.
This test can be launched as “accelerated”, loading the entire ASAP log, and at a speed of 1 to 1, and indeed at any one selected. Yes, testing the daily log will take a day, but does it bother you? But the hoster can plan the test in such a way that the maximum number of requests from the log was processed at the moment of minimal load on the site. Moreover, while delays do not begin to affect the logic of the site itself, such testing can be prioritized to minus infinity: well, “virtual” users will receive their page not in 2 seconds, not in 0.2, but in 22. But the number of CPU cycles, requests to the database, IOPS, traffic will be calculated correctly.
The input log can and should be corrected by simulating the slashdot moments (and it is quite simple to do this - take and mix copies of real sessions with modified IP addresses).
All steps are completely transparent and understandable even to the complete beginner.
Disadvantages of this method mass
This creates a load on the host, comparable to the real hosting. Minus the output channels, plus the alignment of the daily load, plus priorities - it will still eat the CPU, IOPS, and the like for real money.
This is quite time-consuming in the development: it will be necessary to create a structure of virtual servers, detached from the Internet, insulated and prioritized. Not rocket surgery, perhaps, but the development costs money.
This raises a lot of questions about personal data - uploading real logs to the host, even passed through some obfuscator (which still needs to be developed), is a delicate matter.
This imposes a lot of conditions on the client: it is no longer just a start-up, but a migrant with an existing site and a live log. What log is not yet available from every shared host? An “inanimate” log is difficult to create from scratch, not everyone can predict which part of the site will be visited most often. The notorious “one plugin in WordPress” can sit on the page where 1 user from 1000 comes in - and maybe on the page where 999 out of 999 sit (and they don’t go to other sections at all).
Well and, of course, not every site can be transferred to the cloud by simple copying - that is, even in order to estimate the cost of hosting, the client-webmaster has to spend time and / or money on the work of the coder to adapt.
There is a palliative option
The hoster lays out an image of a virtual machine (more precisely, a bunch of two machines, a hoster and a stressor), which the client launches on his laptop, on NAS, and on anything - this is already a question for the webmaster client.
Pluses compared to the above: there is no leakage of user data, there is no consumption of hoster resources.
The disadvantages are also quite obvious: firstly, if the webmaster has a home machine to cope with such a load on the site (at least at a “very low pace”), then he most likely does not need cloud hosting. Secondly, the leakage of the billing system and the actual hosting in the provided virtual image; however, you can give a trimmed version, suitable only for counting resources. Thirdly, it is necessary to very carefully consider the effect of virtualization on an unknown in advance hardware.
An additional bonus is the possibility of developing for a specific hosting platform.
And finally: both options, it seems to me, would be useful for non-cloud hosters.