I am new with Magento and have developed a website using CE 1.7.0.2. Now its ready to go live but I have issues with slow page load.
My website product home, list and detail page initially takes time to 10-13 sec to page load but after that first load it only takes 1-2 second to page load.
Also I have installed APC, Memcache and CDN on server and full page cache extension for website but yet it is slow. I am so frustrated why this happening with my website?
If anybody knows how can we resolve speed up issues that will be helpful for me.
Thanks!
You can go through the below steps for Magento Optimization:
High Performance Dedicated Server. Ex: Amazon EC2 cloud
Swap Apache for NGINX
Minimize Javascript use
Minify and Compressed CSS files
‘Combine CSS’ seeks to reduce the number of HTTP requests made by a
browser
Optimize images
Use lazyload for images
Specify Image dimensions
Combine images into CSS sprites
Use a Content Delivery Network (CDN) for delivering static files
like JS, CSS and Images to offload your server
Disable modules/extension which are not required
Enable all Magento Caches
Use a Full Page Cache / Varnish Cache / Memcache / RedisCache
Don’t use layered navigation if you don’t really need it, it needs
a lot of resources
Enable Compilation
Limit the number of products on a product overview page.
Set only those attribute frontend properties to ‘Yes’ that you’re
actually going to use. Set all other to ‘No’.
Don’t use in quick search, advanced search compare, etc. : Catalog
-> Attributes -> Manage Atributes -> Frontend Properties.
Install Google Page Speed Module
Minimize redirects – Minimizing HTTP redirects from one URL to
another cuts out wait time for users.
Prefer asynchronous resources – Fetching resources asynchronously
prevents those resources from blocking the page load.
This list may help you for Magento performance improvement:
Enable Magento caching
This is ofcourse the first step in optimization: Enable all the available caches in the Magento Admin Panel.
Compress images
Many people forget that images (PNG, JPG) can be compressed, which lowers the bandwidth between the browser and the webserver. Not only the images used by the Magento skin need optimizing, but catalog images as well. Various tools allow you to compress batches of images, for instance the online tool Smush.It.
Disable unneeded Magento modules
By disabling Magento modules that you do not need, less resources are needed – as simple as that. Modules could be disabled through the configuration in the Magento Admin Panel, or by editing XML-files in app/etc/modules. For instance, disable Mage_Log which performs queries on every request, but is not needed if you gather site statistics using external programs.
Enable flat catalogs for smaller webshops
For smaller webshops switching from the complex EAV-structure to a flat catalog could save time. This optimization is dubious and depends on many parameters, so do not take this step lightly.
W3C compliance
While it could be argued that this is less important with the coming of HTML5, it is still a fact that if your webpages are filled with ugly errors, the browser will have a harder time interpreting it. If you stick to W3C compliance, it is made sure the browser engine has an easy job parsing your HTML-code.
Compress output in general
By enabling the PHP-setting zlib.output_compression the output generated by PHP is compressed when sent to the browser. This saves bandwidth. Instead of using this, you could use the Apache mod_deflate module as well, which allows also for compression of non-PHP output (CSS, JavaScript, other plain text-files).
Configure PHP options
Most PHP settings actually do not influence the performance of Magento, but just set certain limits. For instance, settings like memory_limit and max_execution_time do not increase the page load but just make sure that certain actions do not timeout or run into memory problems.
Session storage
With Magento, sessions could be stored in files or in the database (by configuring app/etc/local.xml). Which option performs best, really depends on how the hosting environment is setup. If MySQL databases perform well, session storage in the database could benefit your site. But if MySQL is not setup correctly, the best choice might be files.
Use a PHP accelerator
By opcode caching, PHP-execution could be fastened. There are various PHP accelerators doing this job (APC, ZendOptimizer+, eAccelerator, XCache). Both APC and ZendOptimizer+ are working flawless with Magento.
Tune PHP realpath_cache
By tuning the PHP realpath_cache_size to for instance 128K (default is 16K) and the realpath_cache_ttl to 86400, things might be speeding up. Make sure you don’t run out of memory, because every Apache child will consume the configured caching size.
Use Apache mod_expires
By telling the browser which files to keep in cache for how long, you can optimize the browser cache. For instance, JavaScript files tend to change much less then CSS files (at least in the first stages of the site), but perhaps after the site is running smooth for some months you can maximize the expiration date.
Beware 404 errors
Every time a file (like a stylesheet or image) is not found, this generates a 404 error. Because the default 404 of Magento is caught by the application of Magento itself, this causes the Magento application to start for every 404 encountered. Check your Apache logs to make sure all 404 errors are solved.
Disable Magento logging
Within the Magento configuration, you can enable logging under the Developers-tab. Depending on the Magento modules this could lead to more logs needed to be written to the filesystem, slowing down your shop. Because the logging-abilities are only needed to debug something, in daily usage, it’s best to disable logging altogether.
MySQL table optimization
Through phpMyAdmin, you can perform the command OPTIMIZE TABLE on specific Magento database-tables. When a table is cluttered, this could lead to improved performance. This does not only count for the complex EAV-tables, but also for regular MySQL tables that are used frequently (for instance, core_config_data).
Merge CSS and JavaScript
By merging all CSS and JavaScript files together as one big file, only one single HTTP-request is needed by the browser to fetch this content. This saves bandwidth. For this merging, the FooMan Speedster module could be used. Magento 1.4 contains an option to merge CSS, while JavaScript-files are merged by default.
Besides merging, crunching is also an option offered by FooMan Speedster: It removes whitespaces from the output, but when compression is already applied to CSS, this option is less needed.
Use Magento Compiler module
The Magento Compiler module limits the number of directories that PHP has to search through when looking for PHP-files. This decreases the PHP execution-time, which speeds up the Magento application in general.
Be warned that you need to be careful when making changes to your Magento system, while the Magento Compiler is enabled. Upgrades should only be undertaken when the compiler is (temporarily) disabled.
One very neat trick that speeds up things tremenduously is to create a tmpfs-mount specifically for the includes/src folder. Note that this tmpfs-mount needs to be at least 100Mb – preferably 200Mb.
MySQL server tuning
The default MySQL setup is a lot of times sufficient to run a general hosting environment, but not all optimized for Magento. Tuning settings like query_cache_size could dramatically increase performance, but is also dangerous because it hugely depends on other variables (number of databases, number of tables per database, number of queries, peak usage).
Serve static content through a CDN
Static content like images, CSS-stylesheets or JavaScript-files, could be served through other servers that are more optimized for static content. For instance, a CDN could be used so that the static content is always served from a location that is closest to the visitor. This is vital for webshops serving customers worldwide.
Disable local Magento modules
If your site does not need local Magento modules, you could choose to skip the search for local modules alltogether. Within the app/etc/local.xml file, you will find an XML-tag allowing you to do so.
Be carefull with HTTPS
Every time you use SSL between webserver and browser, the process of encrypting and decrypting is added on both sides. Also there is a slight overhead in bandwidth. The Magento site runs slightly faster if you disable SSL for all or just a few pages. However, this “win” is so small compared to the other wins on this page, that it should only be handled with caution. The gained bandwidth is non-vital, while almost all computers nowadays have CPU-power with which the encryption/decryption process takes place in microseconds.
Magento in the cloud
While CDNs could be used to optimize the bandwidth for static content, the Magento application could also be optimized in the same way by using cloud computing.
Memory-based filesystem for dynamic data
By storing dynamic data (var/cache, var/session) on a memory-based filesystem like RAMdisk or tmpfs, the disk I/O is decreased.
Disable Apache htaccess-files
When allowing the usage of htaccess-files, Apache needs to inspect every directory in its path to see if an htaccess-file is present. By moving the Apache configuration-directives from the htaccess-file to the VirtualHost configuration-file, and disabling htaccess-files all together, the Apache execution-time is decreased. This tip probably applies in most cases only to dedicated servers.
Use Nginx or Litespeed
While the Apache webserver is very flexible in its configurations, there are other webservers that are better optimized regarding memory usage: By replacing Apache with either Nginx or Litespeed, you could speed up the Magento scripts even more. Both webservers require manual configuration to allow for SEF URLs.
Use lazyload for images
When a page is loading, a visitor is often waiting for images on that page to load. Depending on the number and size of these images, this can take some time. Instead of loading images at once when the page is loaded, you can also add the LazyLoad JavaScript effect that makes sure only visible images (within the browser screen) are loaded, while remaining images are only loaded once the visitor scrolls down.
Minimize Apache logging
If Apache logging is minimized, less file operations are needed for every incoming request. Ofcourse less logging also means less insight when something goes wrong. An alternative is to optimize the filesystem on which Apache logs are stored. By default, Apache logs to the /var filesystem – but there’s no need to enable things like journalling for that filesystem.
ref: http://magentotutorialbeginners.blogspot.in/2014/05/magento-performance-improvement.html
If you have done all kind of server and caching optimization.Go to code level.
1) See are you loading a collection with in a foreach loop.
2) Try to optimize the code.
3) If you are loading a collection, filter the collection for the required attributes only.
4) Check for your product images.Use png images and try to keep images size under 500 KB.
5) Try commenting the custom functionality that you are providing on that page.And check with some tool like GTMetrix. How much time you achieve to load the page.Try to find out the code which is taking long time to load.
6) Keep only necessary attributes used for filter purpose in Layered navigation.
7) Try disabling unnecessary modules.
8) Try after enabling the compilation.
Hope these suggestions will work for you.
Related
I have a laravel website which is running on apache2 and it's running on multiple servers for multiple clients. There is only one web server where the website loads slowly. Now it's not loading slowly on every page load, it randomly loads slowly. Also after loading a page, that has loaded quickly, if you leave the site for say 5 minutes and begin to navigate to another page, the page loads slowly yet again.
Not sure if in fact it's apache that causes the slowness of the site, or if it's a third party plugin because as the page is loading it mentions m.stripe.com is loading and then on another page load, it could be another plugin loading.
Are there any tools that I can use to decipher this issue.
It is very difficult to answer why a Laravel website is slower. There are many reasons behind a slower Laravel application. You have to debug and take decisions where you need to improve in your application. Here a list I focus on when I develop an application.
Database
How may database query load on each page? you have to ensure any recursive query not exist. Make efficient data cache. Check queries takes a little time to execute.
Network Connection
If you are using different network connections with your Redis, database, queue then make sure those connections are well optimized and taking a little time to connect and serve data.
Cache Files
Make Cache you blade HTML files, routers, config files, and optimize those cache. Also, reduct autoloads services as much as possible.
Optimize your Images
Optimize your images. I recommend not to use local files. try to use a cloud service.
Minify CSS and JS file
You should minify your CSS and js files. and try to use libraries from CDN.
Use Queue
Use queue where possible like email send, PDF Generate...
Found that there where 2 A name records with different IP adresses for the same domain. I would have thought some error would have been raised by apache because of this, but it randomly selected the ip to serve the site and of course long load times for the ip that does not exist.
Minify your HTML, CSS, and Javascript. it's a great way to increase page spread. Depending on the IDE you use, you could install a minifier extension, use webpack to bundle your code, or use an online minifier like https://fixcode.org/minify
Use a CDN to load static files like scripts, images, and style sheet. you could also load all of your site via a CDN
you could also consider lazy loading parts of your script. especially in cases where you compile scripts with webpack
I'am trying to cache static files on my server using varnish cache. I configured varnish to cache files with image extensions (.jpg, .png etc.). After that I open my website and debug it with browser developer tools and check load time of all images on my site and there is no difference in load time when I use varnish or not. There is a "HIT" in X-Cache entry in response header so images are available in my cache right? Any idea what can I doing wrong?
Ps. I'm using nginx as a backend server
Varnish shoudln't have a real impact on static files, especially when they're located on a SSD. Very heavy frequented sites may be an exception, particulary when the data is stored on a (slow) HDD. Here you have a huge amout of I/O which can be highly reduced by caching the images in the ram with Varnish. But these might be some special cases where caching of static files make sense. For nginx is also noticeable that this is a very fast webserver which is very good at delivering static files.
The main purpose for Varnish is HTML generated by some server-side backend like PHP, ASP.NET, and other languages which are designed for this task. Compared with serving static files it's very time-sensitive to generate dynamic content: The backend hat to work for example on database-querys which are very common in web-applications today or parsing templates. Wordpress is a widespread CMS and also a good example for this: Several 10k of php-code are executed on a single request and depending on the amout of plugins 100 database-querys and more are no exception.
So there are a lot of things to do for the server - for every request. For you as a site-owner this has the following effects:
The loadtime of the page increases which will result in to problems when its too high:
Visitors are not very patient and they're going to leave your page when they're thinking it's not fast enough. A online-shop which is making $100k per day can be loss up to $2.5 million per year by a delay of 1 second (see https://blog.kissmetrics.com/loading-time/ for more information)
As a result of this its not unexpected that Google is using the loadtime as an indicator for your ranking (see http://www.shoutmeloud.com/google-started-ranking-websites-based-on-load-time-and-speed.html)
Depending on the amount of visitors it can cost you money for more or more powerfull servers
Varnish can store the HTML generated by a backend in the RAM or on a hard drive. Especially with a SSD the latter make sense. Depending of the structure and use of your site, Varnish will at least improve the speed of your page and maybe also save money because less (powerfull) servers will do the job.
When Varnish is used as fronted for dynamic-generated content, you'll notice a noticeable difference. Depending of the application even a big difference. I configured varnish for a vBulletin based forum and could improve the page load time about 5 times.
Summarizing you should focus on caching dynamic pages instead of static stuff like images or clientscript because in most cases the webserver is already good enough to deliver those things. When static content is really slow, this can probably improved by using a CDN. Or maybe your webserver is not well configured for optimal speed. Perhaps there is no lifetime defined for images as example. This can have a negative impact on performance, especially on larger ones. But without further about your application and configuration its not possible to investigate the performance-issue and give concret tipps how this can be enhanced.
Lately i have experienced something strange on my magento site. Sometimes my site is running slow and sometimes its acceptable.
Do you know some tools to test it a day long?My site is running on a VPS.
http://bit.ly/iefbw1
Love to know your results and reviews on the sites speed.
Thanks
To test the speed of a website + immediately get recommendations on what can be easily improved to reduce the loading time I use GTMetrix.
Some other pointers for speeding up Magento:
Install Varnish on your VPS + PageCache powered by Varnish
(Magento module)
Install APC for better caching
Make sure you have enabled Magento's default compilation feature
EDIT: As mentioned by ADM you must also optimize your MySQL and Apache (considering you are running apache2) configuration.
EDIT2: As general suggestion I suggest you to Google for "speed up Magento" and you will find hundreds of topics/articles covering this subject.
#Kenny you have a bit wrong approach, to start you have to check your apache config, unload all extra modules apache2ctl -M, same with php -m, then install apc or eaccelerator, then check your mysql config, it usually takes 2 days to see mysql real values, use mysqlreport perl script, it will show you whats going on with your database. then you go for Leverage browser caching, and only after you setup FPC. not sure if compilation 'must have' feature...
I have checked many Magento websites and find that most of them are very slow.
Have you ever checked why the Magento websites are very Slow. Let me show some reasons and the solution for making Magento Websites Faster.
Reasons why Magento websites are slower
Compilation Turned Off
Cache Problem
No Full Page Cache
Code looping
Flat Data not Enabled
Large Database
Memory Limit Too Low
Indexes are not updated
Not Using Memcached
Merge css and js files
Magento Htaccess Gzip, Mod_deflate, Performance Settings
Server
Solutions for Making Magento websites Faster
1. Compilation Turned Off : The Main reason due to the Installation of many modules.All activities of the system must go through modules and an action in Magento may involve some modules, thus the loading and running of Magento system are quite slow. So if you want to make your website faster then first enable the compilation.
Procedure for enabling the compilation
Login to the Admin panel
System -> Tools -> Compilation
-> Then Click on the Run Compilation Process
Cache Problem : Cache is not enabled in your system.
Procedure for enabling the Cache
System ->Cache Management
-> Select All -> then from action select options -> select Enable ->click Submit
No Full Page Cache : Full page cache is very important for any Magento based websites.
You can also use this free Magento extension for Full page Cache.
Lesti Full PAge Cache
Code looping : Their might be a reason for the Custom Code, may be some wrong code added so that it is looping and using the wrong code and looping database queries. If this is the problem then any developer can only solve the problem or use the default code.
Flat Data not Enabled : Flat Category and product data is very important for Magento Websites. Whether or not you should enable the Flat Data of Products and/or Categories varies depending on your Magento website structure.
If you have only dozens of products with many attributes, or have a few hundred products with only a few attributes/attribute variations, then flattening the products/categories may not impact the site speed significantly. On the other hand, if your website contained almost 1,000, or possibly several thousands of products, then it is almost always recommended to flatten your products. If these products are spread across multiple dozens of categories (and products aren’t duplicated across these categories), then flattening these categories would be suggested as well.
System -> Configuration -> Catalog -> Then in frontend tab you will find two settings as
Use flat catalog category and flat catalog product. Enables both the settings to yes.
Large Database : Due to large database size might decrease the performance of your server. So it is always recommended that you backup and delete the old and garbage data. If you have log enabled then what changes you will do every time in the Admin it will be stored ion the Admin, so if it is not necessary then either you can off the the record of the log or make the setting as it will delete all you logs at the end of the day or at the end of the week. if you have more than 1000 of visitors per day in your website then certainly it saved all the searched data in the database and other customer related info, if it is not so important then you can also delete and clean your database.
Procedure for enabling or disabling the logs in Magento
System -> Configuration -> Developer – > Click on log settings tab
Here you will find the setting for the log
Memory Limit Too Low : I have checked in some posts, they are saying that this may also be the reason and it should be improved to make Magento website faster.
There is a setting in your configuration files which sets the maximum amount of memory you can dedicate to PHP processes. Since Magento is a big memory hog, having this value be greater than 128mB can significantly bump up the time it takes Magento to perform operations.
what you are trying to do.
For more info about : Increasing Magento Speed and Loading Time
http://www.webtechnologycodes.com/increasing-magento-speed-and-loading-time/
I was studying about browser performance when loading static files and this doubt has come.
Some people say that use CDN static files (i.e. Google Code, jQuery
latest, AJAX CDN,...) is better for performance, because it requests
from another domain than the whole web page.
Other manner to improve the performance is to set the Expires header
equal to some months later, forcing the browser to cache the static
files and cutting down the requests.
I'm wondering which manner is the best, thinking about performance and
if I may combine both.
Ultimately it is better to employ both techniques if you are doing web performance optimization (WPO) of a site, also known as front-end optimization (FEO). They can work amazingly hand in hand. Although if I had to pick one over the other I'd definitely pick caching any day. In fact I'd say it's imperative that you setup proper resource caching for all web projects even if you are going to use a CDN.
Caching
Setting Expires headers and caching of resources is a must and should be done 100% of the time for your resources. There really is no excuse for not doing caching. On Apache this is super easy to config after enabling mod_expires.c and mod_headers.c. The HTML5 Boilerplate project has good implementation example in the .htaccess file and if your server is something else like nginx, lighttpd or IIS check out these other server configs.
Here's a good read if anyone is interested in learning about caching: Mark Nottingham's Caching Tutorial
Content Delivery Network
You mentioned Google Code, jQuery latest, AJAX CDN and I want to just touch on CDN in general including those you pay for and host your own resources on but the same applies if you are simply using the jquery hosted files cdn or loading something from http://cdnjs.com/ for example.
I would say a CDN is less important than setting server side header caching but a CDN can provide significant performance gains but your content delivery network performance will vary depending on the provider.
This is especially true if your traffic is a worldwide audience and the CDN provider has many worldwide edge/peer locations. It will also reduce your webhosting bandwidth significantly and cpu usage (a bit) since you're offloading some of the work to the CDN to deliver resources.
A CDN can, in some rarer cases, cause a negative impact on performance if the latency of the CDN ends up being slower then your server. Also if you over optimize and employ too much parallelization of resources (using multi subdomains like cdn1, cdn2, cdn3, etc) it is possible to end up slowing down the user experience and cause overhead with extra DNS lookups. A good balance is needed here.
One other negative impact that can happen is if the CDN is down. It has happened, and will happen again. This is more true with free CDN. If the CDN goes down for whatever reason, so does your site. It is yet another potential single point of failure (SPOF). For javascript resources you can get clever and load the resource from the CDN and should it fail, for whatever the case, then detect and load a local copy. Here's an example of loading jQuery from ajax.googleapis.com with a fallback (taken from the HTML5 Boilerplate):
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.8.2.min.js"><\/script>')</script>
Besides obvious free API resources out there (jquery, google api, etc) if you're using a CDN you may have to pay a fee for usage so it is going to add to hosting costs. Of course for some CDN you have to even pay extra to get access to certain locations, for example Asian nodes might be additional cost then North America.
For public applications, go for CDN.
Caching helps for repeated requests, but not for the first request.
To ensure fast load on first page visit use a CDN, chances are pretty good that the file is already cached by another site already.
As other have mentioned already CDN results are of course heavily cached too.
However if you have an intranet website you might want to host the files yourself as they typically load faster from an internal source than from a CDN.
You then also have the option to combine several files into one to reduce the number of requests.
A CDN has the benefit of providing multiple servers and automatically routing your traffic to the closest location to your client. This can result in faster delivery, optimized by location.
Also, static content doesn't require special application servers (like dynamic content) so for you to be able to offload it to a CDN means you completely reduce that traffic. A streaming video clip may be too big to cache or should not be cached. But you don't neccessarily want to support that bandwidth. A CDN will take on that traffic for you.
It is not always about the cache. A small application web server may just want to provide the dynamic content but needs a solution for the heavy hitting media that rarely changes. CDNs handle the scaling issue for you.
Agree with #Anthony_Hatzopoulos (+1)
CDN complements Caching; also in some cases, it will help optimize Caching directives.
For example, a company I work for has integrated behavior-learning algorithms into its CDN, to identify and dynamically cache generated objects.
Ordinarily, these objects would be un-Cachable (i.e. [Cache-Control: max-age=0] Http header). But in this case, the system is able to identify Caching possibilities and override original HTTP Header directions. (For example: a dynamically generated popular product that should be Cached, or popular Search result page that, while being generated dynamically, is still presented time over time in the same form to thousands of users).
And yes, before you ask, the system can also identify personalized data and very freshness, to prevent false positives... :)
Implementing such an algorithm was only possible due to a reverse-proxy CDN technology. This is an example of how CDN and Caching can complement each other, to create better and smarter acceleration solutions.
Above those experts quotes, the explanation are perfect to understand CDN tech and also cache
I would just provide my personal experience, I had worked on the joomla virtuemart site and unfortunately it will not allow update new joomla and virtuemart version cause it was too much customised fields in product pages, so once the visitor up to 900/DAY and lots user could not put their items in their basket because each time to called lots js and ajax called for order items takes too much time
After optimise the site, we decide to use CDN, then the performance is really getting good, along by record from gtmetrix, the first YSlow Score was 50% then after optimise + CDN it goes to 74%
https://gtmetrix.com/reports/www.florihana.com/jWlY35im
and from dashboard of CDN you could see which datacenter cost most and data charged most to get your improvement of marketing:
But yes to configure CDN it has to be careful of purge time and be balancing numbers of resource CDN cause if it down some problem you need to figure out which resource CDN cause
Hope this does help
I am currently combing through the Magento Performance White paper to optimize our Magento experience before the start of the holiday season. For 2 months we get heavy traffic spikes and want to make sure we are running smoothly. We are using Magento EE 1.8 and by default utilizing Full Page Cache. In addition to FPC I have enabled GZIP, Cache-Control headers, and made all the mySQL tuning adjustments recommended by the white paper. We will also be employing a CDN to serve static content.
We are currently using filesystem cache and I am confused on where APC would fall into this stack, if at all. Is it worth installing APC when we are using FPC already? I know that the Magento cache and APC cache are 2 different things so if I edit products which invalidate the Magento cache and need a refresh, do I in turn have to refresh the APC cache each time? Any help is appreciated!
APC is opcode cache geared towards PHP itself, FPC is more geared towards caching of content geared towards Magento itself. You should not need to refresh APC when making any product changes. Only FPC will need to be refreshed upon a backend type of edit, Magento will normally notify you about it being invaldated. APC will only need to be refreshed if a PHP or template (.phtml) file has been modified or changed. Keep in mind that APC stores cache for both CLI and Web based differently so employing some type of wget or cURL request to a custom internal URL that will clear the cache is best.
For example something like
system('wget --spider --quiet http://localhost/apc/clear_apc_cache.php');
Also, I'd highly recommend setting Varnish reverse proxy server in front of the stack as its performance is highly noticable on high traffic systems. You can also use memcache to keep database loads on checkout or dynamic requests outside of Varnish or FPC.
Getting Varnish To Work on Magento
Hope this helps!
You could use APC for your 2 level caching (see _getBackendOptions() in Mage_Core_Model_Cache). Though APC isn't the best option for that.
Depending on whether you run a single or multiple webnodes you could either choose for memcache (multiple webnodes) or tempfs (single webnode). With memcache configured in Magento you can still use APC to cache opcodes.
After editing a product you only need to hit the 'flush cache storage' in the cache management admin to invalidate all entries in memcache. APC doesn't need any flushing.
Where are you currently storing your sessions? If it's also on disk, you might also want to migrate them to tempfs or memcache. Though, be cautious when using memcache: use a different port/pool for your sessions than the one that is used for FPC. Otherwise you would flush all sessions when flushing memcache, logging out all users and flushing their carts in the progress.