Shitcourse has gotten extremely slow?
-
So normally everything has been smooth for me on Chrome on Windows.
Now its fucktastically slow.
Click the notification icon?
50 seconds to load and display the box.
Load a post?
Maybe in a day from now.
Edit a post?
Wait, we were loading?
It appears its the server struggling for some reason but the behavior of the client is just so abnormal.
I don't even understand the notification box, I thought the stupid thing was being spam polled for the notifications and thus the client should already have it.
-
if it is not the import that is going on, it is probably my fault.
I have been testing a ddos on one of the json resources.
-
I have been testing a ddos on one of the json resources.
Why here? Why not on a test site?
-
are you serious?
this is a testing site isn't it?
-
-
I am not sure it was my testing,
-
It was light testing 10 simple simultaneous GET requests to /about.json
-
It only affects this site, some database deficiency is my assmopsion
-
-
-
- It was light testing 10 simple simultaneous GET requests to /about.json
Uicoderss can handle 10 simultaneous GETs, surely?
-
But can the database handle 10 simultaneous
SELECT count(*) FROM posts JOIN /* public post filters */
during inserts?Can the server handle hashing 10 simultaneous 20kb password hashings? that was a funny bug report. "potential DoS with 20 kilobyte passwords"
-
Ooh, passwords is an interesting one, because you do want a minimum bound of the amount of computation the hashing takes... but would it actually accept a โฅ20,000 character-long password?
-
We'd call them out on it if it didn't.
-
The most secure passwords are a megabyte of random unicode characters.
-
You'd probably need a few Post-It notes to write it down on though.
-
Not anymore
Discourse fails out early if you give it a password > 200 characters.
-
That seems reasonable...
-
Why not a nice round number like 255?
-
How many bits of entropy do you really need? Really?
-
Discourse fails out early if you give it a password > 200 characters.
well.... that's it i can't log in any more.....
i mean i could reset my password but where's the fun in that?
-
Discourse fails out early if you give it a password > 200 characters.
In all seriousness, does anyone use a password that long?
-
@accalia, apparently?
-
Ah, but then you have to work out whether she's really doing so, or just being mischievous ;)
-
-
I believe mischievous is a given?
-
i have a long one, but it's not that long
it's like 80 characters
-
-
-
-
y'all are very weird people.....
-
Just trying to make you feel welcome.
-
-
-
#ALL OF THEM!
-
-
If your password is in a font, you're doing it wrong.
-
-
In which font?
Really?
A quick google shows that either should be fine, but IMO what seems better, since it's not a selection from a list of possibilities, but about identifying any possible choice.
(Any
pe(n)dantsexperts care to share their opinion?)
-
it's not a selection from a list of possibilities
Are you suggesting there's an infinite continuum of fonts?
-
Are you suggesting there's an infinite continuum of fonts?
At least if you include font size in the definition of a font, then yes. (Well, maybe not a continuum, but >= โตโ.</pedantry>)
-
If you can list all the fonts that will ever exist, I'll believe there are a finite number of fonts.
-
The most secure passwords are a megabyte of random unicode characters.
Is that more secure than a megabyte of random bytes?
-
What material are the bytes made out of? I could see steel bytes being much more secure than woolen ones, for example.
-
What material are the bytes made out of? I could see steel bytes being much more secure than woolen ones, for example.
True, but the steel ones are going to be much more difficult to work with. You don't want to byte off more than you can chew.
-
Well, I'd be worried about the megabyte of random bytes getting mangled by systems that expect a certain encoding for forms. That's why I said unicode and not bytes. If you somehow managed to make UTF-31, that'd be pretty much the same thing.
-
gzip has taken out one CPU here out of the 2 ... 100% usage gzipping the backup...
-
it's like 80 characters
I have one of similar length, but not for WTDWTF; nothing I do here, or most anywhere else, needs that kind of security.
-
3 fucking hours of cpu time compressing shit ... disabling backups while this is debugged ... also @zogstrip we gonna have to stop using gzip --best ... its just toooo slow, changing that right now.
-
note, all ... we are not using tar with the compression options cause we tend to use
tar --append
-
ok, I hot patched the code here with:
It made an enormous difference the gzip phase of the backup is only taking a couple minutes to compress the 7GB it needs to compress (as opposed to 3 plus hours)
there is still some pg tuning I need to apply to improve perf which I will look at re-applying now.
-
I applied some PG tuning that was missing post server move. Lets see how this plays out. cc @apapadimoulis @PJH
-
Thanks, @sam!
-
If you can list all the fonts that will ever exist, I'll believe there are a finite number of fonts.
Your conditional is valid, but the pre-condition fails. Fractional font sizes exist, so an infinite number of font sizes are axiomatically possible.