Close
Both.

When SPDY is enabled in Firefox downloads start at ~100KB/s and max out at ~600KB/s after a few seconds. Browsing pages when this occurs causes thumbnails to load one by one delayed.

When SPDY is disabled in Firefox start out at ~300KB/s and max out at ~1024KByte/s after a few seconds. Thumbnails load one by one delayed.

Normally, downloads start at ~2000KB/s and almost instantly jumps to 4000~6000KB/s near the limit of my 50Mbit connection. Thumbnails load instantly.
Pool zips are not handled via ssl/spdy due to a bug in streaming zips, so I don't think its worth testing.

I have a feeling spdy is adding a lot of connection overhead. I've turned off max connection limiting on everything except on pool zips.
Not seeing any improvement.

Single image download (SPDY enabled):
~600KB/s max speed.

Single image download (SPDY disabled):
~1100KB/s max speed.

Three simultaneous images downloads (SPDY enabled):
~1100KB/s combined speed

Three simultaneous images downloads (SPDY disabled):
~2400KB/s combined speed

The slower than normal speed with SPDY disabled could be explained by something else. It seems my ping to yand.re is now 26ms compared to 13ms from the tracert results posted the last month. If this is causing speed issues, it must be recent, since everything was normal last week.

Last month:
tracert to yande.re
<1 ms | 192.168.1.254
<1 ms | ftth.swbr.surewest.net
<1 ms | 172.22.5.13
<1 ms | 172.21.2.13
<1 ms | 172.21.0.250
4 ms | sjo-bb1-link.telia.net [213.248.88.73]
4 ms | xe-1-3-0.sjc10.ip4.tinet.net [173.241.128.109]
13 ms | xe-2-2-0.lax30.ip4.tinet.net [89.149.180.250]
13 ms | as29761.gw.ip4.tinet.net [199.168.63.78]
13 ms | 96.44.180.2.internal.quadranet.com [96.44.180.2]
13 ms | yande.re [72.11.139.2]

Now:
tracert to yande.re
<1 ms | 192.168.1.254
<1 ms | ftth.swbr.surewest.net
<1 ms | 172.22.5.13
<1 ms | 172.21.2.13
<1 ms | 172.21.0.250
4 ms | sjo-bb1-link.telia.net [213.248.88.73]
4 ms | xe-1-3-0.sjc10.ip4.tinet.net [173.241.128.109]
26 ms | xe-2-2-0.lax30.ip4.tinet.net [89.149.180.250]
26 ms | as29761.gw.ip4.tinet.net [199.168.63.78]
26 ms | 96.44.180.2.internal.quadranet.com [96.44.180.2]
26 ms | yande.re [72.11.139.2]

The Tinet backbone which Quadranet uses seems like they may be having (capacity?) issues at their LAX router. Separate issue, but maybe something you could file a ticket with your host about.
Thanks for the detailed data.

I'm not going to open a ticket to provider unless more people report slowness.

In the mean time I'm putting the connection limits back in and see how well it does over night. No one else has complained yet on social networks either.
Time for a double post.

I've re-enabled anti bot stuff, hopefully its less false positives.
Killed spdy, will wait for more patches.
admin2, could do a trace route from the yande.re server to my ISP's gateway?

I'd be curious if outbound traffic from your server to my ISP is actually traveling over a different backbone than Tinet<->Telia, and you see high latency or loss on one of my ISPs other primary backbones (Level3, GlobalCrossing, Sprintlink).

I ran a Wireshark trace from my end and I didn't see anything particularity abnormal. Whatever it is, it's affecting the entire Quadranet's LA datacenter, as I'm seeing a similar download rate from their speed test.
Both tracert and download speed seem back to normal today and match your result of 15ms, so Tinet must have resolved the issue:

tracert to yande.re
<1 ms | 192.168.1.254
<1 ms | ftth.swbr.surewest.net
<1 ms | 172.22.5.13
<1 ms | 172.21.2.13
<1 ms | 172.21.0.250
4 ms | sjo-bb1-link.telia.net [213.248.88.73]
4 ms | xe-1-3-0.sjc10.ip4.tinet.net [173.241.128.109]
15 ms | xe-2-2-0.lax30.ip4.tinet.net [89.149.180.250]
15 ms | as29761.gw.ip4.tinet.net [199.168.63.78]
15 ms | 96.44.180.2.internal.quadranet.com [96.44.180.2]
15 ms | yande.re [72.11.139.2]

