0
1

Voat -- Not a scalable design (self.Voat)

robpolak が 投稿

GitHub : https://github.com/voat/voat

I was very interested in Voat, like any programmer I decided to look at the underlying technology. I was pretty shocked at what I saw.. This entire site is built upon a pretty shaky infrastructure, and it WILL have scalability issues moving forward. I highly urge people be very careful before tossing any money into this platform until they have a plan to resolve these issues.

A little about me, I am a passionate technologist who has been programming for many years (about 18 years). I have worked in major IT shops, including a very prominent web company. I have experience in both writing large enterprise systems as well as highly scalable web implementations.

Here are the issues I have with Voat..

  1. .Net - I was a .net developer for about 10 years of my career, there are things I absolutely love and hate about .net. When it comes down to it .net works very well at some tasks and horrendous at other. Microsoft has fallen very far behind in the web world. They spent more time dedicated to silverlight and WPF and fell far behind on the initial web boom. While MVC4-5 is a huge step forward, there are so many other frameworks out there that will outperform in almost all cases. The major problem with .Net is going to be scalability. I worked for a company whose website was entirely built on .net and would see about 17k-20k concurrent users @ 2M unique page views a day. Even at that level we ran into major scalability issues.. mainly the amount of hardware we needed to push to meet load requirements. We ended up needing about 100 servers to maintain decent response times. My major beef with .net is that it does not scale gracefully.

  2. Entity Framework - This framework is bloat and will always be bloat. Create an EF query with a few complex joins and you will see where the framework falls short. A site built to scale at this level should have hardened SQL queries that can be performance tuned. This also leads me to believe no performance tuning is being done on the SQL server side. I have operated SQL Server databases that got into the 1TB-2TB range and we had to do significant performance tuning to make it operate successfully. I can see based on your SQL queries you have not factored this in at all. For example, I would expect to have seen partition keys in your queries and models.

  3. SQL Server - (based on your raw SQL I am assuming SQL Server and not MYSQL).. I love SQL Server and it is great in the enterprise world.. However, with the vast number of databases choices out there I really struggle with why SQL Server would win for this implementation. MongoDB/Cassandra/MYSQL being on the top of that list for me, and all would have gave you better performance.

  4. Code Quality - The code quality is pretty atrocious and I would have never let code of this quality touch a production system. You have controllers that interact with the database, you have no level of abstractions (read Dependency Injection).

  5. Caching - I was very shocked that there was no layer of caching besides simple .net caching. In the world of scalable websites the less you interact with the database the better your front end performance is going to be. Having a scalable caching platform like redis to store highly cacheable data is critical.

Honestly, I am not trying to beat up on Voat, however there is no way this system will scale unless you throw a HUGE amount of server capacity at it (at a very large cost). I would be very cautious sinking any money into this platform until they can address some of these major issues.

全 24 件のコメント
並べ替え:
ベスト
トップ新着論争中古い順Q&A

[–]waterboardspecialist 16ポイント17ポイント  (4子コメント)

A few of the things OP wrote about are so blatantly wrong I felt compelled to create an account to correct them.

They spent more time dedicated to silverlight and WPF and fell far behind on the initial web boom.

I guess you were a .NET developer in the dark ages. This statement is no longer true as .NET has overtaken virtually everything unless you're building Amazon or Google.

While MVC4-5 is a huge step forward

These were actually huge steps backwards. MVC was where Microsoft tried to compete with other web frameworks a decade ago and while MVC structure is obviously still around, it really shouldn't be because it's utter shit.

It's utter shit because it doesn't have a Repository layer - I know most MVC frameworks corrected this by, you know, adding a Repository layer breaking the design pattern. But that wasn't really the worst part. The View bit is where it gets really fucking terrible and is ultimately why nobody who wants a future in webdevelopment should be doing MVC frameworks.

Microsoft either out of sheer luck or absolute genius included the WEB-API in their MVC framework. In the modern world of Single Page Applications Web API is the best server side platform to put behind your javascript, htlm5 and css3 front.

Entity Framework

I'll absolutely agree with you here. Entity is terrible.

Code Quality

I haven't bothered to look i through, but if controllers are interacting directly with the database it's utter shit.

Caching

I don't think this is a major worry in an open source project on the .NET platform as it'll be relatively easy to implement later on through the .NET ecosystem.

[–]robpolak[S] -5ポイント-4ポイント  (3子コメント)

I guess you were a .NET developer in the dark ages. This statement is no longer true as .NET has overtaken virtually everything unless you're building Amazon or Google.

