Earlier quoted context omitted.
If the request is performing heavy calculations you will see fever req/sec obviously. Say an API call spins up a Linux VM and makes it available some user. Or a bulk upload of data which needs to be indexed. Or whatever. The idea that a site should be able to handle X requests/sec because the stack can handle X NOOPs per second is odd.
Not talking NOOPs. I'm talking multiple full round trips to the database per query. Node can render more NOOPs per second than that; I've heard of a well tuned Node server hitting 100k. But because of the async nature of the handling of responses, you don't need dozens or hundreds of threads to handle thousands of clients, and it's the threads that kill you. Unless you've just got an awful architecture, in which case…
My first DDoS attack for a $200 ransom
61–67 of 67 posts
Re: My first DDoS attack for a $200 ransom
#62Earlier quoted context omitted.
Well, when your DDOS is '10 requests a second', your site is probably not the most sophisticated.
Haha, true! But please share your personal DDoS experience is mine is not large enough :p
Re: My first DDoS attack for a $200 ransom
#63Earlier quoted context omitted.
Well, when your DDOS is '10 requests a second', your site is probably not the most sophisticated.
Haha, true! But please share your personal DDoS experience is mine is not large enough :p
Re: My first DDoS attack for a $200 ransom
#64Earlier quoted context omitted.
Not talking NOOPs. I'm talking multiple full round trips to the database per query. Node can render more NOOPs per second than that; I've heard of a well tuned Node server hitting 100k. But because of the async nature of the handling of responses, you don't need dozens or hundreds of threads to handle thousands of clients, and it's the threads that kill you. Unless you've just got an awful architecture, in which case…
I still don't understand what point you are trying to make. Surely you must agree that the number of requests per second your server will depends on what the server is doing? If your operation calls a DB or calculates something and that is heavy, then your db or internal calculation service might run out of resources. I'm not sorry, but your lack of experience with large scale systems is visible.
It's the poor design of most systems that cause them to not scale; there are certainly exceptions where the server needs to do a lot of complex calculations, but those calculations can most of the time be handled in microservices and, again, scaled orthogonally to the application layer.
Re: My first DDoS attack for a $200 ransom
#65Re: My first DDoS attack for a $200 ransom
#66villa-bali is not even close to this, my bet that you (or your ORM) are making too many requests to database. Try to record ALL requests to database during page rendering and I bet you have about hundred. Check out following test results:
8 test agents: http://loadme.socialtalents.com/Result/ViewById/57341f645b5f... - 5% of users have to wait more than 2 seconds 16 test agents: http://loadme.socialtalents.com/Result/ViewById/57341f1a5b5f... 5% of users need to wait for more than 4 seconds.
Definitely, any bot can nuke your website easily.
Re: My first DDoS attack for a $200 ransom
#67Earlier quoted context omitted.
And there are 73 persons on it right now if I believe Google Analytics
[ Edit: I'm almost certain it's an ipv6 vs ipv4 issue. the ipv4 addresses resolve to github pages land, the ipv6 address resolves to somewhere inside OVH - the issue being that if the viewer's network infrastructure prefers ipv6, they will get a holding page from OVH stating that that "Site not installed / The site ghirardotti.fr is not yet installed" ] Dig: dig ghirardotti.fr ;; ->>HEADER Both ip's belong to Github,…