{"action":"created","issue":{"url":"https://api.github.com/repos/backdrop/backdrop-issues/issues/716","labels_url":"https://api.github.com/repos/backdrop/backdrop-issues/issues/716/labels{/name}","comments_url":"https://api.github.com/repos/backdrop/backdrop-issues/issues/716/comments","events_url":"https://api.github.com/repos/backdrop/backdrop-issues/issues/716/events","html_url":"https://github.com/backdrop/backdrop-issues/issues/716","id":57679612,"number":716,"title":"Consider using a flat-file cache for the page cache","user":{"login":"quicksketch","id":100206,"avatar_url":"https://avatars.githubusercontent.com/u/100206?v=3","gravatar_id":"","url":"https://api.github.com/users/quicksketch","html_url":"https://github.com/quicksketch","followers_url":"https://api.github.com/users/quicksketch/followers","following_url":"https://api.github.com/users/quicksketch/following{/other_user}","gists_url":"https://api.github.com/users/quicksketch/gists{/gist_id}","starred_url":"https://api.github.com/users/quicksketch/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/quicksketch/subscriptions","organizations_url":"https://api.github.com/users/quicksketch/orgs","repos_url":"https://api.github.com/users/quicksketch/repos","events_url":"https://api.github.com/users/quicksketch/events{/privacy}","received_events_url":"https://api.github.com/users/quicksketch/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-02-14T03:42:24Z","updated_at":"2015-12-19T00:42:15Z","closed_at":null,"body":"We've already optimized Backdrop to the point that a database connection is not necessary if you're using an alternative cache-backend like Memcache. Even though the database is unnecessary except for the single query to get the cached page, we still need that database connection just for that single query.\r\n\r\nI was experimenting with using a flat-file cache as an alternative, a basic port of https://www.drupal.org/project/filecache. The results were fairly promising running `ab -c 100 -n 100 http://backdrop.local/`:\r\n\r\nDatabase cache:\r\n```\r\nRequests per second:    569.45 [#/sec] (mean)\r\nTime per request:       175.608 [ms] (mean)\r\nTime per request:       1.756 [ms] (mean, across all concurrent requests)\r\nTransfer rate:          12078.02 [Kbytes/sec] received\r\n```\r\n\r\nFile cache:\r\n```\r\nRequests per second:    741.53 [#/sec] (mean)\r\nTime per request:       134.857 [ms] (mean)\r\nTime per request:       1.349 [ms] (mean, across all concurrent requests)\r\nTransfer rate:          15727.74 [Kbytes/sec] received\r\n```\r\n\r\nSo roughly a 30% performance increase in cached page delivery. The downside is that the disk becomes littered with non-sense cache files. But as far as disk-space goes, this is no different from the page cache, which takes up just as much room, but it's hidden away in the database.\r\n\r\nIf we can test this approach on various servers and consistently get a similar increase, I think we might consider bundling a flat-file cache and using it by default for the page cache."},"comment":{"url":"https://api.github.com/repos/backdrop/backdrop-issues/issues/comments/165927972","html_url":"https://github.com/backdrop/backdrop-issues/issues/716#issuecomment-165927972","issue_url":"https://api.github.com/repos/backdrop/backdrop-issues/issues/716","id":165927972,"user":{"login":"Gormartsen","id":5018896,"avatar_url":"https://avatars.githubusercontent.com/u/5018896?v=3","gravatar_id":"","url":"https://api.github.com/users/Gormartsen","html_url":"https://github.com/Gormartsen","followers_url":"https://api.github.com/users/Gormartsen/followers","following_url":"https://api.github.com/users/Gormartsen/following{/other_user}","gists_url":"https://api.github.com/users/Gormartsen/gists{/gist_id}","starred_url":"https://api.github.com/users/Gormartsen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Gormartsen/subscriptions","organizations_url":"https://api.github.com/users/Gormartsen/orgs","repos_url":"https://api.github.com/users/Gormartsen/repos","events_url":"https://api.github.com/users/Gormartsen/events{/privacy}","received_events_url":"https://api.github.com/users/Gormartsen/received_events","type":"User","site_admin":false},"created_at":"2015-12-19T00:42:15Z","updated_at":"2015-12-19T00:42:15Z","body":"> That may be true, but as with storing in APC, Redis, Memcache, or any other cache backend, they each have unique features. In the case of a generic cache backend, we have to be able to implement the same features across all of them.\r\n\r\nI agree. What I am trying to say is that TAG ing could be done with out Database use at all, simply by creating public://filecache/TAGNAME folder and symlink keys from public://filecache/BIN to TAG folder.\r\n\r\nThen if we need to clean all keys by TAG, we just simply read TAGNAME folder and remove files from BIN folder and all symlinks from TAG folder.\r\n\r\nSame Idea could be done for time expiration. We can create a dir public://filecache/EXPIRE/timestamp , symlink there keys from BIN and in garbageCollection() get all directories with timestamp less than REQUEST_TIME and clean files by symlinks.\r\n"}}