Concrete5 code would attempt to read the same nonexistent files hundreds or thousands of times per page load
Permalink
My two concrete sites are always so slow to load when editing. I wrote to my host provider and got this message back.
"We recently investigated a similar report of slow sites for another customer and the problem was determined to be that the other member was (also) running Concrete5. We identified behavior where the Concrete5 code would attempt to read the same nonexistent files hundreds or thousands of times per page load, creating massive overhead. We think this is a defect in Concrete5. "
Has anyone had the same issue or been able to resolve this?
Thank you.
"We recently investigated a similar report of slow sites for another customer and the problem was determined to be that the other member was (also) running Concrete5. We identified behavior where the Concrete5 code would attempt to read the same nonexistent files hundreds or thousands of times per page load, creating massive overhead. We think this is a defect in Concrete5. "
Has anyone had the same issue or been able to resolve this?
Thank you.
Did they offer any details on what files, or where they thought they saw this?
Thanks for the response.
Unfortunately they did not. I'm a relative noob hosting at Nearlyfreespeech.net.
They advise people like me, asking questions like that, to find another host.
Is gaining the information you seek the only route to a solution? If so I'll go
back and plead my case, pay some money and suffer their wrath.
Unfortunately they did not. I'm a relative noob hosting at Nearlyfreespeech.net.
They advise people like me, asking questions like that, to find another host.
Is gaining the information you seek the only route to a solution? If so I'll go
back and plead my case, pay some money and suffer their wrath.
tell em you've got the CEO's ear and he's eager to learn what they've found and see if that helps.
Update:
---------------
"Hello Chris --
On Tue, 05 Jun 2012, 19:53:16 UTC, Chris wrote:
> Do you have any information that could assist the people at Concrete5
> to get their CMS to work well with NFS??
We'd need to reinvestigate your specific situation to provide that kind of information (at the cost of however many support points corresponds to the time that would take, which we can't predict). Please let us know if you'd be interested in having us take another look.
Regards, "
---------------
I love concrete5 and I love NearlyFreespeech.net. But the edit and load times are becoming unbearable. Can any action be taken by Concrete5 to resolve this issue with my host provider?
Thanks.
Chris
---------------
"Hello Chris --
On Tue, 05 Jun 2012, 19:53:16 UTC, Chris wrote:
> Do you have any information that could assist the people at Concrete5
> to get their CMS to work well with NFS??
We'd need to reinvestigate your specific situation to provide that kind of information (at the cost of however many support points corresponds to the time that would take, which we can't predict). Please let us know if you'd be interested in having us take another look.
Regards, "
---------------
I love concrete5 and I love NearlyFreespeech.net. But the edit and load times are becoming unbearable. Can any action be taken by Concrete5 to resolve this issue with my host provider?
Thanks.
Chris
The bleeding edge branch of concrete5 has some code in it that could really improve situations where this is a problem. Specifically we cache the state of your site and no longer check to see if files exist on every page load. Do you think I might be able to have access to your web space ? That branch is 100% ready for performance testing yet but it would be great to have access to a host for whom performance has been a problem so we can test against it going forward.
PM me for more details if you're interested.
PM me for more details if you're interested.
Thank you. Very interested. I sent you a message.
If this can speed up override determination, will there be scope for packages to create overrides of other packages or the core? or for finer granularity of overrides?
I imagine this is us checking to see if overrrides exist using file_exist().
e.g. checking the models/, blocks/, libraries/, controllers/, etc... files in the root before we check the core.
e.g. checking the models/, blocks/, libraries/, controllers/, etc... files in the root before we check the core.
You can ask your host about
I think php defaults to like 16k or something and your host may have something like that. If you bump this up to at least 2MB or even better 4MB you're going to have a better time.
realpath_cache_size
I think php defaults to like 16k or something and your host may have something like that. If you bump this up to at least 2MB or even better 4MB you're going to have a better time.
Oh wow. I did not even know this setting existed.
Sent from my iPhone
Sent from my iPhone
I thank you for the suggestion. I'll report back soon.
The good people at NearlyFreeSpeech.net looked into "realpath_cache_size" and replied.
"This setting would actually not affect the issue we saw previously."
"This setting would actually not affect the issue we saw previously."
Some light reading for your host
http://php.net/manual/en/function.clearstatcache.php...
http://www.php.net/manual/en/ini.core.php#ini.realpath-cache-size...
http://us3.php.net/manual/en/function.file-exists.php...
On that last link they might want to scroll down to the "Notes" section and check out
http://php.net/manual/en/function.clearstatcache.php...
http://www.php.net/manual/en/ini.core.php#ini.realpath-cache-size...
http://us3.php.net/manual/en/function.file-exists.php...
On that last link they might want to scroll down to the "Notes" section and check out
Note: The results of this function are cached. See clearstatcache() for more details.
I should revisit quickly as that may have been a bit terse. file_exists does not cache not found files. This is probably why they said that. But concrete5 does a bunch of require_once's and other stuff(like successful file_exists) that this gives you a bump for.
Anyhow, since they are having trouble with this that means that their NFS is pretty slow and you need caching. Some other reading on the topic from another CMS that has some similar behavior.
http://tag1consulting.com/blog/nfs-drupal-and-realpath-cache...
Anyhow, good luck with your host.
Anyhow, since they are having trouble with this that means that their NFS is pretty slow and you need caching. Some other reading on the topic from another CMS that has some similar behavior.
http://tag1consulting.com/blog/nfs-drupal-and-realpath-cache...
Anyhow, good luck with your host.
I gave them the info. Thanks again for the help. Will report back.
Reporting back with new information from NearlyFreeSpeech.net
> Anyhow, since they are having trouble with this that means that their
> NFS is pretty slow and you need caching.
"This is incorrect; the problem we observed was that the code was trying to access the same nonexistent file thousands of times per second. That's what caused the perceived slowness and the only way to speed it up is for it not to do that."
--
> Anyhow, since they are having trouble with this that means that their
> NFS is pretty slow and you need caching.
"This is incorrect; the problem we observed was that the code was trying to access the same nonexistent file thousands of times per second. That's what caused the perceived slowness and the only way to speed it up is for it not to do that."
--
Just a quick one. I don't work for concrete5. I'm not sure if they are aware of that. Anyhow, thousands of times per second is quite an exaggeration. Many hosts use NFS, any many hosts have figured how to deal with this issue and concrete5 isn't the only middle-ware that does this.
Like @andrew said you can try to development branch or find a new host if they don't want to/can't improve their NFS performance. Just to be clear, their NFS is slow compared to other hosts.
bluehost, dreamhost any host pretty much uses NFS and seems to host concrete5 fine, even with the "thousands"(it's not actually thousands) of requests per second while you are in edit mode.
Like @andrew said you can try to development branch or find a new host if they don't want to/can't improve their NFS performance. Just to be clear, their NFS is slow compared to other hosts.
bluehost, dreamhost any host pretty much uses NFS and seems to host concrete5 fine, even with the "thousands"(it's not actually thousands) of requests per second while you are in edit mode.
I should add that if you want to get creative you can symlink your root directories to the concrete/ core directories and it solves a lot of this in a fairly ugly but effective manner.
Is this "thousands" of requests thing still an issue with the latest Concrete 5.5.2.1? I need to know what I'm up against here. I have a huge client and a fastly-approaching deadline. I thought we were past all those old speed issues but my completely blank template with no content is loading slower than the client's previously existing site on the same server. :-( Obviously, when I start adding content, it's going to be even slower and they are not going to be happy.
If it was, we'd see more posts. Personally, I think it's a symptom of my particular host NearlyFreeSpeech.net. Should be fixed soon, possibly next week.
If you do a search for "slow," you'll find a lot of people have experienced slow C5 sites. All of mine have been slower than other non-C5 sites I build regardless of which hosting company I've used.
In fact, I just posted yesterday about a new C5 site I put up on MediaTemple which has a blank default.php and no content added yet... and it is slower than the client's currently running website which was made with TextPattern and contains a slideshow, images and content.
You can see that post here (no replies yet):http://www.concrete5.org/community/forums/chat/5.5-blank-template-n...
In fact, I just posted yesterday about a new C5 site I put up on MediaTemple which has a blank default.php and no content added yet... and it is slower than the client's currently running website which was made with TextPattern and contains a slideshow, images and content.
You can see that post here (no replies yet):http://www.concrete5.org/community/forums/chat/5.5-blank-template-n...
Media Temple shared hosting is ridiculously slow, their virtual and dedicated servers are very good though. I have found slowness with C5 is usually the hosting service you are using. Once you get using a good host you have no problems.
That may be, but the client's old website is on the same server and loads up lickety split. I just put C5 in a different directory on their same account.
EDIT: for the record, I just installed the exact same C5 site on Hostgator's baby hosting plan at $3.95 per month and it was quite a bit faster than MediaTemple's $20/month plan! Sheesh.
EDIT: for the record, I just installed the exact same C5 site on Hostgator's baby hosting plan at $3.95 per month and it was quite a bit faster than MediaTemple's $20/month plan! Sheesh.
This can be a problem. Typically on cloud hosts like Rackspace Cloud Sites or something like that. Part of some cloud type hosts is that file access can be inconsistent. Not always slow, but up and down.
On a traditional shared host, which afaik is what NearlyFreeSpeech.net is, they just haven't configured there NFS very well, they are oversold or something else with that host.
While the hundreds of file_exists() can be a test of a shared host with NFS, most of them I've come across deal with it just fine.
On a traditional shared host, which afaik is what NearlyFreeSpeech.net is, they just haven't configured there NFS very well, they are oversold or something else with that host.
While the hundreds of file_exists() can be a test of a shared host with NFS, most of them I've come across deal with it just fine.
We have seen this exact issue a few times now after recompiling php. We actually just dealt with it last week.
In our case the files that cause the problem are the session files located in the servers root /tmp directory.
It seems after recompiling php, the permissions of these session files are being altered and they are no longer able to delete themselves.
This causes a very high cpu load when loading pages and slow things down quiet a bit in edit mode as concrete5 attempts to access hundreds of files that supposedly do not exist even though they obviously do.
We discovered the "No such file or directory" issue on a whm/cpanel server by running a trace in the process manager on the php instances that had a super high cpu load.
We fix this issue by simply deleting the session files located in the servers root /tmp directory.
Here is a small snippet from a trace we just ran last week when having this issue.
In our case the files that cause the problem are the session files located in the servers root /tmp directory.
It seems after recompiling php, the permissions of these session files are being altered and they are no longer able to delete themselves.
This causes a very high cpu load when loading pages and slow things down quiet a bit in edit mode as concrete5 attempts to access hundreds of files that supposedly do not exist even though they obviously do.
We discovered the "No such file or directory" issue on a whm/cpanel server by running a trace in the process manager on the php instances that had a super high cpu load.
We fix this issue by simply deleting the session files located in the servers root /tmp directory.
Here is a small snippet from a trace we just ran last week when having this issue.
stat("/home/c5theme/public_html/libraries/3rdparty/Zend/Cache/Backend/Interface.php", 0x12b637c8) = -1 ENOENT (No such file or directory) stat("/home/c5theme/public_html/concrete/config/../libraries/3rdparty/Zend/Cache/Backend/Interface.php", {st_mode=S_IFREG|0644, st_size=3904, ...}) = 0 close(4) = 0 time(NULL) = 1338471179 lstat("/home", {st_mode=S_IFDIR|0711, st_size=4096, ...}) = 0 lstat("/home/c5theme", {st_mode=S_IFDIR|0711, st_size=4096, ...}) = 0 lstat("/home/c5theme/public_html", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 lstat("/home/c5theme/public_html/libraries", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/home/c5theme/public_html/libraries/3rdparty", 0x7fff9f56fdb0) = -1 ENOENT (No such file or directory) open("/home/c5theme/public_html/libraries/3rdparty/Zend/Cache/Backend.php", O_RDONLY) = -1 ENOENT (No such file or directory)
That's very interesting and good information. I would definitely attempt this. This is completely different than what I was describing.
