amazing
Help Center
Ask questions and help others in this forum.
TOPIC | How to Avoid Being Banned/Suspended?
Oh, for the love of god.
1. Go get NewRelic if you haven't already. It'll tell you exactly what queries are causing your bottlenecks. MYSQL eating up memory is the number one cause of lag on websites like this, and you're not going to solve that problem by banning users who happen to hit on heavy queries.
2. Go install LiteSpeed onto your server and use their DDOS tools, if you are actually getting a DDOS (which I doubt), to mitigate unwanted traffic attack. If you're using Apache, replace it with Litespeed because Apache is bloated and gross and Litespeed has DDOS tools!
Just for fun I ran Flightrising.com through the Website Optimizer, and here's what it has to say:
Look into the optimization warnings too, because these are problems with your layout, which is loaded every time the user views the page.
1. Go get NewRelic if you haven't already. It'll tell you exactly what queries are causing your bottlenecks. MYSQL eating up memory is the number one cause of lag on websites like this, and you're not going to solve that problem by banning users who happen to hit on heavy queries.
2. Go install LiteSpeed onto your server and use their DDOS tools, if you are actually getting a DDOS (which I doubt), to mitigate unwanted traffic attack. If you're using Apache, replace it with Litespeed because Apache is bloated and gross and Litespeed has DDOS tools!
Just for fun I ran Flightrising.com through the Website Optimizer, and here's what it has to say:
Quote:
Analysis and Recommendations
TOTAL_HTML - Congratulations, the total number of HTML files on this page (including the main HTML file) is 1 which most browsers can multithread. Minimizing HTTP requests is key for web site optimization. Y
TOTAL_OBJECTS - Warning! The total number of objects on this page is 41 which by their number will dominate web page delay. Consider reducing this to a more reasonable number. Above 20 objects per page the overhead from dealing with the actual objects (description time and wait time) accounts for more than 80% of whole page latency. See Figure II-3: Relative distribution of latency components showing that object overhead dominates web page latency in Website Optimization Secrets for more details on how object overhead dominates web page latency. Combine, refine, and optimize your external objects. Replace graphic rollovers with CSS rollovers to speed display and minimize HTTP requests. Consider using CSS sprites to help consolidate decorative images. Using CSS techniques such as colored backgrounds, borders, or spacing instead of graphic techniques can reduce HTTP requests. Replace graphic text headers with CSS text headers to further reduce HTTP requests. Finally, consider optimizing parallel downloads by using different hostnames or a CDN to reduce object overhead.
TOTAL_IMAGES - Warning! The total number of images on this page is 30 , consider reducing this to a more reasonable number. Recommend combining, replacing, and optimizing your graphics. Replace graphic rollover menus with CSS rollover menus to speed display and minimize HTTP requests. Consider using CSS sprites to help consolidate decorative images. Use CSS techniques such as colored backgrounds, borders, or spacing instead of graphic techniques to reduce HTTP requests. Replace graphic text headers with CSS text headers to further reduce HTTP requests. Finally, consider optimizing parallel downloads by using different hostnames to reduce object overhead.
TOTAL_CSS - Caution. The total number of external CSS files on this page is 3 , consider reducing this to a more reasonable number. Because external CSS files must be in the HEAD of your HTML document, they must load first before any BODY content displays. Although they are cached upon subsequent requests, CSS files slow down the initial display of your page. Combine, refine, and optimize your external CSS files. Ideally you should have one (or even embed CSS for high-traffic pages) on your pages. You can optimize CSS files using shorthand properties, grouping, and then minify and GZIP compress them to reduce their footprint. Remember to place CSS files in the HEAD and JavaScript files at the end of the BODY to enable progressive display.
TOTAL_SIZE - Warning! The total size of this page is 497308 bytes, which will load in 107.31 seconds on a 56Kbps modem. Consider reducing total page size to less than 100K to achieve sub 20 second response times on 56K connections. Pages over 100K exceed most attention thresholds at 56Kbps, even with feedback. Consider optimizing your site with Website Optimization Secrets, Speed Up Your Site or contacting us about our optimization services.
TOTAL_SCRIPT - Warning! The total number of external script files on this page is 7 , consider reducing this to a more reasonable number. Combine, refactor, and minify to optimize your JavaScript files. Ideally you should have one (or even embed scripts for high-traffic pages) on your pages. Consider suturing JavaScript files together at the server to minimize HTTP requests. Placing external JavaScript files at the bottom of your BODY, and CSS files in the HEAD enables progressive display in XHTML web pages.
HTML_SIZE - Congratulations, the total size of this HTML file is 6885 bytes, which less than 50K. Assuming that you specify the HEIGHT and WIDTH of your images, this size allows your HTML to display content in under 10 seconds, the average time users are willing to wait for a page to display without feedback.
IMAGES_SIZE - Warning! The total size of your images is 464861 bytes, which is over 100K. Consider switch graphic formats to achive smaller file sizes (from JPEG to PNG for example). Finally, substitute CSS techniques for graphics techniques to create colored borders, backgrounds, and spacing.
SCRIPT_SIZE - Caution. The total size of your external scripts is 10172 bytes, which is above 8K and less than 20K. Consider optimizing your scripts and eliminating features to reduce this to a more reasonable size. You can substitute CSS menus for JavaScript-based menus to minimize or even eliminate the use of JavaScript.
CSS_SIZE - Caution. The total size of your external CSS is 15390 bytes, which is above 8K and less than 20K. For external files, ideally keep them less than 1160 bytes to fit within one higher-speed TCP-IP packet (or an approximate multiple thereof). Consider optimizing your CSS and eliminating features to reduce this to a more reasonable size.
MULTIM_SIZE - Congratulations, the total size of all your external multimedia files is 0 bytes, which is less than 10K.
TOTAL_HTML - Congratulations, the total number of HTML files on this page (including the main HTML file) is 1 which most browsers can multithread. Minimizing HTTP requests is key for web site optimization. Y
TOTAL_OBJECTS - Warning! The total number of objects on this page is 41 which by their number will dominate web page delay. Consider reducing this to a more reasonable number. Above 20 objects per page the overhead from dealing with the actual objects (description time and wait time) accounts for more than 80% of whole page latency. See Figure II-3: Relative distribution of latency components showing that object overhead dominates web page latency in Website Optimization Secrets for more details on how object overhead dominates web page latency. Combine, refine, and optimize your external objects. Replace graphic rollovers with CSS rollovers to speed display and minimize HTTP requests. Consider using CSS sprites to help consolidate decorative images. Using CSS techniques such as colored backgrounds, borders, or spacing instead of graphic techniques can reduce HTTP requests. Replace graphic text headers with CSS text headers to further reduce HTTP requests. Finally, consider optimizing parallel downloads by using different hostnames or a CDN to reduce object overhead.
TOTAL_IMAGES - Warning! The total number of images on this page is 30 , consider reducing this to a more reasonable number. Recommend combining, replacing, and optimizing your graphics. Replace graphic rollover menus with CSS rollover menus to speed display and minimize HTTP requests. Consider using CSS sprites to help consolidate decorative images. Use CSS techniques such as colored backgrounds, borders, or spacing instead of graphic techniques to reduce HTTP requests. Replace graphic text headers with CSS text headers to further reduce HTTP requests. Finally, consider optimizing parallel downloads by using different hostnames to reduce object overhead.
TOTAL_CSS - Caution. The total number of external CSS files on this page is 3 , consider reducing this to a more reasonable number. Because external CSS files must be in the HEAD of your HTML document, they must load first before any BODY content displays. Although they are cached upon subsequent requests, CSS files slow down the initial display of your page. Combine, refine, and optimize your external CSS files. Ideally you should have one (or even embed CSS for high-traffic pages) on your pages. You can optimize CSS files using shorthand properties, grouping, and then minify and GZIP compress them to reduce their footprint. Remember to place CSS files in the HEAD and JavaScript files at the end of the BODY to enable progressive display.
TOTAL_SIZE - Warning! The total size of this page is 497308 bytes, which will load in 107.31 seconds on a 56Kbps modem. Consider reducing total page size to less than 100K to achieve sub 20 second response times on 56K connections. Pages over 100K exceed most attention thresholds at 56Kbps, even with feedback. Consider optimizing your site with Website Optimization Secrets, Speed Up Your Site or contacting us about our optimization services.
TOTAL_SCRIPT - Warning! The total number of external script files on this page is 7 , consider reducing this to a more reasonable number. Combine, refactor, and minify to optimize your JavaScript files. Ideally you should have one (or even embed scripts for high-traffic pages) on your pages. Consider suturing JavaScript files together at the server to minimize HTTP requests. Placing external JavaScript files at the bottom of your BODY, and CSS files in the HEAD enables progressive display in XHTML web pages.
HTML_SIZE - Congratulations, the total size of this HTML file is 6885 bytes, which less than 50K. Assuming that you specify the HEIGHT and WIDTH of your images, this size allows your HTML to display content in under 10 seconds, the average time users are willing to wait for a page to display without feedback.
IMAGES_SIZE - Warning! The total size of your images is 464861 bytes, which is over 100K. Consider switch graphic formats to achive smaller file sizes (from JPEG to PNG for example). Finally, substitute CSS techniques for graphics techniques to create colored borders, backgrounds, and spacing.
SCRIPT_SIZE - Caution. The total size of your external scripts is 10172 bytes, which is above 8K and less than 20K. Consider optimizing your scripts and eliminating features to reduce this to a more reasonable size. You can substitute CSS menus for JavaScript-based menus to minimize or even eliminate the use of JavaScript.
CSS_SIZE - Caution. The total size of your external CSS is 15390 bytes, which is above 8K and less than 20K. For external files, ideally keep them less than 1160 bytes to fit within one higher-speed TCP-IP packet (or an approximate multiple thereof). Consider optimizing your CSS and eliminating features to reduce this to a more reasonable size.
MULTIM_SIZE - Congratulations, the total size of all your external multimedia files is 0 bytes, which is less than 10K.
Look into the optimization warnings too, because these are problems with your layout, which is loaded every time the user views the page.
Oh, for the love of god.
1. Go get NewRelic if you haven't already. It'll tell you exactly what queries are causing your bottlenecks. MYSQL eating up memory is the number one cause of lag on websites like this, and you're not going to solve that problem by banning users who happen to hit on heavy queries.
2. Go install LiteSpeed onto your server and use their DDOS tools, if you are actually getting a DDOS (which I doubt), to mitigate unwanted traffic attack. If you're using Apache, replace it with Litespeed because Apache is bloated and gross and Litespeed has DDOS tools!
Just for fun I ran Flightrising.com through the Website Optimizer, and here's what it has to say:
Look into the optimization warnings too, because these are problems with your layout, which is loaded every time the user views the page.
1. Go get NewRelic if you haven't already. It'll tell you exactly what queries are causing your bottlenecks. MYSQL eating up memory is the number one cause of lag on websites like this, and you're not going to solve that problem by banning users who happen to hit on heavy queries.
2. Go install LiteSpeed onto your server and use their DDOS tools, if you are actually getting a DDOS (which I doubt), to mitigate unwanted traffic attack. If you're using Apache, replace it with Litespeed because Apache is bloated and gross and Litespeed has DDOS tools!
Just for fun I ran Flightrising.com through the Website Optimizer, and here's what it has to say:
Quote:
Analysis and Recommendations
TOTAL_HTML - Congratulations, the total number of HTML files on this page (including the main HTML file) is 1 which most browsers can multithread. Minimizing HTTP requests is key for web site optimization. Y
TOTAL_OBJECTS - Warning! The total number of objects on this page is 41 which by their number will dominate web page delay. Consider reducing this to a more reasonable number. Above 20 objects per page the overhead from dealing with the actual objects (description time and wait time) accounts for more than 80% of whole page latency. See Figure II-3: Relative distribution of latency components showing that object overhead dominates web page latency in Website Optimization Secrets for more details on how object overhead dominates web page latency. Combine, refine, and optimize your external objects. Replace graphic rollovers with CSS rollovers to speed display and minimize HTTP requests. Consider using CSS sprites to help consolidate decorative images. Using CSS techniques such as colored backgrounds, borders, or spacing instead of graphic techniques can reduce HTTP requests. Replace graphic text headers with CSS text headers to further reduce HTTP requests. Finally, consider optimizing parallel downloads by using different hostnames or a CDN to reduce object overhead.
TOTAL_IMAGES - Warning! The total number of images on this page is 30 , consider reducing this to a more reasonable number. Recommend combining, replacing, and optimizing your graphics. Replace graphic rollover menus with CSS rollover menus to speed display and minimize HTTP requests. Consider using CSS sprites to help consolidate decorative images. Use CSS techniques such as colored backgrounds, borders, or spacing instead of graphic techniques to reduce HTTP requests. Replace graphic text headers with CSS text headers to further reduce HTTP requests. Finally, consider optimizing parallel downloads by using different hostnames to reduce object overhead.
TOTAL_CSS - Caution. The total number of external CSS files on this page is 3 , consider reducing this to a more reasonable number. Because external CSS files must be in the HEAD of your HTML document, they must load first before any BODY content displays. Although they are cached upon subsequent requests, CSS files slow down the initial display of your page. Combine, refine, and optimize your external CSS files. Ideally you should have one (or even embed CSS for high-traffic pages) on your pages. You can optimize CSS files using shorthand properties, grouping, and then minify and GZIP compress them to reduce their footprint. Remember to place CSS files in the HEAD and JavaScript files at the end of the BODY to enable progressive display.
TOTAL_SIZE - Warning! The total size of this page is 497308 bytes, which will load in 107.31 seconds on a 56Kbps modem. Consider reducing total page size to less than 100K to achieve sub 20 second response times on 56K connections. Pages over 100K exceed most attention thresholds at 56Kbps, even with feedback. Consider optimizing your site with Website Optimization Secrets, Speed Up Your Site or contacting us about our optimization services.
TOTAL_SCRIPT - Warning! The total number of external script files on this page is 7 , consider reducing this to a more reasonable number. Combine, refactor, and minify to optimize your JavaScript files. Ideally you should have one (or even embed scripts for high-traffic pages) on your pages. Consider suturing JavaScript files together at the server to minimize HTTP requests. Placing external JavaScript files at the bottom of your BODY, and CSS files in the HEAD enables progressive display in XHTML web pages.
HTML_SIZE - Congratulations, the total size of this HTML file is 6885 bytes, which less than 50K. Assuming that you specify the HEIGHT and WIDTH of your images, this size allows your HTML to display content in under 10 seconds, the average time users are willing to wait for a page to display without feedback.
IMAGES_SIZE - Warning! The total size of your images is 464861 bytes, which is over 100K. Consider switch graphic formats to achive smaller file sizes (from JPEG to PNG for example). Finally, substitute CSS techniques for graphics techniques to create colored borders, backgrounds, and spacing.
SCRIPT_SIZE - Caution. The total size of your external scripts is 10172 bytes, which is above 8K and less than 20K. Consider optimizing your scripts and eliminating features to reduce this to a more reasonable size. You can substitute CSS menus for JavaScript-based menus to minimize or even eliminate the use of JavaScript.
CSS_SIZE - Caution. The total size of your external CSS is 15390 bytes, which is above 8K and less than 20K. For external files, ideally keep them less than 1160 bytes to fit within one higher-speed TCP-IP packet (or an approximate multiple thereof). Consider optimizing your CSS and eliminating features to reduce this to a more reasonable size.
MULTIM_SIZE - Congratulations, the total size of all your external multimedia files is 0 bytes, which is less than 10K.
TOTAL_HTML - Congratulations, the total number of HTML files on this page (including the main HTML file) is 1 which most browsers can multithread. Minimizing HTTP requests is key for web site optimization. Y
TOTAL_OBJECTS - Warning! The total number of objects on this page is 41 which by their number will dominate web page delay. Consider reducing this to a more reasonable number. Above 20 objects per page the overhead from dealing with the actual objects (description time and wait time) accounts for more than 80% of whole page latency. See Figure II-3: Relative distribution of latency components showing that object overhead dominates web page latency in Website Optimization Secrets for more details on how object overhead dominates web page latency. Combine, refine, and optimize your external objects. Replace graphic rollovers with CSS rollovers to speed display and minimize HTTP requests. Consider using CSS sprites to help consolidate decorative images. Using CSS techniques such as colored backgrounds, borders, or spacing instead of graphic techniques can reduce HTTP requests. Replace graphic text headers with CSS text headers to further reduce HTTP requests. Finally, consider optimizing parallel downloads by using different hostnames or a CDN to reduce object overhead.
TOTAL_IMAGES - Warning! The total number of images on this page is 30 , consider reducing this to a more reasonable number. Recommend combining, replacing, and optimizing your graphics. Replace graphic rollover menus with CSS rollover menus to speed display and minimize HTTP requests. Consider using CSS sprites to help consolidate decorative images. Use CSS techniques such as colored backgrounds, borders, or spacing instead of graphic techniques to reduce HTTP requests. Replace graphic text headers with CSS text headers to further reduce HTTP requests. Finally, consider optimizing parallel downloads by using different hostnames to reduce object overhead.
TOTAL_CSS - Caution. The total number of external CSS files on this page is 3 , consider reducing this to a more reasonable number. Because external CSS files must be in the HEAD of your HTML document, they must load first before any BODY content displays. Although they are cached upon subsequent requests, CSS files slow down the initial display of your page. Combine, refine, and optimize your external CSS files. Ideally you should have one (or even embed CSS for high-traffic pages) on your pages. You can optimize CSS files using shorthand properties, grouping, and then minify and GZIP compress them to reduce their footprint. Remember to place CSS files in the HEAD and JavaScript files at the end of the BODY to enable progressive display.
TOTAL_SIZE - Warning! The total size of this page is 497308 bytes, which will load in 107.31 seconds on a 56Kbps modem. Consider reducing total page size to less than 100K to achieve sub 20 second response times on 56K connections. Pages over 100K exceed most attention thresholds at 56Kbps, even with feedback. Consider optimizing your site with Website Optimization Secrets, Speed Up Your Site or contacting us about our optimization services.
TOTAL_SCRIPT - Warning! The total number of external script files on this page is 7 , consider reducing this to a more reasonable number. Combine, refactor, and minify to optimize your JavaScript files. Ideally you should have one (or even embed scripts for high-traffic pages) on your pages. Consider suturing JavaScript files together at the server to minimize HTTP requests. Placing external JavaScript files at the bottom of your BODY, and CSS files in the HEAD enables progressive display in XHTML web pages.
HTML_SIZE - Congratulations, the total size of this HTML file is 6885 bytes, which less than 50K. Assuming that you specify the HEIGHT and WIDTH of your images, this size allows your HTML to display content in under 10 seconds, the average time users are willing to wait for a page to display without feedback.
IMAGES_SIZE - Warning! The total size of your images is 464861 bytes, which is over 100K. Consider switch graphic formats to achive smaller file sizes (from JPEG to PNG for example). Finally, substitute CSS techniques for graphics techniques to create colored borders, backgrounds, and spacing.
SCRIPT_SIZE - Caution. The total size of your external scripts is 10172 bytes, which is above 8K and less than 20K. Consider optimizing your scripts and eliminating features to reduce this to a more reasonable size. You can substitute CSS menus for JavaScript-based menus to minimize or even eliminate the use of JavaScript.
CSS_SIZE - Caution. The total size of your external CSS is 15390 bytes, which is above 8K and less than 20K. For external files, ideally keep them less than 1160 bytes to fit within one higher-speed TCP-IP packet (or an approximate multiple thereof). Consider optimizing your CSS and eliminating features to reduce this to a more reasonable size.
MULTIM_SIZE - Congratulations, the total size of all your external multimedia files is 0 bytes, which is less than 10K.
Look into the optimization warnings too, because these are problems with your layout, which is loaded every time the user views the page.
@Helmintio
Dang. Nice, that all makes a lot of sense. Thanks for the optimization stuff, it's nice to see that info!
Dang. Nice, that all makes a lot of sense. Thanks for the optimization stuff, it's nice to see that info!
@Helmintio
Dang. Nice, that all makes a lot of sense. Thanks for the optimization stuff, it's nice to see that info!
Dang. Nice, that all makes a lot of sense. Thanks for the optimization stuff, it's nice to see that info!
.
A user behaving normally on a website can easily look like a DDOS attack if there's a really poorly made query that just spams the database up with requests. Just refreshing the page a couple of times can cause some nasty hangups in MYSQL if you have one. The solution is to locate those (and NewRelic will point them right out to you, along with some other very useful traffic bottleneck data) and fix them.
Another tool that I happen to find rather fun, is to look at the MYSQL requests: if you're going through a lag patch, load up WHM and look at the MYSQL queries tab. It'll tell you what queries are going through to the database as well as how long they're taking. If you're encountering a lag patch you're going to find a couple of queries near the top that display processing at 100 sec+. Those queries are usually ones you need to check out.
And, of course, there's the MYSQL slow query log. It'll tell you which queries are taking the longest and thus are ones that need to be optimized. Not having indexes in your database can cause a lot of issues too, especially if you're looking through a very large database like the dragons one must be considering how many there are on the website. I don't know if the FR admins have indexed the database properly, but it has a learning curve.
Another tool that I happen to find rather fun, is to look at the MYSQL requests: if you're going through a lag patch, load up WHM and look at the MYSQL queries tab. It'll tell you what queries are going through to the database as well as how long they're taking. If you're encountering a lag patch you're going to find a couple of queries near the top that display processing at 100 sec+. Those queries are usually ones you need to check out.
And, of course, there's the MYSQL slow query log. It'll tell you which queries are taking the longest and thus are ones that need to be optimized. Not having indexes in your database can cause a lot of issues too, especially if you're looking through a very large database like the dragons one must be considering how many there are on the website. I don't know if the FR admins have indexed the database properly, but it has a learning curve.
A user behaving normally on a website can easily look like a DDOS attack if there's a really poorly made query that just spams the database up with requests. Just refreshing the page a couple of times can cause some nasty hangups in MYSQL if you have one. The solution is to locate those (and NewRelic will point them right out to you, along with some other very useful traffic bottleneck data) and fix them.
Another tool that I happen to find rather fun, is to look at the MYSQL requests: if you're going through a lag patch, load up WHM and look at the MYSQL queries tab. It'll tell you what queries are going through to the database as well as how long they're taking. If you're encountering a lag patch you're going to find a couple of queries near the top that display processing at 100 sec+. Those queries are usually ones you need to check out.
And, of course, there's the MYSQL slow query log. It'll tell you which queries are taking the longest and thus are ones that need to be optimized. Not having indexes in your database can cause a lot of issues too, especially if you're looking through a very large database like the dragons one must be considering how many there are on the website. I don't know if the FR admins have indexed the database properly, but it has a learning curve.
Another tool that I happen to find rather fun, is to look at the MYSQL requests: if you're going through a lag patch, load up WHM and look at the MYSQL queries tab. It'll tell you what queries are going through to the database as well as how long they're taking. If you're encountering a lag patch you're going to find a couple of queries near the top that display processing at 100 sec+. Those queries are usually ones you need to check out.
And, of course, there's the MYSQL slow query log. It'll tell you which queries are taking the longest and thus are ones that need to be optimized. Not having indexes in your database can cause a lot of issues too, especially if you're looking through a very large database like the dragons one must be considering how many there are on the website. I don't know if the FR admins have indexed the database properly, but it has a learning curve.
[quote name="Ankokou" date="2014-02-16 12:32:11"]Hopefully this isn't against the ToU, since it isn't about a single incident but rather is an open inquiry.
I'm afraid to do normal daily activities like bonding with my familiars and using the search to find mates for my selective breeding projects.[/quote]
We're slaughtering lambs to find the wolves among us.
Ankokou wrote on 2014-02-16 12:32:11:
Hopefully this isn't against the ToU, since it isn't about a single incident but rather is an open inquiry.
I'm afraid to do normal daily activities like bonding with my familiars and using the search to find mates for my selective breeding projects.
I'm afraid to do normal daily activities like bonding with my familiars and using the search to find mates for my selective breeding projects.
We're slaughtering lambs to find the wolves among us.
In addition to the great information provided above, is there any particular reason the site apparently uses PNG-24 instead of PNG-8 (compressed via something like [url=https://tinypng.com/]tinypng[/url]?) Is there something with compression that would make the generation of dragon images malfunction?
Because:
[img]http://i.imgur.com/Alx6bSY.png[/img]
(177k)
[img]http://i.imgur.com/zyTqdEq.png[/img]
(56k)
121k x HoweverManyDragonImagesGetServedPerDay ...
Of course the images will vary in size based on color and complexity, but. Big difference. That might help site function overall. (I know this isn't related directly to excessive queries/DoS-type-loads, but it is relevant to bandwidth and general performance.)
Eh. The way this whole thing is being handled is offensively awkward.
In addition to the great information provided above, is there any particular reason the site apparently uses PNG-24 instead of PNG-8 (compressed via something like tinypng?) Is there something with compression that would make the generation of dragon images malfunction?
Because:
(177k)
(56k)
121k x HoweverManyDragonImagesGetServedPerDay ...
Of course the images will vary in size based on color and complexity, but. Big difference. That might help site function overall. (I know this isn't related directly to excessive queries/DoS-type-loads, but it is relevant to bandwidth and general performance.)
Eh. The way this whole thing is being handled is offensively awkward.
Because:
(177k)
(56k)
121k x HoweverManyDragonImagesGetServedPerDay ...
Of course the images will vary in size based on color and complexity, but. Big difference. That might help site function overall. (I know this isn't related directly to excessive queries/DoS-type-loads, but it is relevant to bandwidth and general performance.)
Eh. The way this whole thing is being handled is offensively awkward.
First of all, many thanks to you @Ankoku and to the other users who messaged me with kind wishes for my friend. I am sad to say that as of right now she still has not been restored to FR despite complete cooperation, and has not yet been told what she has done either. What @Helmentio posted is a very good synopsis of what seems like it is happening here, and also sounds like what my friend noticed (and attempted to suggest, as she uses anti-DDOS tools herself).
Beyond that, however, I think there is a very large problem when you tell the user base to keep using the site as normal and then ban/suspend them for doing just that--especially when the people getting suspended are the ones basically doing the debugging for you.
Beyond that, however, I think there is a very large problem when you tell the user base to keep using the site as normal and then ban/suspend them for doing just that--especially when the people getting suspended are the ones basically doing the debugging for you.
First of all, many thanks to you @Ankoku and to the other users who messaged me with kind wishes for my friend. I am sad to say that as of right now she still has not been restored to FR despite complete cooperation, and has not yet been told what she has done either. What @Helmentio posted is a very good synopsis of what seems like it is happening here, and also sounds like what my friend noticed (and attempted to suggest, as she uses anti-DDOS tools herself).
Beyond that, however, I think there is a very large problem when you tell the user base to keep using the site as normal and then ban/suspend them for doing just that--especially when the people getting suspended are the ones basically doing the debugging for you.
Beyond that, however, I think there is a very large problem when you tell the user base to keep using the site as normal and then ban/suspend them for doing just that--especially when the people getting suspended are the ones basically doing the debugging for you.
Yeah, I especially found this troubling when the word is that MULTILINKS and the like are causing traffic issues and look like a ddos attack to the diagnostics. I hope that wasn't a call from lightsky, because if it was, they're not worth a single fraction of the money they're being paid.
If at any point that someone using multilinks is sending out red flags like that, it's time to spend some long nights with the coding, because it's not them that's got the problem, it's you. Because that's a whole bunch of unneeded calls to resources. Then again this really is part of the same tune coders where whistling about a few months back as well ("WHY ARE TOOLTIPS MAKING CALLS TO DYNAMIC DATA, WHY?!" anyone?).
By comparison every single other petsite, no matter how duct-taped together their servers were and how shoddy their coding was... never had a problem with any link-opening extensions their users had. So for Flight Rising to be little jimmy special about this, even with shiny new servers, a kickstarter, and a decent bit coming in from sales each month, this isn't a user problem, this is a developer problem.
On top of that, there's the absolutely awful customer service and throwing babies out with the bathwater here. "Oh no" comes the cries, "we can't tell you anything useful on how to avoid being banned. Just don't do the thing" "The thing?" we say, "Tell us this thing, give us clues, or at least give us our accounts back in a reasonable timeframe if we're at risk of being banned every other week under your constantly shifting and contradictory rules!" But no, no, the staff and mods clasp their hands to their chests in shock and gasp "but then the hackers will know too! Here, take these whispered rumors on tumblr, these vague interpretive dances of the tos, these mute shadow plays of what it might be but mostly is not, take them, for the enemy is everywhere."
And then we start to back out of the room a little bit, because that's startin' to sound a mite crazy. We just want to play our dumb pixel dragon game without being banned, that's all.
If at any point that someone using multilinks is sending out red flags like that, it's time to spend some long nights with the coding, because it's not them that's got the problem, it's you. Because that's a whole bunch of unneeded calls to resources. Then again this really is part of the same tune coders where whistling about a few months back as well ("WHY ARE TOOLTIPS MAKING CALLS TO DYNAMIC DATA, WHY?!" anyone?).
By comparison every single other petsite, no matter how duct-taped together their servers were and how shoddy their coding was... never had a problem with any link-opening extensions their users had. So for Flight Rising to be little jimmy special about this, even with shiny new servers, a kickstarter, and a decent bit coming in from sales each month, this isn't a user problem, this is a developer problem.
On top of that, there's the absolutely awful customer service and throwing babies out with the bathwater here. "Oh no" comes the cries, "we can't tell you anything useful on how to avoid being banned. Just don't do the thing" "The thing?" we say, "Tell us this thing, give us clues, or at least give us our accounts back in a reasonable timeframe if we're at risk of being banned every other week under your constantly shifting and contradictory rules!" But no, no, the staff and mods clasp their hands to their chests in shock and gasp "but then the hackers will know too! Here, take these whispered rumors on tumblr, these vague interpretive dances of the tos, these mute shadow plays of what it might be but mostly is not, take them, for the enemy is everywhere."
And then we start to back out of the room a little bit, because that's startin' to sound a mite crazy. We just want to play our dumb pixel dragon game without being banned, that's all.
Yeah, I especially found this troubling when the word is that MULTILINKS and the like are causing traffic issues and look like a ddos attack to the diagnostics. I hope that wasn't a call from lightsky, because if it was, they're not worth a single fraction of the money they're being paid.
If at any point that someone using multilinks is sending out red flags like that, it's time to spend some long nights with the coding, because it's not them that's got the problem, it's you. Because that's a whole bunch of unneeded calls to resources. Then again this really is part of the same tune coders where whistling about a few months back as well ("WHY ARE TOOLTIPS MAKING CALLS TO DYNAMIC DATA, WHY?!" anyone?).
By comparison every single other petsite, no matter how duct-taped together their servers were and how shoddy their coding was... never had a problem with any link-opening extensions their users had. So for Flight Rising to be little jimmy special about this, even with shiny new servers, a kickstarter, and a decent bit coming in from sales each month, this isn't a user problem, this is a developer problem.
On top of that, there's the absolutely awful customer service and throwing babies out with the bathwater here. "Oh no" comes the cries, "we can't tell you anything useful on how to avoid being banned. Just don't do the thing" "The thing?" we say, "Tell us this thing, give us clues, or at least give us our accounts back in a reasonable timeframe if we're at risk of being banned every other week under your constantly shifting and contradictory rules!" But no, no, the staff and mods clasp their hands to their chests in shock and gasp "but then the hackers will know too! Here, take these whispered rumors on tumblr, these vague interpretive dances of the tos, these mute shadow plays of what it might be but mostly is not, take them, for the enemy is everywhere."
And then we start to back out of the room a little bit, because that's startin' to sound a mite crazy. We just want to play our dumb pixel dragon game without being banned, that's all.
If at any point that someone using multilinks is sending out red flags like that, it's time to spend some long nights with the coding, because it's not them that's got the problem, it's you. Because that's a whole bunch of unneeded calls to resources. Then again this really is part of the same tune coders where whistling about a few months back as well ("WHY ARE TOOLTIPS MAKING CALLS TO DYNAMIC DATA, WHY?!" anyone?).
By comparison every single other petsite, no matter how duct-taped together their servers were and how shoddy their coding was... never had a problem with any link-opening extensions their users had. So for Flight Rising to be little jimmy special about this, even with shiny new servers, a kickstarter, and a decent bit coming in from sales each month, this isn't a user problem, this is a developer problem.
On top of that, there's the absolutely awful customer service and throwing babies out with the bathwater here. "Oh no" comes the cries, "we can't tell you anything useful on how to avoid being banned. Just don't do the thing" "The thing?" we say, "Tell us this thing, give us clues, or at least give us our accounts back in a reasonable timeframe if we're at risk of being banned every other week under your constantly shifting and contradictory rules!" But no, no, the staff and mods clasp their hands to their chests in shock and gasp "but then the hackers will know too! Here, take these whispered rumors on tumblr, these vague interpretive dances of the tos, these mute shadow plays of what it might be but mostly is not, take them, for the enemy is everywhere."
And then we start to back out of the room a little bit, because that's startin' to sound a mite crazy. We just want to play our dumb pixel dragon game without being banned, that's all.
PNG 8 has no transparency. The FR artists are artists - they value dragon art quality over bandwidth cost.
PNG 8 has no transparency. The FR artists are artists - they value dragon art quality over bandwidth cost.
Participating in Trick or Treat
The coding on this site has always been a trainwreck, and now the customer service that matches it is becoming more apparent to the wider database.
casually awaits 'random mistaken banning for "DDOS attacking" through normal use'
The coding on this site has always been a trainwreck, and now the customer service that matches it is becoming more apparent to the wider database.
casually awaits 'random mistaken banning for "DDOS attacking" through normal use'