I really cannot understand your logic here.. name any top internet site that runs on .net, there are virtually none. I however, did work at one large company whose .net platform ran for 10+ years (~20k-30k concurrent users). I have seen first hand the issues with everything .net/windows related. There are so many better systems available today .. Node/Go/Rails/etc...

These were actually huge steps backwards. MVC was where Microsoft tried to compete with other web frameworks a decade ago and while MVC structure is obviously still around, it really shouldn't be because it's utter shit. It's utter shit because it doesn't have a Repository layer - I know most MVC frameworks corrected this by, you know, adding a Repository layer breaking the design pattern. But that wasn't really the worst part. The View bit is where it gets really fucking terrible and is ultimately why nobody who wants a future in webdevelopment should be doing MVC frameworks. Microsoft either out of sheer luck or absolute genius included the WEB-API in their MVC framework. In the modern world of Single Page Applications Web API is the best server side platform to put behind your javascript, htlm5 and css3 front.

Again this makes no sense, every implementation of MVC I have created implemented a Repository patten. The MVC project should have no knowledge of the repository in general, that would actually be an Anti-Pattern.

[–]TankorSmash 4ポイント5ポイント  (1子コメント)

SurveyMonkey used to use a lot of .NET and they're huge.

[–]Bliss86 4ポイント5ポイント  (0子コメント)

StackOverflow itself was build in .net, as was PlentyOfFish.

[–]kimtranjan 4ポイント5ポイント  (0子コメント)

Seriously? How about StackOverflow? It's amazing scalable.

[–]Nishruu 15ポイント16ポイント  (1子コメント)

.NET as a stack

I guess whole Stack Exchange would disagree, and their setup is nothing too hardcore for their scale

EF

Again, as an example StackExchange/StackOverflow uses Linq 2 SQL for parts that are not performance sensitive. I'd say they're good with EF (with a little bit of warmup, query precompiling etc) in less frequented parts and use any micro-ORM of choice for the hot path, both options can easily coexist in one project.

SQL Server

MySQL as a 'better' alternative? Seriously? I mean, come on

Other than that, I'd say that choosing a relational database is the right choice, then you can add more stuff if there's a clear, proven need for it. Even reddit (AFAIK) uses Postgres for most data.

Code Quality

Can't comment, I haven't checked it out, but it might be a valid concern.

Caching

I guess YAGNI applies here - their traffic might not have warranted any kind of cache at least so far. Anyway, in my opinion and experience adding Redis to the stack for persistent cache and as a 'data structure server' is not a hard thing to do if it's required.

[–]Rikkety 5ポイント6ポイント  (0子コメント)

I wrote a similar critique in /r/programming, nice to see I don't have to repeat it her.

[–]CoreProc 6ポイント7ポイント  (0子コメント)

You have to remember that he was simply experimenting on the idea of reproducing Reddit in Dot Net FOR FUN and then finally it just go boom when Reddit Exodus arrives.

I will say Voat would need to keep using commercial DB, not crappy database like MySQL. As for .Net not scaling, I would say it isn't managed correctly, because I am seeing 50,000 concurrent users per server from my end. You're saying Voat coding quality is atrocious? I've seen code far worse than anything you've seen then.

Quit being a drama queen.

[–]MagnarHD 4ポイント5ポイント  (1子コメント)

Perhaps provide this feedback on Voat directly, where Atko may see it.

[–]ivquatch 4ポイント5ポイント  (0子コメント)

Feel bad for the guy. One day, your site's humming along with a modest amount of traffic, and the next day /r/programming's armchair CTOs are ripping your architecture a new one because it's not reddit-scale. Ultimately a good problem to have, I guess.

[–]TotesMessenger 3ポイント4ポイント  (0子コメント)

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)

[–]pig-newtons 0ポイント1ポイント  (0子コメント)

I'm assuming it is more of a hobby so I won't be too critical but I do think using .Net was a mistake.

I'm guessing it's the language he knows which is entirely fine then for a hobby / experiment but anytime someone uses Java or .Net for their website I think they're just making their lives harder. For services that do heavy lifting that's fine but no so much for the front-end.

[–]sketerpot 0ポイント1ポイント  (0子コメント)

My major beef with .net is that it does not scale gracefully.

When you say that it doesn't scale, what do you mean by that? Where, specifically, is the bottleneck?

[–]Burtonium 0ポイント1ポイント  (6子コメント)

I'm a software programmer that's not too savvy on the web part. What would a TODO list fixing these issues look like?

[–]ivquatch 3ポイント4ポイント  (1子コメント)

