Page 1 of 1
Need help with experience on design (short q)
Posted: Fri Feb 05, 2010 9:57 am
by dev_php_11
I'm looking to design a stock simulator, capable of handling thousands of users simultaneously. I'm not asking "how to build it" but looking behind the design portion to see if I need a framework (so far Kohana looks the best I think), if I should use javascript or some other sort of client side processing, and if I will be able to handle all the users once on a standard server.
I realize that this is more of a "learn as you work on other projects" aspect, however I am on a time crunch, have previous knowledge of c++ on non-networking projects, and need to figure the best path to dedicate my time and resources to.
Thanks.
Re: Need help with experience on design (short q)
Posted: Fri Feb 05, 2010 1:46 pm
by tr0gd0rr
Don't build a php app without a framework.
I believe the network limit of a web server is a little less than 10,000 simultaneous requests (10,000 ports on a server). If users spend an average of 60 seconds per page and each request took 1s to process I guess that would be about 600,000 simultaneous logged-in users without making users wait. For a few thousand users, you probably don't even need a cluster of servers--just one decent server. When the site grows and pages start to feel slow, then get a better setup.
JavaScript can greatly enhance user experience. My advice is to make the entire site work without javascript, then add enhancements later. For example, modal boxes, refreshing part of page and instant calculations are helpful but not necessary. You can use a meta refresh tag for auto save or auto update, for example.
Besides, you may have to cater to users who have javascript disabled. Or a mobile version with no javascript to make things faster.
Re: Need help with experience on design (short q)
Posted: Sat Feb 06, 2010 8:11 am
by inghamn
Frameworks exist to save you time during development - and - to give good suggestions as to how to organize all your code.
They will not make your stuff run faster. When a user sends a request, there's going to be a lot of code that runs, written by the framework authors, that adds to the processing time. The tradeoff is well worth it, though.
Realistically, you'll probably end up with processing time per page request hovering around 0.1 to 0.3 seconds, using one of the popular frameworks. That's without any optimizations or caching. You are not going to be handling even 10 simultaneous page requests at launch.
When, and if, you do start handling more traffic, the popular frameworks describe ways to optimize and scale as needed. If you stick to good ways of organizing and writing your code, the scaling and optimizing will be easy to do when needed.
All that being said, it's not a bad idea to keep an eye on per page process time. When I end up creating a page that takes 1 or more seconds of process time, it usually is worth rethinking what you're doing on that page. Are you displaying a bunch of data that should be paginated? Are your database queries really slow and need indexing? For my stuff, my threshold for starting to worry about performance of a single page is around 1.5 seconds, during development.
Just remember that the most important time measurement is how long it takes you to build and modify the site. Not how long it takes the server to run each page request.