site speed
some quick suggestions:
1) looks like everything's been ported to PHP (nice work). if that's the case, suggest you roll a new compile of Apache without mod_perl. this will dramatically reduce the size of the binary. if not, suggest you port all remaining and then re-compile (grin).
2) can't see any reason for the SSL stuff top be compiled in either. did i miss something? in general, suggest you compile in only the modules that are needed.
3) don't know how the server is tuned, but suggest careful reading of the following docs:
http://httpd.apache.org/docs/misc/perf-tuning.html
http://httpd.apache.org/docs/misc/perf.html
4) if you're not using Zend Optimizer, suggest you at least evaluate it for use. in general, tracking stuff on the Zend site (http://www.zend.com/) will prove worthwhile.
5) don't know which database you're using, but of course a profiler will show that's the bottleneck so tuning the database (and choosing the right database) and optimizing the system the database runs on yield the best results most of the time.
6) don't run reports or anything interactive on the live server (grin).
forgive me if all or any of this is obvious to you. just trying to share some (hard earned) lessons.
-c
1) looks like everything's been ported to PHP (nice work). if that's the case, suggest you roll a new compile of Apache without mod_perl. this will dramatically reduce the size of the binary. if not, suggest you port all remaining and then re-compile (grin).
2) can't see any reason for the SSL stuff top be compiled in either. did i miss something? in general, suggest you compile in only the modules that are needed.
3) don't know how the server is tuned, but suggest careful reading of the following docs:
http://httpd.apache.org/docs/misc/perf-tuning.html
http://httpd.apache.org/docs/misc/perf.html
4) if you're not using Zend Optimizer, suggest you at least evaluate it for use. in general, tracking stuff on the Zend site (http://www.zend.com/) will prove worthwhile.
5) don't know which database you're using, but of course a profiler will show that's the bottleneck so tuning the database (and choosing the right database) and optimizing the system the database runs on yield the best results most of the time.
6) don't run reports or anything interactive on the live server (grin).
forgive me if all or any of this is obvious to you. just trying to share some (hard earned) lessons.
-c
Thanks for the tips. We are working on all of these things. The system is Linux/Apache/PHP/MySQL FYI. It will improve as we do more to optimize it. Yes we are going to rebuild the web server to be more lean and are running Zend.
fabulous. let me know if i can help in any way.
are you running Apache/PHP on the same box as MySQL? depending on the box(es) and the network and the application architecture, running two boxes can allow for far better optimization and tuning (and thus can result in higher performance).
of course, you probably realize that (grin).
-c
are you running Apache/PHP on the same box as MySQL? depending on the box(es) and the network and the application architecture, running two boxes can allow for far better optimization and tuning (and thus can result in higher performance).
of course, you probably realize that (grin).
-c
yup... all that has been considered & discussed. thanks for the post tho..
Yes we are running them on the same box. Right now we have 1 box, a cobalt raq3. Sure multiple boxes are ideal and faster, no arguement there. But $$$ is the important consideration right now. Besides even with ~200khits a day and up to 100 simultanious users, this box keeps up very well.
And the reason all the extra "shit" that is compiled into apache is bacuse cobalt has it's own special version of apache and if you screw up, other stuff stops working correctly.
At somepoint we will compile a seperate tuned apache version. The site is running pretty well right now, and it's never a good idea to intruduce too many changes at once.
I too have lots of php and mysql hosting experience
Thanks again
-r
Yes we are running them on the same box. Right now we have 1 box, a cobalt raq3. Sure multiple boxes are ideal and faster, no arguement there. But $$$ is the important consideration right now. Besides even with ~200khits a day and up to 100 simultanious users, this box keeps up very well.
And the reason all the extra "shit" that is compiled into apache is bacuse cobalt has it's own special version of apache and if you screw up, other stuff stops working correctly.
At somepoint we will compile a seperate tuned apache version. The site is running pretty well right now, and it's never a good idea to intruduce too many changes at once.
I too have lots of php and mysql hosting experience

Thanks again
-r
Thread
Thread Starter
Forum
Replies
Last Post
Muz
Australia & New Zealand S2000 Owners
3
May 28, 2002 10:48 PM







