| SitePoint Sponsor |
Hi.
How can I make my app fast and it should be able to bear 50,000+ hits per day!
Need to know main points to achieve this goal...
/***********************************************/
Sometimes, an application is working fine. Bust as the load increase on the application i.e. the number of users accessing the site increases upto several thousands per day, it crashes....
What are the reasons for such crashes....
[COLOR=SlateGray]
Web Developer @ VeriQual
The basic recipe is this: 1) Write the program so it does what it should do. 2) Put it under stress and measure where the slow parts are. 3) Apply optimisation to these places. 4) Measure again and see if the optimisation worked. 5) Test that the application still works. 6) Repeat from 2.
To help with 2, you can use apache-bench, xdebug and either kCacheGrind or WinCacheGrind (If you use Windows, the latter is probably easier).
To help with 1 + 5, you can use unit-testing.
“Almost all programming can be viewed as an exercise in caching.” - Terje Mathisen
This is even more so for performance related problems.
Design patterns: trying to do Smalltalk in Java.
I blog too, you know.
install php APC extension, 50,000 hits is nothing
Not a bad idea!Originally Posted by ionix5891
Wots PHP APC,??
Where can I get this..
[COLOR=SlateGray]
Web Developer @ VeriQual
Also, instead of installing APC without a second thought, I would recommend first following the Kyber's instructions to to pinpoint the exact bottlenecks that are slowing down your application. A cache system like APC can solve only a certain type of bottleneck and that bottleneck may or may not exist in your application. it could be faulty or weak hardware, inefficient or redundant queries, anything...
^^ i concur
if your code is rubbish to begin with APC wont help much but it is the easiest optimization to add, also make sure you have the very latest php version and i also when compiling php ensure extensions i know i wont use are not compiled/configured
I can highly recommend xdebug + kcachegrind, I usually leave xdebug dumping profiling data for the whole site into a single file, then towards the end of the week load it up in kcachegrind and review the various different measurements, graphs etc..
You run a profiler on your production site? I wouldn't recommend that practise; It takes a lot of performance, not to mention disk space.
This has been my experience:
1) Determine which pages get the majority of requests - start optimizing those ones first (server logs, analytics stats etc.)
2) Cache, cache, cache!!
3) Optimize database related stuff - slow queries, indexes, table types etc.
4) Server infrastructure configuration - httpd.conf, my.conf etc.
5) Server infrastructure hardware - once you've exhausted the above, you will have to look at your actual server hardware. eg. go from virtual to dedicated host, upgrade to more powerful server hardware, migrate to a multi-server environment etc.
6) Sandboxing application functionality onto different servers. Eg. if your app has a high db load and serves a lot of images, move image serving to a separate server (images.yourapp.com) and move the database to it's own separate db or replicated across different machines etc.
#5 and #6 are usually a last resort once you've squeezed as much as you can out of the other items.
I wouldn't recommend it as a standard practise, but sometimes there's no alternative due to usage patterns that might only affect that particular instance, so doing something like this for a few days can be worth the pain.
Some cache techniques:
Browser site: Once a file is downloaded it remains in the browser cache until a newer version is available on the server. It can be achieved by sending the correct HTTP headers.
Server site: Save the output in a file. When the URL is requested the second time, deliver the cached file. In this way there's almost now work for PHP to do and database queries could be avoided. It it also possible to save a serialized object in a file.
Database: Cache the queries and the results. See MySQL query cache for example.
No, just in the development environment and for unit tests so I can get better in-depth measurements of overall performance rather than just guessing.
Posting Permissions
Bookmarks