SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.
SoylentNews
Right, so there's currently a DDoS of our site specifically happening. Part of me is mildly annoyed, part of me is proud that we're worth DDoS-ing now. Since it's only slowing us down a bit and not actually shutting us down, I'm half tempted to just let them run their botnet time out. I suppose we should tweak the firewall a bit though. Sigh, I hate working on weekends.
Update: Okay, that appears to have mitigated it; the site's functional at a reasonable rate of responsiveness.
Update2: Attack's over for now. You may go about your business.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
QOTD:
"My life is a soap opera, but who gets the movie rights?"
(Score: 3, Informative) by NCommander on Monday October 31 2016, @05:03AM
Slashcode actually originally had this functionality. The database and themes were essentially exported as HTML files and served up to ACs; only accessing the .pl files directly (which happened when logged in) would give you a real-time view (this is what the original "delay in updating static page" meant when you post on the site). Due to coderot, and the fact that generating and syncing this HTML across multiple web frontends was a massive headache, we eventually just migrated everything to using varnish and put a bullet in the static content generation (most of the code is still there but disabled).
One thing that constantly drives me up a wall though is poor use of existing tools. Originally, this site used memcached as a hotcache, and standard MySQL for backend storage, which lead to an entire class of bugs where the two would disagree with each other and occasionally blow crap up. While memcached is very good at what it does, it adds a massive layer of complexity as you essentially have to map structed data to KV pairs, and deal with dirty reads. We had a lot of pain in the earlier days of the site because of this because memcached isn't a distributed datastore, the assumption is you have a central "cache" and then introduce network latency to the mix which actually tends to cause performance to go down the crapper. We got around this by running memcached on each web frontend, but the dirty read problem got a lot worse because now different parts of the stack might have different ideas on what the current state of everything was.
The entire problem got solved by moving everything to MySQL cluster which allowed for in-memory/disk-based durability for CP important data such as posts, stories, and user data. Cluster is amazing for high read performance and allows for easy multi-master operation; data is cached in the frontend mysqld cluster instances, and data is stored in the NDB instance backing it. If we needed even better performance, we'd likely migrate things like templates, statistics and such from MySQL to an AP datastore like Cassandra which is ideal for these sorts of cases where the data is non-essential, but very useful to have "at hand" (I know TMB has experimented with Redis, but I don't think it made it to production). Even without cluster, it would have been possible to use MySQL MEMORY tables as a hotcache backed to InnoDB ones to get the same effect (and we will likely have to do something similar with NDB in the future).
What always staggers me is people praising things like Postgres, but when I look at their code, its basically being used a dumb store with no concept of using FORIEGN KEYS, or stored procedures, or anything that their DB is *good* at, and instead reinventing the wheel.
Still always moving