[Edit 2/20: And now it's back to 13ms again]

Single Original Images now once again download my connection limit of 50Mbps.

I guess it was just bad timing that you enabled SPDY on the same day as a backbone issue. Though this does seem to exhibit that SPDY has a horrible overhead under poor network conditions.
I've changed the tag sorting for index page again.
edogawaconan said:
I've changed the tag sorting for index page again.
The tag order for individual posts seems to be random instead of alphabetical now. post #244120

Edit: Appears to be fixed now.
SPDY's been enabled for 12+ hours and I haven't seen a problem. Anyone notice any oddities?
Well I just re-enabled SPDY in Firefox (had it explicitly disabled since last time).

Initial impressions: Downloads are not smooth.

Overall speed seems fine, but SPDY causes spikes of very_slow->fast_burst->very_slow->fast_burst per image download, when downloading multiple images.

It doesn't seem to do a good job of balancing available speed over multiple downloads. Most likely just a limitation of this SPDY v2 implementation. Instead of streaming packets of multiple image downloads concurrently, it instead seems to alternate exclusive use of the SPDY connection every half-second or so.

Impression #2: Thumbnails and other pages load slightly out-of-sync and a split-second slower with SPDY enabled. (vs HTTP pipelining)
I agree, thumbnails are noticeably slower and do load out of order. Actual image download speed seems slower as well. All of this is nightly x64, no idea about anything else.
Busy as hell due to work.

I probably use the site much differently from everyone as I only see a problem with the thumbs loading out of order, but after the initial preload its fine (we load two pages of thumbs ahead).

It seems stable enough, but I'll turn it off on Monday.
admin2 said:
It seems stable enough, but I'll turn it off on Monday.
I'd consider this latest implementation "stable enough" as well, with what I listed above more nitpicking than anything else.

The real question is, has SPDY helped reduce server load in any significant way, without reducing average/maximum network throughput? Assuming you are using the finalized SPDYv2 support included in stable ngnix, I'd say to leave it enabled as long as needed to generate enough graph data to make a conclusion about that aspect.
It made zero difference and people are saying weird things on twitter saying they can't load stuff so I'll just blame that..
Cloudflare's enabled again. I turned off anti hotlinking so redirects won't get cached. There's already some issues I see, but would like to know if there's others.
forgot to update, cloudflare's disabled again~

I've been messing with robots.txt let me know if your rss reader is having problems with it.
stripped thumbs across some new subdomains, might cause thumbs to load out of order but if you have a higher limit set it'll load faster.
Adding 32gb of ram to the server on Tuesday, this will bump the server up to 60gb.

It was expensive, I might ask for donations.
I enabled SPDY again see how it plays across multiple subdomains.
upgraded to rails 4, if you see bugs please post about it.
A few minutes ago, I was experiencing random extremely long delays loading pages and others stalling completely. Though now it seems fine again, so no idea what was going on. [Firefox 22.0]
Cyberbeing said:
A few minutes ago, I was experiencing random extremely long delays loading pages and others stalling completely. Though now it seems fine again, so no idea what was going on. [Firefox 22.0]
Networking issues, its effecting the colo guessing a ddos
PM Preview Option problem
Hey admin2.
I'm having a little problem with the Preview option.

I see now that it works for the comments but I was just PMing someone and when I clicked "Preview" this showed up at the bottom:

Login

You need an account to access some parts of yande.re. Click here to reset your password.
Name
Password
Login

When I do provide them, I get this.

(It's a good thing I did a backup of all that writing I was doing.)
I go back to Re-PM the person, copy and paste the backup message, and clicked Preview again (thinking it was just a mistake) and it asked for login details again. I didn't provide it this time and I just send the message.
The message was sent successfully.

Now this isn't a big deal or anything but I want to ask, did something most recent happened like a change or what?
Up above doesn't seem to relate to this.
I can "Preview" on the comments such as here but PMs is a different thing.
fixed in trunk, will be deployed ~soon~
I can use it without that little error now.
Thanks admin2.
automated banning script is more aggressive now, hope I don't trigger false positives...there's been a massive amount of abuse that's been effecting over things hosted on the machine.