In this article I will compare the four different built-in methods for Magento session management. These are: file-storage (the default), database, memcached and tmpfs-backed file-storage.
Admittedly, the tmpfs-backed file-storage method is only tenuously ‘built-in’, to use it you have to mount an in-memory filesystem but I wanted to benchmark it here anyway, and cover some of the benefits and limitations it offers.
So we’ll look firstly at each of the four methods being compared – particularly what they are good for (and not good for), and then I’ll get straight in to some benchmarks.
Not at all coincidentally, I’ll be using my new Magento Speed Testing tool to benchmark each session storage option. <plug> I just launched the premium subscription last week, you can now performance test your own Magento store from multiple data-centers globally for only $5/month. Give it a try on your own store, the results may surprise you. </plug>
30 Second Introduction to Sessions (and Session Storage)
When you go back to a Magento store a few days after browsing it, and the items you added to cart are still in the cart – that’s sessions!
Sessions are user-specific data that is stored on the server for each client. The server maps clients to their sessions with a cookie (or in dire, cross-domain cases, by a SID in the url).
How quickly data can be put in and got out of the session storage, how volatile it is, and how it is distributed in a clustered environment are all important considerations when choosing how to store sessions.
Thankfully Magento provides multiple options out-of-the-box. Let’s take a look at those…
Filesystem Session storage
Remember that innocuous setting during Magento install that asks you if you want to store your sessions on disk or in the database? Well if you are like me, you normally choose filesystem, not knowing any better and having never bothered to test or research the consequences (until now)
The benefits of file-based sessions for Magento are simplicity, stability and durability. It’s simple because you don’t have to do anything to set it up. It’s stable because most modern filesystems use journaling to make sure that in the event of a system crash your session data is consistent. It’s also durable, because a system restart will not cause you to lose your session data. Coming back to a webstore a week later and not having your items in your cart is annoying, right?
To enable file-based storage, choose it during installation or in your app/etc/local.xml file simply make sure you have a session_save tag like this:
<session_save><![CDATA[files]]></session_save>
Note: Look in app/etc/local.xml.additional for examples but ignore the comment about empty defaulting to files, you need the word files in there.
I have performance benchmarked filesystem storage in the Benchmark section below.
Database Session storage
Database session storage is the other storage type, the one you probably didn’t choose during install, and forgot to circle back round and find out if you should have. With database session storage the session data is stored in the Magento MySQL database. The connection used is the same as the core connection.
One of the key benefits of using database sessions is the clustered environment support. In a filesystem based session storage scheme, if you have more than one Magento frontend node in a cluster, they will need to share session data (unless you use a loadbalancer with sticky sessions) and the database gives you that capability quite easily.
Databases also have good stability and durability during crashes and reboots.
One of the problems with database session storage is that it adds more load to the database. On large catalog sites with many SKUs, or busy sites with lots of sessions, this can hurt the database performance.
To use the database for session storage simply have this in your local.xml:
<session_save><![CDATA[db]]></session_save>
Check out the benchmarks below to see how well database session storage performs.
Memcached Session storage
Memcached session storage takes a bit more setup than either of the previous two options, which is probably why it’s not considered a ‘normal’ option during Magento install. For starters you need a Memcached server running.
Once you have it up and running, the memcached session storage offers a number of benefits. Firstly it is very cluster friendly. The session data can be shared by any number of webnodes, and to make things even better you can easily add more memcached server nodes so that even your session storage can be scaled to handle many 1000′s of concurrent sessions*. Secondly, it is (or can be) separate of the database and web node entirely, which offloads the work of storing sessions from busy nodes in a high-traffic environment.
The memcached server is not tolerant to failures, if your system crashes or dies the data in memory will be lost. Being a separate server does allow the session storage to be kept running during a web or database node restart though – something you cannot do with the tmpfs storage option below.
In terms of speed, the memcached keeps all it’s data in memory (think a giant hashtable), so it should be fast. However, there is the overhead of an extra tcp connection, so we’ll see in the benchmark section if that has an effect or not.
Quick tip: sharing one memcached server with multiple stores is tricky, you need to use different ports or unix sockets. So if you need multiple stores and are not comfortable with that sort of socket setup, assume you may need to run a separate memcached instance for each store.
To use a memcached session store in Magento you’ll need to have this in your app/etc/local.xml:
<session_save><![CDATA[memcache]]></session_save> <session_save_path><![CDATA[tcp://localhost:11211?persistent=1&weight=2&timeout=10&retry_interval=10]]></session_save_path>
Note: Adjust the server:port in the url above to match your environment. I’m assuming you have memcached running.
(*then all you need is to own a webstore that has 1000′s of concurrent shoppers…)
tmpfs-backed Filesystem Session storage
This is not really a good idea for storing sessions, it’s highly volatile and unstable two things you probably don’t want for ecommerce store sessions. It’s also not scalable either as it relies on the machine’s physical memory, and you can only stick so much of that in – you might need it for the web server too. It will also not help at all in a clustered environment as it is machine specific.
Despite all it’s limitations I really wanted to test tmpfs sessions more out of curiosity than anything, I have a hunch that it will make quite a performance boost. Let’s see how it does in the benchmark section below.
If you’re keen to try this, I’ll assume you know what you’re doing on the system side of things. Mount var (or var/sessions) as a tmpfs and set Magento to use file based session storage like in the first option above.
Benchmarks
Benchmarks have been performed with Magento Speed Test on a lightly-optimized Magento 1.5 install with a few hundred products. The store was running on a combined web+DB node, EC2 large instance.
Here are the results of each sessions storage for varying numbers of concurrent users.
Session Storage Transaction throughput (Transactions/s) for a varying number of concurrent users
| Filesystem | Database | Memcached | tmpfs Filesystem | |
|---|---|---|---|---|
| 10 users | 4.79 | 3.56 | 4.02 | 5.10 |
| 30 users | 5.18 | 5.52 | 5.95 | 5.92 |
| 75 users | 5.83 | 5.29 | 5.64 | 5.84 |
Session Storage Average Response Time (s) for a varying number of concurrent users
| Filesystem | Database | Memcached | tmpfs Filesystem | |
|---|---|---|---|---|
| 10 users | 1.53 | 2.14 | 1.83 | 1.42 |
| 30 users | 4.59 | 4.33 | 4.11 | 4.07 |
| 75 users | 10.23 | 11.33 | 10.52 | 10.33 |
Conclusion
I’ve looked at the benefits and limitations of each Magento session storage option, and tested the performance of each with varying numbers of concurrent users.
I was a quite surprised at how little each option affected the store’s performance. I guess it shows you that session storage is not so much about performance as it is about stability, and suitability for your requirements (cluster vs non-cluster, large catalog database etc).
I am working on a follow up article that simulates the effect of a week’s worth of sessions (in a long-lived session setup) because I have a hunch that the filesystem begins to slow down as the number of sessions being stored gets higher. It will be interesting to see if that is true and if it is also true for the DB or memcached options.
I hope this article will help you to make an informed decision which option to choose during install, and understand what can be achieved by tweaking the settings.
On an unrelated note; my latest round of changes including the ‘Run this test again’ button on Magento Speed Test make repeatably testing small performance tweaks like this on a store really easy. Try it out on your own site for free!
Lastly, it’s been a while since I posted an article here at Magebase, I hope this article is on the mark for our many new readers, any feedback most welcome.
Originally published on magebase.com. Copyright © 2011 Magebase - All Rights Reserved.
Proud members of the 
Great, insightful, article. Appreciate it.
[...] inzwischen sind Videos von Magento-Imagine-Sessions online.Ashley Schroder: welchen Speicher soll man für Sessions wählen und warum?H&O: eine sehr sehr schicke Anpassung des Magento-Bezahlvorgangs – nur [...]
[...] These are: file-storage (the default), database, memcached and tmpfs-backed file-storage. Link – Trackbacks source: Topsy – magento tutorial – Magento Session Storage: Which to [...]
[...] a month since I last wrote anything, but I dropped an article on Magebase earlier this month about Magento Session storage, have you read [...]
This was a really awesome read. I am installing Magento right now and debated about the session storage. I set it to database.
Hi , Is there any way that i can configure separate database connection for session management . So in this way i can store session management information in separate database and put less load on my catalog database in magento.
It was really a helpful content. Keep sharing…
Content covered is great!!!!!!!111
[...] http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/ Related post: Magento : Optimization [...]
Well written article – but a little on the useless side.
You used a test tool that doesn’t really support session creation (cookie support). Apache bench will test pure throughput, but will not have any bearing on sessions. You would be better served using Apache jMeter with a proper real-world simulation (link clicks, cookie support, mutli-page viewing per session).
Then a top of that, you will really not notice an issue until you start getting into the tens of thousands of sessions. So a small concurrency test over a short period of time will not highlight anything.
With file based sessions, they will be auto-pruned by the PHP session clean-up cron – so the files are likely to be deleted within ~7200 seconds of creation. So even on a busy site (30k uniques per day), there usually only around 4,000 session files in ./var/session – which is nothing for a Linux server.
With Memcache sessions, TCP/IP is the only overhead – which for a single-server deployment, would make it slower than file based. So then, you would use a unix socket instead, which removes that overhead and gives better security. But even still, your customer sessions will be truncated/limited as to the amount of RAM you can allocate. The average Magento session is 4Kb – so you’ll be able to support 256 active sessions, per MB you allocate. So be sure to set an appropriate limit to avoid customers randomly losing cart/session. And also bear in mind, a Memcache daemon restart will wipe out all existing sessions (BAD!).
The with DB, the default prune expiration setting is a mighty 1 week, so with the above store size as an example (30k uniques per day), you’ll be looking at a DB table size for core_cache_session of around 7GB – which will grind your store to a complete halt, for almost every session based operation.
From experience of hosting both large (230k unique visitors per day) and small (<1k unique visitors per day) stores, our recommendation is:
Single-server deployment = files
Multi-server deployment = memcache (using a separate TCP/IP instance from your main Magento cache)
Oh, furthermore, no-one should ever be using tmpfs for **anything** on Magento. Be it cache storage, session storage or anything else.
The performance difference is negligible to using disk alone (unless your hosting provider is using 10 year old 4,200 RPM HDDs). The Linux file system cache will appropriately place the correct files into the RAM cache by itself as demand increases for them.
It should be noted that the database session handler does not implement locking whereas both memcache and file do. So, using database it would be possible for one request to overwrite the session of another request. Probably not a huge deal since the cart is stored separately in the database, but it could cause flash messages to be lost perhaps.
Hmm… ( Note my experience is primarily with CE ). These figures just don’t gel with my experience of administering servers running magento. You can literally *feel* the difference on a small/med linux server when all else is tuned correctly and you swap between either db and file and tmpfs support. It’s just plain much snappier. You’d need at least 25% difference to notice that.
As a quick test, set it up for tmpfs, and then screw with the permissions on var/session to it has to write session data to /tmp instead. The overhead of a failed file open is trivial to the file creation/access itself. The overhead of creating a file is extremely heavy: 20 years ago I doubled the speed of a process where files were used as flags just by using a hard link to a pre-existing file instead – it wouldn’t happen now but it is a good example. That’s part of what you’re streamlining by using an ultrafast disk. No amount of buffering will change that. The rest, well sessions aren’t usually around long enough to efficiently use the file buffers. It’s the initial access time of a site that you’re really improving.
The way I see it, running a website is 99% readonly stuff. If you can serve all of that from memory then you’re going to have a far more performant site than having to go to disk to deliver content. What do you need to write? Logs and purchases… what else ( ignoring the admin side for now )?? Given the current cost of memory ( I think I’ve just paid NZ$25 for 4GB ), a base build of 2GB will cover most shops, and to 4GB is little hardship.
Without a doubt, the 3 most successful performance upgrades to a linux server supporting a Magento CE site are (in order):
1. Use PHP in FPM mode, integrating APC both with Magento FE and PHP.
2. Replace apache with nginx (ESPECIALLY if running in SuPHP mode )
3. Put sessions on a tmpfs partition.
(Without them you see the 5 second product display that’s so prevalent in poorly served Magento sites)
There’s plenty more that’ll improve further ( I’m assuming server / infrastructure tuning as a given ), but the return is diminishing fast.
What’s the problem with tmpfs? It’s solid as a rock, and blisteringly fast (as long as it doesn’t get swapped out). OK it doesn’t survive a reboot… unless you script for it… just add a bit of code to the web server start / stop blocks. If you have problems with your server’s reliability, then losing your sessions is the last of your problems. IIRC PHP expires them after 24 minutes or somesuch anyway by default. I know risk perception is a purely personal thing, but, based on my experience, this is really low. Way below not mirroring your disks, for example.
Steve
I agree with Sonassi (Ben?) that using tmpfs is a negligible performance improvement and not worth the risk of session losses or out of memory problems. If you’re getting many uniques per day, you simply can’t risk losing that many sessions since it will certainly lead to lost sales. Also if you get a sudden spike you can’t risk running out of space on the tmpfs and the bigger your site gets the more likely you are to have large spikes in traffic. The regular files session storage is good for single-server setups and I don’t really recommend changing it until you move to a cluster at which point I don’t like any of the packaged Magento options. Ben, do you have a way to dump Memcached so it can be restored in case a reboot is needed? E.g, ram upgrade.
Yes, its Ben here
offers nothing, absolutely nothing over the “standard” storage mechanisms. That applies to ./var/cache and./var/sessions alike. Unless of course, you have a critically wrong issue with your I/O subsystem – SAN mounted over 10BaseT
It adds unnecessary complication and limits scalability. I’m not negating the speed and stability advantages it might have – but it really isn’t appropriate. Its just a last ditch attempt for people trying to speed up Magento and looking at completely the wrong bottleneck (Magento is not bound by I/O!)
RE: Memcached survivability, we’ve got a few approaches in operation.
Repcached – http://repcached.lab.klab.org/ (over HAProxy)
No replication/redundancy – Power it down during the wee hours
Its nice that Memcached V3 (BETA) has redundancy built in, but ZF doesn’t really handle it properly. There’s also some pretty cool methods out there for Memcached dumping (http://www.dctrwatson.com/2010/12/how-to-dump-memcache-keyvalue-pairs-fast/).
It is really client dependant, but even our largest client (230k daily uniques) – we just use a bit of common sense monitoring and planning infrastructure changes.
–
Off topic, but please do not get me started on Nginx vs Apache (vs Litespeed vs Lighttpd) – when it comes to raw PHP/Magento performance, PHP is the bottleneck, not the HTTP server.
The *only* time when Nginx will outperform Apache (for pure benchmarking concurrency) is when Apache is using mod_php and spawing new threads is a cumbersome process. But when you are using fCGI/FPM – Apache will have the same throughput … and support on-the-fly htaccess style modifications.
And Eaccelerator will outperform APC by about 6-10% – just make sure you exclude the appropriate classes and you have no compatibility issues.
–
Back on topic, choosing the storage mechanism is an easy decision with Magento.
Single server (unless you’ve got one of those Supermicro 8 way E7 monsters), you’re likely to have a “smaller” site anyway – and file storage will performance and scale perfectly.
Multi server – you’ve got 3 options.
1. DB storage – but unfortunately Varien’s implementation of this isn’t great and the core_session table will grow and grow and grow, as well as tying up your DB server, and adding TCP/IP overheads.
2. File storage – yes, it is possible, over NFS/SAN/GlusterFS – but add in the overheads of these replication techniques, PHP FLOCK issues … it becomes impossible to use.
3. Memcache – worldwide recognised as a distributed session/data storage mechanism. With a variety of different means of providing replication. Its nice, quick, stable and works out of the box.
Simples.
1. On topic.
I would like to see evidence. I’m finding it hard to even design, let alone generate tests to properly exercise Magento session management – I think I’d need ab running concurrently from dozens of ip addresses with a number of crafted templates before it would really be a meaningful benchmark. Single pages / sources are no good. That’s why I’ve only provided anecdotal evidence ( and my disks are mirrored SAS! ).
These days, I see it’s pretty simple to run 100+k uniques / day + 100k+ products on run of the mill servers ( and handle spikes far higher than that using a cdn to perform the gruntwork ), now that multiple 6 core/12 thread CPU / 64GB / RAID 10 1U servers are easily available. Most clustered solutions I’ve seen lately have been swayed by the vmware promise of utra high uptime / transparent upgrades. Unfortunately, at a price where a mirrored backup server would be just as reliable, and much, much cheaper!
This is why I see this as beiing important enough a topic to keep banging on about!
2. Off topic.
I feel that you are at odds with a large number of companies who now use nginx to host their sites – whether just as a front end proxying to apache or native is difficult to assess (although if it’s not native, it sounds like just a CV stuffing process and little else useful). These include…
http://www.magentocommerce.com
http://www.linode.com
http://www.tumblr.com
http://stackoverflow.com (allegedly)
http://www.stuff.co.nz (well, it’s busy for New Zealand)
… and of course Apache themselves admit it, with the release of 2.4 ( after a delay of XP’esque proportions ), including comments like
“We also show that as far as true performance is based – real-world performance as seen by the end-user- 2.4 is as fast, and even faster than some of the servers who may be “better” known as being “fast”, like nginx,” Jim Jagielski, President of the ASF. ( note the quotes, but it *is* public perception at least ).
and, of course me (:
Sure the ultimate bottleneck is not the web server, but look at the resources that Apache consumes in comparison just to serve php. When you’re talking about the vast majority of generic ecommerce sites running on (for example, my minimum specs) a 2GB/4 vCPU VPS, these resources really do count… they can be used in far better ways. Especially when most of these sites are being run through dashboards which do their level best to enforce a generic and totally unsatisfactory configuration for Magento ( but that’s a rant for another day! ). I’ve even managed to get sort of acceptable performance out of a small Amazon instance – the image is out there somewhere… not particularly well tuned though.
I would also hesitate to recommend eAccelerator over APC, as no releases have been made in about 2 years, and their site can’t even forward the generally published http: link to the live https: one.
@Steve I don’t want to turn this article into a debate – so I’ll make this my last response. But I will happily continue it over email if you want.
1. With all due respect, if you are only aware of A/B – you aren’t qualified to make these statements. Apache Bench/Siege are not remotely usefully as a true benchmarking, or real-world simulation tests. They probe a single HTTP request, with no true session support and really only highlight how good a job your OPCode cache/disk buffer is doing.
We use Apache jMeter for testing, with client instances running on multiple physical services. With hand-build profiles to simulate the entire customer browsing and checkout proccess. We even factor in random searches, random amounts of page visits and truly replicate the various types of shoppers you would expect to see:
Window shoppers (view many products, even add items to basket, never attempt checkout, generally hit 5-9 pages per visit)
Sale (view many products, add a few, and complete checkout, generally hit 5 pages per visit)
Wishlist shoppers (log in to account, add products to wishlist, generally hit 8-12 pages per visit)
The types of pages they visit are drummed from a list of URLs, comprising of search, search+layered nav, category, product, customer account and multiple address checkout (its too hard to re-enact the OPC accordion).
I can supply a sample test config if you like and you can get a feel for true benchmarking using jMeter. If you are at all serious about performance optimisation, ditch Siege/AB and use the right tool for the job.
Based on experience, hosting a 100k+ unique visitor Magento store isn’t a simple task, nor can it be achieved with just run-of-the-mill set ups. I’m not sure why you mentioned a CDN, as it plays no role whatsoever in improving “Magento” performance – it only becomes valuable on high traffic sites that serve a huge amount of static media.
2.Are you REALLY going to use MagentoCommerce.com to justify the use of Nginx – it is one of the slowest, most unreliable websites we have the misfortune to have to use.
Linode – its not Magento
Tumblr – its not Magento
Stackoverflow – its not Magento
Stuff.co.nz – its not Magento
And this is the main reason why the majority of companies are wrong about true Magento performance – heck, Rackspace and Peer1 (the enterprise partners) recommend separate DB/Web servers to improve performance, but anyone who has ever actually properly bench and soak tested a Magento store knows that it is not bound by MySQL, most of our MySQL servers (for shared and dedicated hosting alike), do little to nothing.
In terms of resources – you are correct. An Apache worker will consume ~30MB regardless of what modules are enabled, whereas an Nginx worker will use about 12MB. But as you said, RAM is cheap. But even on the “30k per day example”, you’ll only have about 20 threads active, whilst PHP-FPM/fCGI does the grunt work.
I’m going to give you (and anyone else reading) a loose analogy – a (Magento) fast-food restaurant.
The customer (at the drive-through), is the customer on your web store.
The till operator (who sits on a chair and hands you the bag of food through the window – Web Server)
The chef (who cooks the meals – PHP)
The su-chef (who prepares the ingredients for the meals – server subsystem)
The average meal takes 2 minutes to prepare, 12 minutes to cook and 5 seconds to hand to the customer.
Now, lets take the perception of Apache (an overweight, unfit, slow window attendant), the kitchen takes 14 minutes to make the meal, hands it to him – then he passes it to you. He is only passing 1 bag, every 14 minutes, a pretty easy job.
But, we want the business to run faster – so we’ll fire Apache and replace him with Nginx (the Ivan Drago of fast-food service).
The kitchen takes 14 minutes to prepare a meal and Nginx hands the bag of food at lightening pace to you.
But hold on, it has still taken 14 minutes for the customer to get their meal – even though we’ve got the fastest delivery staff available.
That’s because it was never the bloke handing you the food that was the bottleneck; in-fact – the “slow” person added value by speaking the native language of kitchen staff and being able to receive updates (.htaccess support). Whereas Ivan speaks russian and it requires a translator to stop him working and tell him new updates (edit Nginx config, reload etc. yada yada yada).
Nginx won’t improve performance over Apache for Magento, we have proved in time and time again in bench testing.
Nginx/Apache are the front men – and in the case of Magento hosting are no more than marketing tools. It is easy to show how fast Nginx/Lighttpd/Litespeed are over Apache in terms of reqs/s. On a given server, Apache is good for around 12k requests per second, Nginx can surpass this with relative ease – hitting around 16k requests per second – but this is for **static content**. When you start to hit 12 THOUSAND **PHP** requests per second – then its time to consider dumping Apache, but until then, it will perform par-for-par with anything else.
If you’re building a CDN, Nginx is a great choice
If you want a static file proxy, Nginx is a great choice (heck, we use it ourselves)
…
If you want a flexible, high performance web server for Magento, Apache is just as good a choice – as at the end of the day, PHP (the chef) is slowing you down, not the web server – never the webserver.
I do wish people would let go of the traditional means to trying to speed up web applications – they just do not apply to Magento.
We’re a small company, but have unquestionable experience in this field. We test server configurations and different techniques daily – we speak from real experience, we eat, sleep and breathe Magento.
What bearing does recency/age or dead links have for performance? The fastest airplane ever made is the SR-71 Blackbird – that is 50 years old. Does that mean anything newer than that is faster?
Just perform your own testing and you’ll soon see that Eaccelerator 0.9.6 will beat APC every single time.
Even for raw Magento performance, PHP 5.2.17 will beat PHP 5.3.7.
Ben, your analogy is perfect.
Until it was taken out of service, the SR-71 was maintained and upgraded regardless of cost ( and still leaked fuel on the ground ). Seeing as PHP is a moving target ( and 5.2 was EOL’d Christmas 2010 ), subject to security breaches with saddening regularity, then the tools that use it require the same level of diligence.
For me, using a product in that state is a far greater risk than using tmpfs.
BTW the SR-71 was the fastest jet-powered aircraft. Whether you consider the X-15 to be an aeroplane is another debate altogether (:
Great discussion guys, thanks for contributing! Let’s hope the Sonassi team can share some of their thoughts on the tmpfs.
@Colin – why do you think that memcached is any safer than tmpfs? It has a max memory size just the same as tmpfs, and will lose stuff when full / server fails – and both need configuring / monitoring / constantly managing for best results. Also, I haven’t seen a config for mage anywhere that uses named sockets to access it, so you’ve added on the overhead of a TCP stack.
And, of course dumping tmpfs is a trivial task. If you’re really paranoid, then saving it every minute would be no big deal. The only way I know of to keep memcache data is to replicate it, for which you’ll need that TCP stack again.
As I said before, I condsider tmpfs to be an extremely low risk, please explain why you find memcached to be a lesser one?
Steve, I only suggested memcached over plain filesystem if you are using a cluster and only then because the other cluster-friendly options suck. For single servers I stick with the filesystem. Of the out-of-the-box options for a cluster memcached is the best one (since it is the only one that fully supports locking and doesn’t abuse your database). I really don’t like memcached much either, which is why I’m working on a MongoDb-based handler that plugs into Magento and uses opportunistic locking.
Overall, I don’t think reading and writing one session file per request is going to have much impact on perceivable performance *until* whatever system you are using is pushed past it’s practical limits. For the filesystem the practical limits are very stable long after the filesystem’s cache is full. For tmpfs the sessions will start being copied into swap at which point tmpfs will perform much worse than the filesystem. For memcached you start losing LRU sessions but performance will not degrade. For the MySQL database, I’m guessing everything would just crash and burn. Which of those options sounds the best to you?
Do you know how to configure the xml file to store session in file but at the same time store cache in memcache? It seems that it is all or nothing for each of the storage option.
@Ryan, you set the session data to be stored in file at ( both snippets appear in the global block )
I usually use a 2 level cache – basic starting config:
<cache> <backend>Apc</backend> <prefix>magento</prefix> <slow_backend>Memcached</slow_backend> <fast_backend>Apc</fast_backend> <slow_backend_options> <servers><!-- The code supports using more than 1 server but it seems to hurt performance --> <server> <host><![CDATA[127.0.0.1]]></host> <port><![CDATA[11211]]></port> <persistent><![CDATA[1]]></persistent> </server> </servers> <compression><![CDATA[]]></compression> <cache_dir><![CDATA[]]></cache_dir> <hashed_directory_level><![CDATA[]]></hashed_directory_level> <hashed_directory_umask><![CDATA[]]></hashed_directory_umask> <file_name_prefix><![CDATA[]]></file_name_prefix> </slow_backend_options> <memcached> <servers> <server> <host><![CDATA[127.0.0.1]]></host> <port><![CDATA[11211]]></port> <persistent><![CDATA[1]]></persistent> </server> </servers> <compression><![CDATA[]]></compression> <cache_dir><![CDATA[]]></cache_dir> <hashed_directory_level><![CDATA[]]></hashed_directory_level> <hashed_directory_umask><![CDATA[]]></hashed_directory_umask> <file_name_prefix><![CDATA[]]></file_name_prefix> </memcached> </cache>Even though I see a fairly ordinary site storing 80MB of data in memcache, but only seems to deliver back at < 10kB/s – so the actual difference between that and straight single level APC cache may be minimal, for a fair bit of effort and extra administration.
I still stand by my assertion – irrespective of others belief in the generic file system cache! – that tmpfs makes a fair difference… in fact in back-to-back tests of a well used ( in developmental terms! ) 1.4.1 site on dedicated hardware ( loads of spare mem, cpu power ), that it improved a random product page load by over 20%.
Steve, I benchmarked files vs tmpfs a while back and here is what I found:
Debian 6.0, PHP 5.3, RAID 1 250Gb SATA enterprise class drives, Dual E5620, 12Gb RAM
Read performance: Nearly identical (due to fs cache no doubt)
Write performance: Decent improvement (but was already quite fast)
Tag clean performance: Minor improvement (still every bit as horrendous for all practical purposes)
I don’t remember the exact numbers but I pretty quickly determined the pros did not outweigh the cons, especially for sessions. I don’t know what testing method you used to arrive at 20% page load improvement, but I’d venture to say if you run a sound benchmark you will have similar results to mine. With regard to sessions, we are talking about one file read and one file write per page load so for that to make *any* perceptible difference you’d have to have some painfully slow disks..
Benchmark tool: https://github.com/colinmollenhour/magento-cache-benchmark
If you are interested, here are the slides from my presentation on Zend_Cache backends at Imagine 2012: http://info.magento.com/rs/magentocommerce/images/imagine2012-tech-cache-showdown.pdf
@Colin. I see your paper is primarily designed to forward the use of redis as a caching mechanism. Whilst this quite possibly a really good idea ( I haven’t checked ), the findings are not necessarily relevant, and the amount of other, configurable software that is in the way means I’d have to spend a lot of time in analysing your results to have a valid opinion. Additionally, I see no display on the amount of work the server itself is doing, and what resources are in use – probably *the* most important factors in choosing your production stack.
My testing – as I said – is ‘real world’, I used a web performance testing service local to the server ( well, Sydney to Christchurch is a latency of c.40ms but that’s pretty real world for the Antipodes too ), and used it to time the delivery of a random page. Hardware is a Dell R-310, quad core, 16GB, Raid1 SAS disks. Network connectivity to the internet is 100mbit. Software is Squeeze 6.0.4, Percona DB, PHP 5.3 in fpm mode, nginx 1.2.0. All resources have been carefully tuned.
The website I used was a pretty standard 1.4.2 based Mage site, which had undergone a fair bit of development in it’s lifetime ( I think it’s having another spurt right now! ), with handful of common plugins. A typical, rather than expertly designed and tuned websystem.
Why do I take this approach? Well, because in my experience ( I wrote my first test harness for a British Telecom 25 project years ago ), a lab approach to testing will only go so far. One thing that is rarely accounted for is the environment the finished product runs in – eg ‘slow’ communications between client and server, and how/when the browser will accept information from the server.
Because of this, the ‘best’ solution for the visitor to a website may not be the best result in the lab.
Back to back tests with and without var/cache and var/session running on tmpfs filesystems with a completely empty cache.
Before: 7.3s
After: 5.8s
Subsequent access with a full cache
Before: 2.9s
After: 2.5s
( I have URLs, but have not requested permission to publish from the owner )
Unfortunately the system had to go live rather faster than expected, so I didn’t have the chance to investigate further. I think that the real gains are in the session data, as the admin backend is appreciably speeded up as well – and that uses it a lot more.
I would recommend that a real world approach be used in conjunction with lab testing, and that a close eye be kept on the system resources whilst the test is in progress – you never perfectly tune a server: you’re just moving the bottleneck around (:
Steve
@Steve your testing is flawed, you need to use a clean demo store, your store could be reading/writing megabytes to sessions for all we know – which would explain the difference.
We host over 80 fairly large Magento stores, between 3k to 200k daily unique visitors – we spend exhaustive amounts of time testing and bench marking and I can tell with (with extreme confidence) the tmpfs myth is just that, a myth.
@Sonassi. No it’s not. You’re wrong. Not only were the results repeatable, I was closely monitoring the server as well. Like I said, I’ve done this kind of thing once or twice before… we’re talking 20+% here. If you find no difference, then you probably need to look more closely at your server tuning – there’s a different bottleneck masking your results.
Where’s your demo site, and what are the specs? Let’s see how fast it is!
@steve http://demo.sonassi.com – its sat on a server with 10 other live stores in a shared hosting environment of 2.4GHz QC / 12GB RAM / 2x SATA HDD
I/O isn’t a bottleneck for *any aspect* of Magento – hence why we can use SATA disks without issue, even in a shared environment.
Beyond that, the Linux disk buffer/cache takes care of caching frequently accessed files – making session read times negligible. Session writes pose no issue whatsoever, for a normal store – however, if you’ve got some badly written extensions writing more to sessions than they should be doing, it would explain why you saw a performance benefit.
If you are having to resort to ramdisks to get better performance – then you have a fairly critical I/O bottleneck. It sounds like you’ve got a partition alignment issue/inappropriate raid stripe size/badly tuned OS; run iostat and see for yourself. If the blocks read/written differ between the disk itself, partition, device mapper and filesystem – you’ve got I/O issues.
I would strongly suggest getting in touch with us, we can offer some consultative services to set up your server properly.
@Sonassi, given that you’re demoing a 1.4.0.0 site, comparing to my demo site @ magento.greengecko.co.nz ( which is set up for ultra security, certainly not performance ) shows the only real difference is probably in DNS performance – always a problem here in the Antipodes.
Nope, no alignment issues, raid stripe has been tuned, very well tuned OS thankyou. IO is trivial throughout testing, as you’d expect. I’m running stats all the time during the first and last testing runs – none in the intermediate ones.
To expect the GP disk cache to work as well as a dedicated shared memory segment is not quite right. tmpfs backed systems are locked in memory, which the cache contents are not – for example an image on a tmpfs filesystem will be available 10 minutes after it’s last access, whereas it’ll be long gone from cache, for example. Tuning the kernel vm parameters ( amongst others ) will make some difference, but will never, ever be as good – especially for the regular session upates that Zend makes, and will be far, far more wasteful on your available resources.
I really can’t see any point in contacting you… until you make anything other than unfounded generalised assertions (:
@Steve – I think we’ll just agree to disagree then.
If you have to resort to using a ramdisk to achieve better performance, it is an I/O issue.
Either a) you are writing too much data to individual session files, causing a bottleneck or b) you have an I/O issue or c) your test tool is giving false results.
I would love to see what you are using for testing to show such a significant difference. We use jMeter and it doesn’t get more realistic than that – and session storage pure and simply is not an issue – the CPU caps out for PHP processing before I/O bottlenecks *anything*.
On a quad core server, you’ll see an average of about 12 requests per second (across the board of search/category view/product view/checkout), and 12 session read/writes per second is negligible.
I truly cannot understand where you are getting your numbers from.
@Sonassi
I’ve been trying to work out how you can accurately test a web app in real life with jMeter. There seem to be 2 major problems if I remember correctly ( well, I checked the first one (: ).
1. To quote: “JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the Javascript found in HTML pages. Nor does it render the HTML pages as a browser does”. Given that there is often in excess of 1MB of JS loaded into a Magento page, not actioning it can somewhat skew the result, and thereby lessens it’s relevance to the end users perception.
2. last time I looked, It didn’t support distributed testing… well, it could handle a few clients on the same subnet.
It is a year or more since I’ve looked closely at it – my native distrust of anything Java clouds my vision – so things may have changed since then.
Personally, my serious testing uses handcrafted PhantomJS scripts, which are run concurrently from about a dozen servers, distributed worldwide. I then add a pretend load to the server locally using ab and monitor changes at both the client and server end.
My results won’t show the theoretical maximum the server can provide, but I feel that it does give me a better idea of what the customers are going to get – which I consider to be far more important.
I have a feeling that your understanding of how the buffer cache and tmpfs file systems work / interact is flawed, which may well be at the core of our disagreement.
@Steve.
JS rendering is client side, and has *nothing* to do with *any* server-side tuning/optimisation/changes. It is irrelevant.
It does support distributed testing. Google jMeter remote / jMeter server – distributed/remote testing is the *only* way to generate significant load to adequately stress a web cluster.
–
I cannot continue this discussion any longer; I’ll stop feeding the troll.
@Sonassi.
So your testing skips all load generated by AJAX calls, and that’s ok? And you have the resource to generate a hundred or more concurrent, geographically disparate clients to load the server up?
I had hoped that you’d be up for swapping ideas that readers could try to improve performance of their websites, and have happily offered my findings. In response, your heavy handed statements with no backing – often factually flawed – just frustrate.
I’ll let the reader decide who the troll is.
Apologies Ashely for rather hijacking this thread. I’m off now.
Steve, I already sent you a private email to discuss – why do you continue to debate on here? I am astonished that you are intentionally trying to discredit Sonassi – and as much as I don’t want to rise to this, your non-professional attitude and responses demand it.
To answer your questions…
No, we don’t perform worldwide testing – ever.
That would be completely and utterly pointless. The massive latency shift would render any results worthless – and no server-level changes would ever change response time of cross continent interconnects. Anything beyond our edge routers is outside of our control – and as a result, irrelevant to testing a server-level configuration change.
If you are trying to benchmark a specific server configuration – the **only** place you should be testing, is locally, or within a low-latency, high speed LAN (1Gbit+).
Magento very little, nigh on zero Ajax calls in the majority of the front-end, with the exclusion of the checkout – and in that instance, our test posts individually to each controller within the checkout phase. It is easy to emulate Ajax with HTTP requests.
My backing and worth, is working for a successful specialist Magento hosting and development agency for 4 years; with a proven track record with hundreds of happy customers and dozens of own own high performance Magento servers.
What would you like me to do exactly? Its your responsibility to prove that tmpfs makes a difference – as no other poster on here, Colin M or I, can see that it does; not in our tests at least. Hence why I asked you testing method.
And for completeness, to quote the email for other readers.
–
Hi Steve,
I thought I’d email you as we’re going to come across petty and childish if our dispute continues on that comment thread.
When testing servers, we use jMeter **because** it doesn’t render like a browser, we are trying to test server load – not measure template render time. It is the only application that can generate enough “proper” traffic to load test our 10+ server clusters, and even then it requires a few powerful servers just to run the testing.
I can send you over a sample profile if you want and you can try it for yourself.
Regarding tmpfs, we own over 50 (pretty powerful) servers and host over 100 Magento stores. We test new hardware and configurations continuously and one thing we don’t use on any production is tmpfs. We wrote a guide about 2.5 years ago on what worked and what didn’t in terms of improving performance and that is still accurate today.
You have misunderstood me, I do not think the disk buffer is a replacement for tmpfs, my point was that it isn’t necessary to load files directly into locked memory for fast read access times – the OS will do that itself indirectly via the disk buffer, I digress.
I’m trying not to belittle your Linux system administration experience; but I out-and-out cannot understand how you could ever see a performance improvement using tmpfs for session data, the read/write is so infrequent (on a stock Magento store) that it would make no difference whatsoever. Which is why I questioned if your template is writing more to the session than it should be – it wouldn’t be the first time I’ve seen it, and would explain your performance difference.
But in the real-world, I/O plainly is not an issue for Magento and during load testing, you would see that. Most time is spent in CPU for PHP, not bound/waiting on I/O – be it session or core file access. It is another reason why compiler doesn’t really offer that much in terms of a performance boost – unless you are using NFS/SAN.
NFS has funky support for F_LOCK, which is why session/cache access can be brutally slow – but it is unlikely you are using NFS, as it would be strange to use a network share for file access, but use a local session storage method. Another reason why I cannot understand your performance gains.
I wasn’t joking when I said I could have a look into your issue for you. tmpfs shouldn’t improve performance on a ‘typical’ Magento store – which would indicate you have a template/code issue (or fatal issues with I/O).
@Sonassi,
I have to disagree with you on Nginx, Performance testing done by Peer1 and Magento has proven that Nginx provides better long term performance for larger busy websites by reducing the cost of resources required per 1000 visitors versus Apache.
Additionally I cannot see anything wrong with someone using tmpfs on a single server, Magento recommends Memcache for clustered enviroments to store sessions and cache and that is nothing more then a glorified tmpfs…
This is both one of the most interesting discussions on Magento performance I have had the pleasure to read in some time. Next round on me guys!
[...] Use the correct session storage, choose file system or database (during setup). Most installations should use “file system” because it’s faster and doesn’t cause the database to grow. But if your site will run on multiple servers, you should select “database” so that a user’s session data is available regardless of which server his/her request is served from. More info about this from Ashley Schroderat Magebase.com. [...]
[...] Use the correct session storage, choose file system or database (during setup). Most installations should use “file system” because it’s faster and doesn’t cause the database to grow. But if your site will run on multiple servers, you should select “database” so that a user’s session data is available regardless of which server his/her request is served from. More info about this from Ashley Schroderat Magebase.com. [...]
[...] Use o armazenamento de sessão correta, escolha do sistema de arquivos ou banco de dados (durante a instalação). A maioria das instalações deve usar "sistema de arquivos" porque é mais rápido e não fazer com que o banco de dados para crescer. Mas se o seu site vai rodar em servidores múltiplos, você deve selecionar "banco de dados" para que os dados de sessão do usuário está disponível independentemente do servidor sua / seu pedido é servido a partir.Mais informações sobre este de Ashley Schroder em Magebase.com . [...]