4 ms·
Ask HN: hackernews coders have experience with high traffic web apps?
I am working on a start up, and I would like to lay a reasonable foundation for scaling. My theory has always been, if I need to scale, I'll be in a good position and that is a good problem to have, however I have some time and would like to at least do a decent job preparing for the possibility of higher growth and expansion.<p>I'm not a whiz at this, so wanted to see if there were any engineers out there that had experience in this that would impart some wisdom for a week or so, in exchange I can provide graphic design services.
- jjoe 16y agoHi Riskish, My team and I deal with high traffic portals on a daily basis (as a hosting business). I'll be happy to listen, understand, and share with you ways to scale. Feel free to get in touch. Regards Joe
- iuguy 16y agoWorry about scaling when you can afford it. Many successful startups go through a transitioning stage but not all do. When icanhazcheezburger was launched it was a mix of PHP and .NET - oil and water. It still is!
- moge 16y agogoogle James Golick http://jamesgolick.com/ http://jamesgolick.com/ He has some amazing conference lectures about how he scaled his 1.5million page view website.
- brk 16y agoI've got a good bit of first-hand experience with this. The right answer depends a lot on the app and architecture. Do you have to maintain state/session over a long period of time? Can requests be load-balanced across different web servers or do they need to stay with the originating server? How much content can be static? How long can the data be cached for? Will there be high-demand customers or topics/trends? (eg: think of how Twitter has dedicated Justin Bieber servers) Will the traffic be bursty or climb steadily? Is there a need for comments or user input to show up in real time? Does the content mostly come from users, or from some structured input on your end? Does the site architecture lend itself to elastic scaling (either from your own standby machines, or EC2 style servers)? These are just some things to think about.
- davidjairala 16y agoMy advice would be: Cache everything you can, especially expensive code sections. Move everything that doesn't have to update immediately to cron jobs. Whenever you can, load information on demand. Try to think before-hand about the nature of your app, specifically, is it write heavy, read heavy or code heavy? Map out a scenario of what you need to scale first, and what isn't as important to scale, for example, would you need more app servers or db servers? Load balance if at all possible.
- stephenou 16y agoMy advice is not to worry about scalability at this point. You can't really predict when and where your startup is going to gain popularity. Focus more on building a solid product, launch it, and you know what directions you are heading toward. Imagine you waste 2 months of scaling your website that is only getting 100 users. I've experienced this before. Tears after all.
- riskish 16y agostephenou,I'm aware of this short-sight. However, I am building a start up and putting a lot of resources into it. I do not want to plan for scale, per se, but I wanted to see if there were rough points I could actually keep in mind when developing, as opposed to just building a prototype. I'm used to use hacking things together with php and mysql, so I wanted to try to be a little more formal this time around.
- user24 16y agountil you have users, how do you know which parts of your app are going to be the bottlenecks?
- riskish 16y agotrue. whenever Im building, (I know php and mysql), I always can get stuff to work, and make it work decently well, but i'm never sure if i'm doing stuff properly. I barely ever create OOP functions and hierarchies, etc. Does anyone else ever feel this way?
- nl 16y agoHere's a few very rough tips: 1) Keep things as simple as possible. That means, for example, try and avoid database joins where-ever you can. Doing that would mean that in the future it's much easier to shard your databases and/or move to a different (eg, different database or NoSQL) solution. 2) Keep things stateless. State is always hard to scale. 3) Become an expert in tuning your database. Learn how to analyze queries and to create sensible indexes.