I am building an API using Codeigniter.
In this API I got 10 models that I use now and then.
Currently I am loading them when I need them but I am thinking of auto loading
all models instead (to cut down on space in my controllers).
What will I loose by doing this? Will they cause things to slow down?
You are instructing CI to auto load your models into memory, which will increase memory footprint. I think autoloading won't have much effect of performance if you have plenty of RAM available but if you run PHP using mod_php then it might cause some slowdown because php processes have to respawned per request.
In any case, before making a decision -- Profile your app! there are two ways to do it.
PECL APD
Xdebug + kcachegrind (linux) or wincachegrind (windows) and it'll show you a few pretty charts that detail the exact timings, counts and memory usage (but you need another extension for that).
I would suggest PECL APD extension because its easier to setup
Related
I recently had an issue with composer, while I was installing a symfony2 bundle.
The free memory on my VM was 700M, but it wasn't enough. It only worked after I stopped some services and freed 1.2G.
Composer documentation doesn't specify much about this:
Note: Composer internally increases the memory_limit to 512M. If you have memory issues when using composer, please consider creating an issue ticket so we can look into it.
My question is - what does composer do internally that uses so much memory ?
In my mind, the process is fairly simple, basically check dependencies between modules, then download module archives, and modify certain files. I presume the algorithms to negotiate a version of all the modules with X stability aren't simple at all, but is this a common problem between package managers for other programming languages, or is it a composer optimization issue ? (I haven't heard of such problems with RubyGems, for example).
Most other dependency managers don't have complete SAT solver and do "approximations" which require much less comparisons (so less cpu, less memory) but in some cases can yield invalid results or unsolvable things where package managers like bower will ask you what you want to do. The Composer solver usually finds a solution or conclusively finds a conflict.
So in short this is a design choice, but I realize this is also a problem due to the memory usage. There are a few strategies that should result in lower memory usage, but they are time-consuming things to even try and not many people have enough project-knowledge or time to make this happen, so it's kinda stalled at the moment.
Yet my site pages load very slowly. Usually there's a 2-3 second lag before the page renders, and I cannot figure out why.
My site is powered by Wordpress v3.4.2.
I'm on a dedicated virtual server with plenty of resources and
bandwidth.
There are no huge images loading.
My CSS files load before JS scripts.
I've spent a lot of time trying to optimize the site within the constraints of the platform (Wordpress + plugins, etc). I don't expect my site to be SUPER fast, but I need it to not be SO slow.
I'm using Chrome's developer tools to audit my site but the suggestions do not appear to explain the long load time (unused CSS rules, etc). When I look at the timeline, I see a 2.7x second load time initially but I can't figure out why. Can anyone help me get to the bottom of this?
My site is located here. The homepage has some extra scripts, so it may be more helpful to look at this page.
I found this superb guide which really helped me fight through the mire of optimising Apache for use with WordPress:
http://thethemefoundry.com/blog/optimize-apache-wordpress/
You said you have a virtual server so chances are it's currently set up to load EVERY module - you'll find a great speed boost here if you eliminate unnecessary modules. Keep a backup of your config file in case you screw it up.
Also - use the TOP command through SSH to see how much memory PHP is using. Probably a lot currently. This will all be improved through eliminating modules as per above link. You don't mention how much memory you have on your VPS but there's a good chance your performance issues are coming from memory thrashing which will be mitigated significantly by reducing how much memory each PHP instance consumes using the link above.
Also, it matters to find out where your performance issues are actually coming from – a great little plugin called WP Tuner helps me locate performance bottlenecks. The original plugin is incompatible but someone else has written an upgrade:
http://www.wwvalue.com/tuts/tut-wp/wordpress-profiler-tuner-revised.html
That will help you identify which specific parts of the page are taking the longest to load so you will immediately find your performance bottleneck.
In addition, a cool plugin called Debug Queries is useful for tracking down performance issues although the wordpress profiler above actually does track queries too.
Finally – I can’t recommend highly enough this WordPress.org discussion on performance, and specifically on W3 Total Cache vs Super Cache (both are excellent).
It’s a fantastic read for anyone looking for split-second response times:
http://wordpress.org/support/topic/wp-super-cache-vs-w3-total-cache
I use W3 total cache on one of my sites and WP Super Cache on another. Both are great. I used both so I could learn about both. I would say use WP Super cache plus all the other tools the guy at the link above recommends if you're looking for extreme performance, but if you're looking to get immediate performance W3 total cache is more comprehensive in its initial setup.
Hope that helps.
use caching plugin,
put JS files at the bottom,
try different webhost (DB server may be slow sometimes)
minify css and JS,
make fewer HTTP requests
make sure external services (like FB and others) are not slowing down (remove
them and see if it helps)
run Yslow or similar test
try to use typekit or google font instead of cufon
Have you tried http://wordpress.org/extend/plugins/wp-super-cache/ or a similar caching plugin?
I have drupal based website (Drupal version is 6.19), it is very heavy content website (about 400K articles in it).
By following Rule one of using Drupal, I didnt make any change on the core. but i have a lot of enabled modules and some of them were customized.
Now, I am suffering of the performace and I need to enhance it. I never used Pressflow before, but I have read some articles saying that pressflow is better than Drupal. is it safe to upgrade from Drupal to Pressflow? and if so, how to do it?
Thanks for your help
Pressflow adds the following features to Drupal.
Support for database replication
Support for Squid and Varnish reverse proxy caching
Optimization for MySQL
Optimization for PHP 5
Pressflow is a 100% api-compliant replacement for your standard Drupal Core. There are no database schema changes. So long as you are running a normal Drupal core and meet the other system requirements (PHP5.x, MySQL 5.x), Pressflow is a "drop in" replacement.
Short answer: probably not. Especially since you state that you "have a lot of enabled modules and some of them were customized."
Longer answer: Pressflow's changes are relatively small, and hardly break the APIs. However, there are some incompatibilities, most in the area of database-access and caching. Especially modules that knowingly or unknowingly don't play by Drupals coding guidelines, will probably break. My suggestion: just try, if a module breaks: fix it (and file a patch).
But the real question is: are you going to benefit from Pressflow? It is not simply "better". It allows database-replication, such as load-balancing or master-slaves. Do you intend to use that?
It introduces better support for caching proxies. Are you planning to run a squid or some other caching proxy?
It has some small changes in, for example, the area of caching, that may (but may not) help you; depending on your current usage.
My suggestion: first see how to improve performance without Pressflow. Then, once you come across an area where Drupal is of little help, but which is "fixed" in Pressflow, consider changing.
Few modules have issues with Pressflow and if they do, someone else probably found them. Try searching if any of you modules is incompatible.
Its actually slowed out websites down. This is due to too many modules setup and no caching of our blocks. I am working through things now trying to setup caching and memcache. The issue I have though is that our editors want to see changes now. So some of this might be training. The other issue I have is that we have the fimage module setup and it does not work with the minimum cache lifetime setting so we do not get that benifit at all. In theory it should speed up your site but just let it be known it might do the opposite.
I'm using PHP + Zend Framework for several CLI daemons.
They take up quite a bit of memory. I'm assuming the Zend Framework part might be causing this, but I want to have facts showing me where the memory is wasted.
How can I determine where memory is wasted? Is this just a trial + error process?
Also how can I improve garbage collection (I read some articles that this might also be an issue causing big memory usage).
I'd recommend using XDebug's profiler, which should give you the answers you need.
The profiler will generate a cachegrind file, which you can view in a tool such as KCacheGrind to see where your program's bottlenecks and memory usages are.
Find out more on XDebug's profiler page: http://www.xdebug.org/docs/profiler
IME, PHP uses a huge amount of memory for parsing code - try building a simple script which does nothing other than explicitly including all the libs you're using and track the memory usage at start/finish. Compare this with what you see in your actual script.
Htbaa is partially correct - more recent versions of PHP have a much smarter garbage collector however the earlier versions still do garbage collection - they just don't find all the cases that the newer gc does. But because its garbage collection, you'll typically see something of a sawtooth in memory usage given a steady input load.
But good garbage collection won't fix bad code - if you've stored something in a variable which is not on the stack, then you need to unset it when you're done with it.
What version of PHP are you running? Only PHP >=5.3 has a decent garbage collector. PHP <=5.2 can eat all your memory when used to run daemon scripts.
While the site is in development mode, it takes for ever to edit content types and do various similar administrative tasks.
Is there a way to speed this up? What kind of hardware would I need?
Any specific MySQL optimization maybe?
Are you working on a local dev environment? That makes a huge difference. You shouldn't really need any big hardware as long as you're local. A new-ish $300 laptop with 4GB of RAM works fine for me.
However, no matter what you do, it's a lot of clicking, so the more you can learn to do that kind of stuff with code, the more efficient you can get.
This might help:
http://drupal.org/node/381668
Disable query log on all admin pages.
The devel module with performance logging is a great place to start to see where the problem is. You can see how many queries are being run per page and how long they take.
In my own experience of running Drupal on a netbook, the database was pretty insignificant in contributing to the page load times. The database was in fact considerably faster on my local machine than on the shared hosting environment I started out with (50-100ms vs. 1000-1500ms, as I recall). Due to the lack of processing power of the Atom CPU however, page loading times were about the same (~2-4 seconds).
If you're using something like XAMPP on a local machine, the default configuration is pretty lean. There are included configurations for larger servers, but beware of turning on the binary log.
Turning on the query cache can also be helpful, but to what degree is variable. It's the biggest boost for complex, often repeated queries; Drupal has some complex queries, but there is more so a lot of pretty simple ones. When you're developing you'll probably also invalidate the cache frequently. Regardless, on a local machine there isn't really any downside to enabling it other than some extra RAM usage. 32 MB could be quite reasonable to work with; I use more because I know I have plenty of available (even on a netbook).
Enabling a PHP opcode cache may also provide a boost in serving pages from your local machine. XAMPP includes the eAccelerator extension, though I would pick APC instead for a linux system.
The only other suggestions I have are trying to reduce the number of clicks you have to perform by using modules like Administration Menu, and make sure you're using a fast browser (e.g., firefox or chrome) since many of the administration pages use javascript.