Alternate view. I would most certainly get rid of the ORM in favor of straight SQL. Longer term, I would strongly consider denormalizing the data for performance and using a non-relational data store for scale.

It would probably be worth while to look into precomputing and caching commonly used data.

Unlike OP, I disagree that .NET is a liability. MVC is plenty fast and the web-tier could be build to scale horizontally the same as would using any other web stack. All the compute/IO-heavy operations should be done asynchronously on the back-end, so the front-end doesn't need to be blazing fast -- just responsive. You'd probably do quite well with standard HTTP caching and request throttling.

Also, I think a SPA-style font-end would be ridiculous for a reddit clone. For starters, you're just making it difficult for search engines to index your site. Secondly, perhaps I'm old-school but I think unless your application has a lot of complex UI state, a reactive framework like angular doesn't do you much good.

SPAs are brittle and an unhandled javascript exception could tank your site. They also take a long time to start-up because the thick javascript client app needs to be downloaded and parsed. It's better to sprinkle some jQuery on server-generated HTML and let the browser do what it's good at: render HTML. Let the server be your engine of application state. If your HTML and other assets are mostly static, you can slap them on a CDN for maximum performance.

So, there's no need to blow-up Vote.co just yet. There are plenty of things that can be done to improve performance using the existing code. They're just in the unfortunate position of having to scale up very quickly and very publicly, so they'll have to optimize more than just the low-hanging fruit.

[–]robpolak[S] 0ポイント1ポイント  (0子コメント)

Unlike OP, I disagree that .NET is a liability. MVC is plenty fast and the web-tier could be build to scale horizontally the same as would using any other web stack. All the compute/IO-heavy operations should be done asynchronously on the back-end, so the front-end doesn't need to be blazing fast -- just responsive. You'd probably do quite well with standard HTTP caching and request throttling.

It is less that .net is a liability it is that windows/IIS is a liability. It is not even that I think it cannot be done, however, it is much easier to accomplish in the unix world. For example, to get quick scalability I can deploy my entire application into one or many docker containers and setup seamless deployments to as many servers as I want. There is no alternative in the windows world, if you want scalability you get involved in messy powershell scripting to make it happen. Again, it can be done, however, why make your life hard.

[–]robpolak[S] -1ポイント0ポイント  (3子コメント)

That is a really hard call as they are so far along on the .net Stack. Honestly I think their biggest issue is going to be data volume and latency times getting it out of the database. They will also be very susceptible to DDOS attacks with their current design (as you can just directly DDOS the database quite easily).

If I needed to right the ship without killing of the entire system I would say..

Step 1. Rewrite Controllers so that they are doing way less.. create a data services tier so you can abstract the data model from front-end logic.

Step 2. Once you have full separation between controllers and data start moving toward a scalable data platform. I think you could make Mongo work (data relationships get a little tricky). MYSQL would be the defacto go-to for a true relational DB.

Step 3. Caching.. cache EVERYTHING (where possible). This will help site performance as well as DDOS mitigation. ..edit.. especially look at doing static caches of pages as well as using a resource CDN (i.e. Akamai).

Step 4. Move toward a MVC model on the UI end (angular/react or one of the other variants).

If I had the opportunity to nuke the project I would love to do a POC with Node.js/(MongoDB || CASSANDRA) with angular.

[–]Nishruu 8ポイント9ポイント  (2子コメント)

MYSQL would be the defacto go-to for a true relational DB.

If I had the opportunity to nuke the project I would love to do a POC with Node.js/(MongoDB || CASSANDRA)

My Poe's Law/troll meter is going off the charts...

[–]physguy1123 3ポイント4ポイント  (1子コメント)

Dude Node+Mongo is webscale it's what all the cool startups use.

[–]professorlamp 1ポイント2ポイント  (0子コメント)

When I looked at the js on their github it made my testicles inverted. So much duplication of code. Don't believe me? Check out the following functions on their github and you too will know what not to do!

voteUpSubmission
voteDownSubmission
voteUpComment
voteDownComment
and a few others further down that file

[–]milesrout -1ポイント0ポイント  (0子コメント)

What's pretty stupid is that reddit is already open source.

[–]ianp -2ポイント-1ポイント  (1子コメント)

To me the biggest concern is the lack of abstraction and all of the baked in dependencies.

If they could change one thing immediately, their priority should be to implement DI and then they could solve their other problems fairly easily, one by one.

[–]ivquatch 1ポイント2ポイント  (0子コメント)

DI generally improves testability and maintainability. It's not going to do shit to enhance performance, which is what the site needs.