Re: [PHP] PHP performance profiling
I'm curious about solutions that don't require installing something on the server side, since that's not usually an option with shared web hosting and all. Since PHP runs on the server, as part of the webserver, I think it will be inevitable that you'll need to install something on your server. -- Richard Heyes HTML5 Graphing for FF, Chrome, Opera and Safari: http://www.rgraph.org (Updated November 15th) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance profiling
On Tue, Nov 18, 2008 at 10:11 AM, Gryffyn [EMAIL PROTECTED] wrote: I did a search and didn't find anything really astounding sounding, so I wanted to ask for some live recommendations from the crowd here. I was wondering if anyone had used FirePHP with Firebug or could recommend a good profiling method for figuring out where the slow parts of your PHP code are. I'm curious about solutions that don't require installing something on the server side, since that's not usually an option with shared web hosting and all. I used to love Zend Studio's server component along with the IDE, but it doesn't help so much with shared web hosts where you can't install the server component. Ideally, I'd love to see what segments of the code are running slow, but at the very minimum, I want to see if it's the PHP code or the MySQL calls that are slow. I know I can just add my own statements in the code, but I was hoping there was a more comprehensive solution available. Thanks in advance. -TG -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php If you cannot install stuff on your server, set yourself up a local dev environment. You should really be doing this anyways. One of the easiest ways to do this is to download a pre-made vmware player server application. Or you could do the xampp thing. Once you have that you can use xdebug [1] to profile your code. It has a lot of various ways of profiling. It doesn't require you modifying your code at all. Then it generates these files that you can use kcachegrind/wincachegrind to see every single function your script calls, how long it took, etc. There's also another tool to view these files called webgrind[2] [1] http://www.xdebug.org/docs/profiler [2] http://code.google.com/p/webgrind/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance profiling
- Original Message - From: Eric Butera [EMAIL PROTECTED] To: Gryffyn [EMAIL PROTECTED] Cc: php-general@lists.php.net Date: Tue, 18 Nov 2008 12:16:04 -0500 Subject: Re: [PHP] PHP performance profiling On Tue, Nov 18, 2008 at 10:11 AM, Gryffyn [EMAIL PROTECTED] wrote: I did a search and didn't find anything really astounding sounding, so I wanted to ask for some live recommendations from the crowd here. I was wondering if anyone had used FirePHP with Firebug or could recommend a good profiling method for figuring out where the slow parts of your PHP code are. I'm curious about solutions that don't require installing something on the server side, since that's not usually an option with shared web hosting and all. I used to love Zend Studio's server component along with the IDE, but it doesn't help so much with shared web hosts where you can't install the server component. Ideally, I'd love to see what segments of the code are running slow, but at the very minimum, I want to see if it's the PHP code or the MySQL calls that are slow. I know I can just add my own statements in the code, but I was hoping there was a more comprehensive solution available. Thanks in advance. -TG If you cannot install stuff on your server, set yourself up a local dev environment. You should really be doing this anyways. One of the easiest ways to do this is to download a pre-made vmware player server application. Or you could do the xampp thing. Once you have that you can use xdebug [1] to profile your code. It has a lot of various ways of profiling. It doesn't require you modifying your code at all. Then it generates these files that you can use kcachegrind/wincachegrind to see every single function your script calls, how long it took, etc. There's also another tool to view these files called webgrind[2] [1] http://www.xdebug.org/docs/profiler [2] http://code.google.com/p/webgrind/ I'm not as worried about profiling the code itself as it's execution in it's final environment. So setting up a test on my local machine isn't going to give me what I want. It's a good idea, and I definitely use VMWare appliances for a few things (particulary testing in various browser versions that don't always like to be installed next to each other). I forgot about xdebug and haven't checked out webgrind yet. Thanks for the recommendations! And thanks to Nathan for the other recommendations. To get really good profiling feedback, control of the server is probably necessary. But if there was something that got me close without messing with the server, I figured it was worth asking about. -TG -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
Eric Butera schreef: On Mon, Mar 3, 2008 at 6:18 PM, Chris [EMAIL PROTECTED] wrote: Just FYI, using ADODB will slow down the performance of your app. Any function calls cost against you and it all adds up. If you remove it, then you remove functionality - so before you go and rip it out, check whether it's the bottleneck using xdebug. I use an abstraction layer all the time and the benefits far outweigh the 'costs'. -- Postgresql php tutorials http://www.designmagick.com/ Hi Chris, These 'benefits' you talk about really only matter if you switch your databases. If this app is written against Oracle and they never plan to change it, then it isn't a bad idea to cut out that fat and just deal with the native interface. Even writing wrapper functions that are very basic that abstract mysql_query or mssql_query end up adding a lot of overhead over lots of requests. Look at some of the PDO benchmarks. It is slower than the native functions too because it is just a wrapper. Even further if you are writing an app where you care about performance you should be writing your SQL to the point where it really isn't portable using all the little vendor specific features so that you get the most out of it. From my personal profiling most of my application time is spent in data access. So the less layers you have there the faster it runs. the adodb php layers are insignificant compared to the cost of the db connection and the round trip to retrieve data from the db. the significant application time you speak of is undoubtly spent at the database performing and retrieving the data as opposed to measurable overhead caused by a [number of] wrapper function[s]. high probability that SQL related tweaks (indexing, query restructuring, db tuning) will win you much, much more than removing any db abstraction layer But that is just my 2cents on it. :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
On Tue, Mar 4, 2008 at 5:51 AM, Jochem Maas [EMAIL PROTECTED] wrote: Eric Butera schreef: On Mon, Mar 3, 2008 at 6:18 PM, Chris [EMAIL PROTECTED] wrote: Just FYI, using ADODB will slow down the performance of your app. Any function calls cost against you and it all adds up. If you remove it, then you remove functionality - so before you go and rip it out, check whether it's the bottleneck using xdebug. I use an abstraction layer all the time and the benefits far outweigh the 'costs'. -- Postgresql php tutorials http://www.designmagick.com/ Hi Chris, These 'benefits' you talk about really only matter if you switch your databases. If this app is written against Oracle and they never plan to change it, then it isn't a bad idea to cut out that fat and just deal with the native interface. Even writing wrapper functions that are very basic that abstract mysql_query or mssql_query end up adding a lot of overhead over lots of requests. Look at some of the PDO benchmarks. It is slower than the native functions too because it is just a wrapper. Even further if you are writing an app where you care about performance you should be writing your SQL to the point where it really isn't portable using all the little vendor specific features so that you get the most out of it. From my personal profiling most of my application time is spent in data access. So the less layers you have there the faster it runs. the adodb php layers are insignificant compared to the cost of the db connection and the round trip to retrieve data from the db. the significant application time you speak of is undoubtly spent at the database performing and retrieving the data as opposed to measurable overhead caused by a [number of] wrapper function[s]. high probability that SQL related tweaks (indexing, query restructuring, db tuning) will win you much, much more than removing any db abstraction layer But that is just my 2cents on it. :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Hi Jochem, This is probably true. I was just referring to an old benchmark [1] I had seen a few years ago. Of course the biggest win will come from an opcode cache if that is a possibility. Just for the record I do use a db wrapper myself but I have weighed the pros and cons of the situation and determined that it works for me. I have many low traffic sites so it makes sense to have a wrapper that delays connections until they're used and such other little tweaks. I listen to peoples recoded talks from conferences and I've heard on many occasions that on single apps they take out the db abstraction. I wish I could cite references but it is out there if you want to dig enough. [1] http://phplens.com/lens/adodb/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
Eric Butera schreef: On Tue, Mar 4, 2008 at 5:51 AM, Jochem Maas [EMAIL PROTECTED] wrote: Eric Butera schreef: ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Hi Jochem, This is probably true. I was just referring to an old benchmark [1] I had seen a few years ago. Of course the biggest win will come from an opcode cache if that is a possibility. Just for the record I do use a db wrapper myself but I have weighed the pros and cons of the situation and determined that it works for me. I have many low traffic sites so it makes sense to have a wrapper that delays connections until they're used and such other little tweaks. I listen to peoples recoded talks from conferences and I've heard on many occasions that on single apps they take out the db abstraction. I wish I could cite references but it is out there if you want to dig enough. duh. ofcourse they do that. remove a layer of abstraction and win some speed. it a game of dimishing returns, take the big target first - that's usually the SQL queries, DB tuning. next step might be op-code caching, then data/output caching, and if that's not enough (or you have enough iron in play to make the numbers add up) you start to remove maintainability and/or abstraction from your code to win a few cpu cycles. php is web-glue, or for the purposes of my metaphor web-butter ... generally the sandwich is mostly filled with something other than butter. [1] http://phplens.com/lens/adodb/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
#1 Get the code, install it on a box in the closet, run valgrind --callgrind This will give you a stack trace of what gets called the MOST in your application. Look for tall trees in the call graph, and fix those first. #2 You can use 'ab' (apache benchmark) or similar to test it externally. #3 You can also script things with Selenium IDE and then use Selenium remote control to run them repeatedly, for the end-user experience. Don't let server non-access stop you from doing #1 though... On Mon, March 3, 2008 11:09 am, Thiago Pojda wrote: Guys, I've been asked to build a performance report for a PHP app. I can't profile it using automated tools as I don't have full access to the server, only to the application itself. It's a PHP4 Object-Oriented app, which uses ADODB as abstraction layer with a Oracle 8i databse. The system also uses a VB.NET socket server for some data manipulation. As for migrating to PHP5 I think it's crucial, but I need facts that it really runs faster than PHP4. Anyone? :) Any ideas on what might be the bottleneck? Thanks guys Atenciosamente, http://www.softpartech.com.br/ www.softpartech.com.br Thiago Henrique Pojda Desenvolvimento Web +55 41 3033-7676 [EMAIL PROTECTED] Excelência em Softwares Financeiros -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
On Mon, Mar 3, 2008 at 12:09 PM, Thiago Pojda [EMAIL PROTECTED] wrote: Guys, I've been asked to build a performance report for a PHP app. I can't profile it using automated tools as I don't have full access to the server, only to the application itself. It's a PHP4 Object-Oriented app, which uses ADODB as abstraction layer with a Oracle 8i databse. The system also uses a VB.NET socket server for some data manipulation. As for migrating to PHP5 I think it's crucial, but I need facts that it really runs faster than PHP4. Anyone? :) Any ideas on what might be the bottleneck? Thanks guys Atenciosamente, http://www.softpartech.com.br/ www.softpartech.com.br Thiago Henrique Pojda Desenvolvimento Web +55 41 3033-7676 [EMAIL PROTECTED] Excelência em Softwares Financeiros Try and get a copy of the files and database, then set it up on your dev machine. Then profile using Xdebug. If you're looking for comparison numbers maybe look at: http://sebastian-bergmann.de/archives/745-Benchmark-of-PHP-Branches-3.0-through-5.3-CVS.html Just FYI, using ADODB will slow down the performance of your app. Any function calls cost against you and it all adds up.
Re: [PHP] PHP performance
Thiago Pojda wrote: Guys, I've been asked to build a performance report for a PHP app. I can't profile it using automated tools as I don't have full access to the server, only to the application itself. It's a PHP4 Object-Oriented app, which uses ADODB as abstraction layer with a Oracle 8i databse. The system also uses a VB.NET socket server for some data manipulation. As for migrating to PHP5 I think it's crucial, but I need facts that it really runs faster than PHP4. Anyone? :) Any ideas on what might be the bottleneck? Hi Thiago, I think it depends on what the application does. You can't just point out a bottleneck just by saying which parts are used. You can however put little timing functions here and there to measure which part of an application is taking too long. Like this: $s = microtime(); do_some_stuff(); do_some_more_stuff(); $f = microtime(); echo ($f - $s).\n; This is very simple benchmarking and you need a lot of these steps to really get some idea where the bottleneck could be. A good start would be nearby query execution and results another would be with file access or remote connections. Also good to investigate are huge loops, huge arrays that are iterated over etc. Do this step by step so you are sure which part you are investigating. Otherwise you have 10 steps, 10 results and you don't know anymore where to look. Good luck. Aschwin Wesselius -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
Just FYI, using ADODB will slow down the performance of your app. Any function calls cost against you and it all adds up. If you remove it, then you remove functionality - so before you go and rip it out, check whether it's the bottleneck using xdebug. I use an abstraction layer all the time and the benefits far outweigh the 'costs'. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
On Mon, Mar 3, 2008 at 6:18 PM, Chris [EMAIL PROTECTED] wrote: Just FYI, using ADODB will slow down the performance of your app. Any function calls cost against you and it all adds up. If you remove it, then you remove functionality - so before you go and rip it out, check whether it's the bottleneck using xdebug. I use an abstraction layer all the time and the benefits far outweigh the 'costs'. -- Postgresql php tutorials http://www.designmagick.com/ Hi Chris, These 'benefits' you talk about really only matter if you switch your databases. If this app is written against Oracle and they never plan to change it, then it isn't a bad idea to cut out that fat and just deal with the native interface. Even writing wrapper functions that are very basic that abstract mysql_query or mssql_query end up adding a lot of overhead over lots of requests. Look at some of the PDO benchmarks. It is slower than the native functions too because it is just a wrapper. Even further if you are writing an app where you care about performance you should be writing your SQL to the point where it really isn't portable using all the little vendor specific features so that you get the most out of it. From my personal profiling most of my application time is spent in data access. So the less layers you have there the faster it runs. But that is just my 2cents on it. :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
These 'benefits' you talk about really only matter if you switch your databases. If this app is written against Oracle and they never plan to change it, then it isn't a bad idea to cut out that fat and just deal with the native interface. Even writing wrapper functions that are very basic that abstract mysql_query or mssql_query end up adding a lot of overhead over lots of requests. Look at some of the PDO benchmarks. It is slower than the native functions too because it is just a wrapper. Using native functions all over the place, how would you log all the database queries that a page is running (especially if you don't have server-level access, only ftp access - ie a clients server on a shared host) ? Using wrapper functions/classes it's easy to add an error_log call in to the 'Query' method to see where everything comes from, and/or how long each query takes to run. Obviously that stuff is disabled by default but with a code change it's doing what you need. Even further if you are writing an app where you care about performance you should be writing your SQL to the point where it really isn't portable using all the little vendor specific features so that you get the most out of it. Depends on the app I guess, though I haven't seen an app that vendor specific (apart from anything to do with full text searching). Using xdebug is the first step to working out where your real bottleneck is - I highly doubt it'll be the wrapper class/functions. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
On Mon, Mar 3, 2008 at 9:21 PM, Chris [EMAIL PROTECTED] wrote: These 'benefits' you talk about really only matter if you switch your databases. If this app is written against Oracle and they never plan to change it, then it isn't a bad idea to cut out that fat and just deal with the native interface. Even writing wrapper functions that are very basic that abstract mysql_query or mssql_query end up adding a lot of overhead over lots of requests. Look at some of the PDO benchmarks. It is slower than the native functions too because it is just a wrapper. Using native functions all over the place, how would you log all the database queries that a page is running (especially if you don't have server-level access, only ftp access - ie a clients server on a shared host) ? Using wrapper functions/classes it's easy to add an error_log call in to the 'Query' method to see where everything comes from, and/or how long each query takes to run. Obviously that stuff is disabled by default but with a code change it's doing what you need. Even further if you are writing an app where you care about performance you should be writing your SQL to the point where it really isn't portable using all the little vendor specific features so that you get the most out of it. Depends on the app I guess, though I haven't seen an app that vendor specific (apart from anything to do with full text searching). Using xdebug is the first step to working out where your real bottleneck is - I highly doubt it'll be the wrapper class/functions. -- Postgresql php tutorials http://www.designmagick.com/ He said he can't use xdebug. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Performance and System Load
on the point of class size; i think this is more a design issue than a performance issue. i worked at a place where we had several files w/ classes that were several thousand lines in size. one i remember was over 6000 lines long. personally i would never let something grow that large, but all im saying is we had large classes like that and the system wasnt crawling. -nathan On 7/20/07, Larry Garfield [EMAIL PROTECTED] wrote: On Friday 20 July 2007, Sascha Braun, CEO @ ejackup.com wrote: Dear People, The webserver does only contain the webspace filesystem structure as well as 5 line of PHP Code dummies, for every document in the content management system, to avoid the usage of mod_rewrite. I inherited a CMS at work that did that. Stop. Now. Use mod_rewrite. You'll live longer and spend less on hair-regrowth medication. mod_rewrite is not itself a huge performance hit. If you're on a dedicated server then you can move the mod_rewrite directive to the apache.conf file and disable .htaccess files, which can give you a performance boost, but if a reasonably simple mod_rewrite is the difference that is killing your server then you need to rethink your server. It's a minor issue. You'll get a better performance gain out of a slightly faster processor. Your PHP coding style itself likely has little if any impact on performance. pre vs. post increment is going to be a tiny fraction of a percent compared to the time taken to parse code, hit the database, hit the disk, etc. As others have said, benchmark benchmark benchmark. As a general guideline, the big performance killers I've run in to include: - Parsing. Opcode cache is good, but if you can give it less to cache that helps, too. You said you're already using autoload(), which helps, but make sure that you're not loading gobs of code that you don't use. Even with an opcode cache, that will eat up RAM. - SQL in loops. Never do this. - Cache pretty much everything that you get back from the database if you can, using a static variable. (Not a global; a static variable local to a function or method, or a private class variable.) If you're loading complex objects, cache the fully prepared version. That not only provides a performance boost, but also provides you with a good single-point-of-optimization because it's then much easier to shift that from a static variable or static array to a memcached storage. - Limit your individual transfers. Oft-forgotten, but remember that every file the browser has to request is another HTTP hit on the server. Even if the response from the server is nope, no change, it's still an HTTP hit. That can really hurt your effective performance, both on the server side and client side. Merge your CSS and JS into as few files as reasonable, even if that means that you send more than you need to on the first page request. It helps overall. You can do that manually or automatically. (Drupal, for instance, auto-aggregates CSS and in the next version will auto-aggregate JS, too. That's been a big performance boost.) The same goes for image files. - Apropos of the last, Firebug! The latest version has a great profiler that can show you how long each HTTP request takes. You may find that you spend most of your browser-load time on things that don't involve PHP at all. - EXPLAIN your SQL. That is, the MySQL EXPLAIN command prefixed to any SELECT query will tell you how MySQL is going to parse and process it. Odds are good that adding a few well-placed keys/indexes will make your SQL an order of magnitude faster or more. Also, watch out for filesort. Any time a query has to do a filesort, it gets slow. It always has to filesort if you are doing a WHERE and ORDER BY that use fields in different tables. Avoid that if you can. Much more information in a MySQL group. :-) Again, benchmark it from every direction you can. Odds are, though, that your PHP code itself is not the bottleneck but the server configuration, SQL server, HTTP traffic, etc. are where you're really dying. Cheers. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Performance and System Load
Hi, What is your desired performance level on what kind of hardware. Have look memcached, General performance tip do not include more than 10 files a page load. I had CMS project too. Sometimes it uses 10 MB of php memory (generally uses 3 mb of php memory). It uses Memcached in every way possible. Uses php Adodb for sql connection. Uses SQL based sessions. Except the external libs (adobs, php sniffer, phpmailer etc) no object method used. Also we had language, template support. Generally be able to pump 5-7 pages per second on intel PII 350 mhz 320 mb ram IDE hdd. If I remove XSS detector (auto check for every member of $_REQUEST array). It can reach 9 - 10 pages per second. My Experiences Looping around sql is bad. Reading large flatfiles bad. Processing large texts are bad (Templating, Lots of preg replaces). If any of those operation was write once read many, store to memcached, then use it. Another simple performance tip. Most of for examples of php look like this for($x=0;$xsizeof($arrSometing);$x++) This is bad. In every cycle you call sizeof this was good $intSize = sizeof($arrSometing); for($x=0;$x$intSize;$x++) if u use. for($x=0;$x$intSiz;++$x). You may gain another %10 to determine costs of your functions use xdebug and kcachegrind. Hope Helps. Regards Sancar On Friday 20 July 2007 10:25:47 Sascha Braun, CEO @ ejackup.com wrote: Dear People, I developed a very large Application, which has at the moment strong performace problems, while pages are loaded. At the moment I am trying to lower the number of filesystem calls as much as I can. I was able allready to lower the rate of filesystem calls from round about 260 calls, which normaly included database calls each time as well. Now a page loads with round about 36 Filesystem and database calls, so a improvement could really get established. Now, as I might have imagined, the next problem is the object model of the application which was very flexible in the past two years. But now over time, for example the content management class grew up to 400 Kb which is for a web application hell of a lot. But it seems it is the only class at that enormous size. I am using the PHP5 autoload functionality exclusive, so no other way of loading classes is getting used. No I started to come in mind of, splitting the cms class into smaller potions. Will it really improve the page load, or will the object ini- tialisations of the new appearing mass of classes have the same effect as a class, stored in the eaccelator cache with a memory consumtion round about 400 Kb? Another question is, that I started to include my application framework over a symlink placed in every webspace directory. I've read somewhere that linux needs time to resolve a symlinks target. Can this be a real performance issue? All datasets as well as images, modules and all application relevant informations are loaded from that symlinked place at the moment. The webserver does only contain the webspace filesystem structure as well as 5 line of PHP Code dummies, for every document in the content management system, to avoid the usage of mod_rewrite. It would be really wonderfull, to be able to discuss my questions with you people here :)) Best Regards, Sascha -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Performance and System Load
On Fri, July 20, 2007 2:25 am, Sascha Braun, CEO @ ejackup.com wrote: I developed a very large Application, which has at the moment strong performace problems, while pages are loaded. Look into valgrind/callgrind to get an idea of where all your time is being spent. Optimizing something that is not taking any significant time pointless. At the moment I am trying to lower the number of filesystem calls as much as I can. I was able allready to lower the rate of filesystem calls from round about 260 calls, which normaly included database calls each time as well. Now a page loads with round about 36 Filesystem and database calls, so a improvement could really get established. Whoa. I'm assuming this helped a lot. But, really, 36 filesystem calls seems kinda high to me... Now, as I might have imagined, the next problem is the object model of the application which was very flexible in the past two years. But now over time, for example the content management class grew up to 400 Kb which is for a web application hell of a lot. Are you only imagining that the class size is the problem, or have you some kind of evidence? But it seems it is the only class at that enormous size. I am using the PHP5 autoload functionality exclusive, so no other way of loading classes is getting used. No I started to come in mind of, splitting the cms class into smaller potions. Will it really improve the page load, or will the object ini- tialisations of the new appearing mass of classes have the same effect as a class, stored in the eaccelator cache with a memory consumtion round about 400 Kb? I cannot begin to imagine how splitting it into a bunch of little classes, each with an fstat for the autoload, is going to improve things. Rather the opposite, really. And splitting it up in the cache will just give you a lot of little numbers that add up to more than 400k due to overhead, so that doesn't seem like a win... Another question is, that I started to include my application framework over a symlink placed in every webspace directory. I've read somewhere that linux needs time to resolve a symlinks target. I would DEFINITELY look very carefully at this... If the eaccelerator is unable to properly cache because of the symlink, your accelerator may be serving no useful purpose... It's also possible that the accelorator handles symlink just fine, but anything not cached requires 2 fstats instead of 1. That's definitely a slow-down, but how MUCH of a slowdown, and whether it's relevant, is unknown until you profile (see valgrind/callgrind paragraph at beginning). Can this be a real performance issue? All datasets as well as images, modules and all application relevant informations are loaded from that symlinked place at the moment. If all else fails, moving the images to a separate server is a common way of lightening the load on a busy web-server. It's generally pretty trivial in a well-designed application. Actually, it's even pretty trivial in a badly-designed application, usually. The webserver does only contain the webspace filesystem structure as well as 5 line of PHP Code dummies, for every document in the content management system, to avoid the usage of mod_rewrite. I'm not sure what this means, though I'm going to hazard a guess that you've got some kind of front-controller model where a 5-line PHP script is pounded to figure out what other content to serve up. While this is really nifty for a lot of reasons, it *DOES* mean that you're hitting that 5-line script for every page hit, which is an extra fstat call, unless your cache is working properly. If the cache is working properly, it's fine. If not, fix the cache, or consider a different model... It would be really wonderfull, to be able to discuss my questions with you people here :)) Before you do anything else, I stress again that using valgrind/callgrind (or any profiling tool) to find your performance bottleneck MUST be your first step. Anything further work or even discussion is pretty pointless without that. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Performance and System Load
On Friday 20 July 2007, Sascha Braun, CEO @ ejackup.com wrote: Dear People, The webserver does only contain the webspace filesystem structure as well as 5 line of PHP Code dummies, for every document in the content management system, to avoid the usage of mod_rewrite. I inherited a CMS at work that did that. Stop. Now. Use mod_rewrite. You'll live longer and spend less on hair-regrowth medication. mod_rewrite is not itself a huge performance hit. If you're on a dedicated server then you can move the mod_rewrite directive to the apache.conf file and disable .htaccess files, which can give you a performance boost, but if a reasonably simple mod_rewrite is the difference that is killing your server then you need to rethink your server. It's a minor issue. You'll get a better performance gain out of a slightly faster processor. Your PHP coding style itself likely has little if any impact on performance. pre vs. post increment is going to be a tiny fraction of a percent compared to the time taken to parse code, hit the database, hit the disk, etc. As others have said, benchmark benchmark benchmark. As a general guideline, the big performance killers I've run in to include: - Parsing. Opcode cache is good, but if you can give it less to cache that helps, too. You said you're already using autoload(), which helps, but make sure that you're not loading gobs of code that you don't use. Even with an opcode cache, that will eat up RAM. - SQL in loops. Never do this. - Cache pretty much everything that you get back from the database if you can, using a static variable. (Not a global; a static variable local to a function or method, or a private class variable.) If you're loading complex objects, cache the fully prepared version. That not only provides a performance boost, but also provides you with a good single-point-of-optimization because it's then much easier to shift that from a static variable or static array to a memcached storage. - Limit your individual transfers. Oft-forgotten, but remember that every file the browser has to request is another HTTP hit on the server. Even if the response from the server is nope, no change, it's still an HTTP hit. That can really hurt your effective performance, both on the server side and client side. Merge your CSS and JS into as few files as reasonable, even if that means that you send more than you need to on the first page request. It helps overall. You can do that manually or automatically. (Drupal, for instance, auto-aggregates CSS and in the next version will auto-aggregate JS, too. That's been a big performance boost.) The same goes for image files. - Apropos of the last, Firebug! The latest version has a great profiler that can show you how long each HTTP request takes. You may find that you spend most of your browser-load time on things that don't involve PHP at all. - EXPLAIN your SQL. That is, the MySQL EXPLAIN command prefixed to any SELECT query will tell you how MySQL is going to parse and process it. Odds are good that adding a few well-placed keys/indexes will make your SQL an order of magnitude faster or more. Also, watch out for filesort. Any time a query has to do a filesort, it gets slow. It always has to filesort if you are doing a WHERE and ORDER BY that use fields in different tables. Avoid that if you can. Much more information in a MySQL group. :-) Again, benchmark it from every direction you can. Odds are, though, that your PHP code itself is not the bottleneck but the server configuration, SQL server, HTTP traffic, etc. are where you're really dying. Cheers. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
[snip] I figured PHP's memory limit per script at 8mb might be the bottleneck, so I upped it to 128, restarted apache, and reran the script. Increasing available memory had no effect. [/snip] This may have already been addressed, but did you index any key fields? alex hogan * The contents of this e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom it is addressed. The views stated herein do not necessarily represent the view of the company. If you are not the intended recipient of this e-mail you may not copy, forward, disclose, or otherwise use it or any part of it in any form whatsoever. If you have received this e-mail in error please e-mail the sender. * -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
[snip] Any recommendations on how to make PHP run faster? [/snip] A multiple CPU box. (It's a legitimate answer!) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
[snip] Any recommendations on how to make PHP run faster? [/snip] A multiple CPU box. (It's a legitimate answer!) I usually add more gerbils to my spinning wheel. -- --Matthew Sims --http://killermookie.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
If your problem is with a long running MySQL Query, and many of mine have been, I would suggest you read http://dev.mysql.com/doc/mysql/en/Optimizer_Issues.html Your objective is to make sure that all your database queries avoid the deadly table scan as a part of their query plan. Good Luck, Warren Vail -Original Message- From: Jay Blanchard [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 12:16 PM To: Ed Lazor; [EMAIL PROTECTED] Subject: RE: [PHP] PHP performance [snip] Any recommendations on how to make PHP run faster? [/snip] A multiple CPU box. (It's a legitimate answer!) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
Jay Blanchard wrote: [snip] Any recommendations on how to make PHP run faster? [/snip] A multiple CPU box. (It's a legitimate answer!) Lot of good that did. I just threw 8 socket 7 AMD processors into a box, and PHP isn't even the slightest bit faster. -- John C. Nichel ÜberGeek KegWorks.com 716.856.9675 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
-Original Message- This may have already been addressed, but did you index any key fields? I do have some indices created, but I'll check to see if there are more than can boost things. Thanks =) Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
Good point Jay. Luckily the server has dual 2.4gh xeon's with 2gig of ram *grin* -Original Message- [snip] Any recommendations on how to make PHP run faster? [/snip] A multiple CPU box. (It's a legitimate answer!) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
* Thus wrote Ed Lazor: Any recommendations on how to make PHP run faster? To help figure out which queries are running slow there is the php.ini setting: mysql.trace_mode=On Using this will have the php library analyze your queries and if any of them do table scans php will issue a warning about it, which can be very helpful finding out where you need indexes. I have a script pulling a lot of data from MySQL and generating reports and spitting out data (flush) as it's processing so I can see what's going on. It was taking around 10 seconds to process each order. I reduced the total number of orders being processed. I expected the script to take less time because there were fewer orders to process, but I was surprised to discover that time spent processing each order also reduced almost in half. I figured PHP's memory limit per script at 8mb might be the bottleneck, so I upped it to 128, restarted apache, and reran the script. Increasing available memory had no effect. Its hard to say blindly where the bottle-neck is though. Curt -- First, let me assure you that this is not one of those shady pyramid schemes you've been hearing about. No, sir. Our model is the trapezoid! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
Lot of good that did. I just threw 8 socket 7 AMD processors into a box, and PHP isn't even the slightest bit faster. Did you try a curveball when throwing the processors into the box? -Ed -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
Thanks Vail, I'll check that out. -Ed -Original Message- If your problem is with a long running MySQL Query, and many of mine have been, I would suggest you read http://dev.mysql.com/doc/mysql/en/Optimizer_Issues.html Your objective is to make sure that all your database queries avoid the deadly table scan as a part of their query plan. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
Ooo ahhh, thanks Curt =) -Original Message- To help figure out which queries are running slow there is the php.ini setting: mysql.trace_mode=On Using this will have the php library analyze your queries and if any of them do table scans php will issue a warning about it, which can be very helpful finding out where you need indexes. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
Did you try a curveball when throwing the processors into the box? Processors like sliders... Can't lay off 'em.., can't hit 'em. alex hogan * The contents of this e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom it is addressed. The views stated herein do not necessarily represent the view of the company. If you are not the intended recipient of this e-mail you may not copy, forward, disclose, or otherwise use it or any part of it in any form whatsoever. If you have received this e-mail in error please e-mail the sender. * -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance [solution]
I added more indexes. The 20 minute report just took 40 seconds *grin* Thanks Everyone, Ed -Original Message- From: Curt Zirzow [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 3:07 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] PHP performance * Thus wrote Ed Lazor: Any recommendations on how to make PHP run faster? To help figure out which queries are running slow there is the php.ini setting: mysql.trace_mode=On Using this will have the php library analyze your queries and if any of them do table scans php will issue a warning about it, which can be very helpful finding out where you need indexes. I have a script pulling a lot of data from MySQL and generating reports and spitting out data (flush) as it's processing so I can see what's going on. It was taking around 10 seconds to process each order. I reduced the total number of orders being processed. I expected the script to take less time because there were fewer orders to process, but I was surprised to discover that time spent processing each order also reduced almost in half. I figured PHP's memory limit per script at 8mb might be the bottleneck, so I upped it to 128, restarted apache, and reran the script. Increasing available memory had no effect. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance [solution]
woohoo indexes kick a$$.. at the expense of mem though :) J Ed Lazor [EMAIL PROTECTED] wrote: I added more indexes. The 20 minute report just took 40 seconds *grin* Thanks Everyone, Ed -Original Message- From: Curt Zirzow [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 3:07 PM To: [EMAIL PROTECTED] Subject: Re: [PHP] PHP performance * Thus wrote Ed Lazor: Any recommendations on how to make PHP run faster? To help figure out which queries are running slow there is the php.ini setting: mysql.trace_mode=On Using this will have the php library analyze your queries and if any of them do table scans php will issue a warning about it, which can be very helpful finding out where you need indexes. I have a script pulling a lot of data from MySQL and generating reports and spitting out data (flush) as it's processing so I can see what's going on. It was taking around 10 seconds to process each order. I reduced the total number of orders being processed. I expected the script to take less time because there were fewer orders to process, but I was surprised to discover that time spent processing each order also reduced almost in half. I figured PHP's memory limit per script at 8mb might be the bottleneck, so I upped it to 128, restarted apache, and reran the script. Increasing available memory had no effect. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
This is a great tip. Thanks! I've added it to my folder of tips to speed up PHP. Matthew Runo http://www.quabbo.com Quabbo Internet Services The only host with the Zend Performance Suite! On Aug 10, 2004, at 3:07 PM, Curt Zirzow wrote: * Thus wrote Ed Lazor: Any recommendations on how to make PHP run faster? To help figure out which queries are running slow there is the php.ini setting: mysql.trace_mode=On Using this will have the php library analyze your queries and if any of them do table scans php will issue a warning about it, which can be very helpful finding out where you need indexes. I have a script pulling a lot of data from MySQL and generating reports and spitting out data (flush) as it's processing so I can see what's going on. It was taking around 10 seconds to process each order. I reduced the total number of orders being processed. I expected the script to take less time because there were fewer orders to process, but I was surprised to discover that time spent processing each order also reduced almost in half. I figured PHP's memory limit per script at 8mb might be the bottleneck, so I upped it to 128, restarted apache, and reran the script. Increasing available memory had no effect. Its hard to say blindly where the bottle-neck is though. Curt -- First, let me assure you that this is not one of those shady pyramid schemes you've been hearing about. No, sir. Our model is the trapezoid! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP performance
Your tag line caught my attention - have any specs on performance boosts provided by Zend? The only host with the Zend Performance Suite! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP performance
Well, across the sites that are on our server at the moment we are seeing an average increase in PHP execution speed of 244% (I just ran a test). According to Zend if everyone of our clients were to use partial page caching and the like, we'd be seeing closer to a 1000% (10x) speedup. Quabbo.com is currently being redesigned to offer more information on partial page caching and the other improvements that ZPS allows such as it's new php download server plugin. I'd also like to get it designed with CSS rather than tables. It's not hard to add in partial page caching code to a PHP driven site, but people just don't want to do it when they can get a decent boost from just being under the Zend Performance Suite's umbrella effects. Matthew Runo http://www.quabbo.com Quabbo Internet Services The only host with the Zend Performance Suite! On Aug 10, 2004, at 3:47 PM, Ed Lazor wrote: Your tag line caught my attention - have any specs on performance boosts provided by Zend? The only host with the Zend Performance Suite! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php performance
It doesn't sound like you've testing to see where the bottleneck is. I would first recommend inserting some microtime() commands into you PHP code, like around your queries and blocks of PHP code. This will tell you what is taking the longest time and will point you in the right direction. Next I would look in your MySQL logs to see if you have slow queries or find out what MySQL is spending it's time on. On Thursday, January 23, 2003, at 04:42 PM, arch wrote: I'm running php4 on apache on linux. I'm having performance problems with php getting data from the mysql database. -- Brent Baisley Systems Architect Landover Associates, Inc. Search Advisory Services for Advanced Technology Environments p: 212.759.6400/800.759.0577 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] php performance
I'm going to ask the really stupid question... Is mysql, php, apache running on the same box as the box you are using to test from? -Chris -Original Message- From: arch [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 1:42 PM To: [EMAIL PROTECTED] Subject: [PHP] php performance I'm running php4 on apache on linux. I'm having performance problems with php getting data from the mysql database. With one user at a given instant, performance is fine, even with the massive size of the data table. But when do very rudimentary load testing (basically, opening a few browser and performing the same requests), the performance is awful. I suppose the issue is with mysql, but I can't be sure. What are some solutions to performance issues such as these? I've already done mysql indexing, which is how I got the current level of performance. But again, performance is unsatisfactory with just a few simultaneous requests. Thanks in advance. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php performance
Nope. It's tested with a typical client/server setup, as in a real use case. Chris McCluskey [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED].. . I'm going to ask the really stupid question... Is mysql, php, apache running on the same box as the box you are using to test from? -Chris -Original Message- From: arch [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 1:42 PM To: [EMAIL PROTECTED] Subject: [PHP] php performance I'm running php4 on apache on linux. I'm having performance problems with php getting data from the mysql database. With one user at a given instant, performance is fine, even with the massive size of the data table. But when do very rudimentary load testing (basically, opening a few browser and performing the same requests), the performance is awful. I suppose the issue is with mysql, but I can't be sure. What are some solutions to performance issues such as these? I've already done mysql indexing, which is how I got the current level of performance. But again, performance is unsatisfactory with just a few simultaneous requests. Thanks in advance. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] php performance
Chris, Can we see your test code? John arch said: Nope. It's tested with a typical client/server setup, as in a real use case. Chris McCluskey [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED].. . I'm going to ask the really stupid question... Is mysql, php, apache running on the same box as the box you are using to test from? -Chris -Original Message- From: arch [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 1:42 PM To: [EMAIL PROTECTED] Subject: [PHP] php performance I'm running php4 on apache on linux. I'm having performance problems with php getting data from the mysql database. With one user at a given instant, performance is fine, even with the massive size of the data table. But when do very rudimentary load testing (basically, opening a few browser and performing the same requests), the performance is awful. I suppose the issue is with mysql, but I can't be sure. What are some solutions to performance issues such as these? I've already done mysql indexing, which is how I got the current level of performance. But again, performance is unsatisfactory with just a few simultaneous requests. Thanks in advance. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP-Performance
Performance related issues depend on too many factors infact, however, PHP is known to be fast in itself (as an apache module), oracle is also known to be fast just like MySQL, but still it depends on what your app will do with the database, and how would you manage both your database and application in order to get good performance, one of the most important sides, is your hardware, single server, multiple servers, dual processors or more? , and so on ... your connection? However PHP, Oracle, Apache, Linux (prefered) is a good group. Regrads, Khalid Al-kary Do you know any resource about php performance? I wonder that can I use php+apache+oracle for a web site serving to many clients ( such as 10.000 ) at the same time? Fatih Üstündað Yöre Elektronik Yayýmcýlýk A.Þ. 0 212 234 00 90 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP-Performance
Get in touch with Zend. I bet they have benchmarks with their optimizer engine. http://www.zend.com/ Cheers, Mike *** REPLY SEPARATOR *** On 03/01/2003 at 3:56 PM Fatih Üstündað wrote: Do you know any resource about php performance? I wonder that can I use php+apache+oracle for a web site serving to many clients ( such as 10.000 ) at the same time? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
