MODX having a hard time on Rackspace Cloud Sites

Not sure if this applies to this thread but for what it's worth I had a Rackspace Cloud Sites MODX site sh!it the proverbial bed today and it turned out that .htaccess became corrupt (or something). When I created a fresh copy of the file all seemed to go back to normal. RS support suggested optimizing the tables in the DB too and was honest by saying that Cloud Sites doesn't play well with MODX—I think he mentioned they're trying to solve it.

Glad it was a simple fix.

What drives me crazy is that it used to work.. and work pretty well. If it never worked well or at all .. fine shame on us.

So good news. Migrating to php 5.4 on cloud sites with the latest MODx is really snappy.. I'm seeing 600ms time to first byte for a MANAGER page load. on php 5.3 it was like 1500 - 2000ms sometimes.

So far no front end issues. Either Rackspace figured it out, or the php 5.4 nodes aren't too full yet.

Quote from: opengeek at Mar 05, 2013, 08:23 AM

Quote from: SpaceCity at Mar 05, 2013, 07:45 AM

When's the last time we even had an update? There hasn't been one in this post.

I'll be honest, I don't believe there is a solution that is going to work on this service as long as there is no kernel level solution for locking a file that works on their NFS deployment. I have not had any luck avoiding the exclusive locking problem on Rackspace Cloud Sites' NFS mounts, and until someone can find or create a solution that works, I'm personally at a loss on what to do.

If you or any other Rackspace Cloud Sites users find that solution, I would love to know how to implement it...

I can't see anyone report what the PHP error message is here once this error occurs? Can anyone post their error log? Outside of the Modx Error Log, what the actual server error log reports? We're having a very similar problem related to cache files being wrote to twice... Not on rackspace though.

In our case one cache file ends up with the same contents twice and we end up with an error message of "Unexpected <". Changing the fmode of the cache manager to W (truncate and write) instead of append appears to fix the issue, but breaks the Modx Error Log... If this is the same issue as on RackSpace, no amount of file locking is going to help as what the xPDO cache manager appears to do is just queue people waiting to write to the file....?

The cache is supposed to be utilizing a technique that always opens the file in append mode, seeks to the beginning of the file and truncates it before writing. It uses flock (or an alternative mechanism if configured) for ensuring the file is locked during this operation, but if that fails to actually get a meaningful lock in the environment, all bets are off.

I'll spend some time revisiting this approach in detail this week and see if I can find a better solution to cache file writing that avoids this problem in the problematic environments.

Quote from: opengeek at Mar 11, 2014, 10:36 AM

The cache is supposed to be utilizing a technique that always opens the file in append mode, seeks to the beginning of the file and truncates it before writing. It uses flock (or an alternative mechanism if configured) for ensuring the file is locked during this operation, but if that fails to actually get a meaningful lock in the environment, all bets are off.

I'll spend some time revisiting this approach in detail this week and see if I can find a better solution to cache file writing that avoids this problem in the problematic environments.

Great! We'll be willing to re-run the ab tests we can use to reproduce the problem on a sandbox version of the site we're working on if you have any updates for us to try. As a "short term" fix, is there anything glaringly wrong with changing the write option to w, where it automatically truncates and writes to the cache file? Obviously we'll lose the Modx Logs, but we can log these separately for now.. Functionally we haven't hit any issues yet.

I should add, I'm not having any more issues currently. @mor-mark you are? on the php 5.4 nodes?

Quote from: himmdesign at Mar 11, 2014, 11:11 AM

I should add, I'm not having any more issues currently. @mor-mark you are? on the php 5.4 nodes?

Our setup is a little different. I'm just high jacking this thread because _I think_ it's a similar issue! We're running a Zend Server WAMP stack with 5.3 PHP...

Have you tried running an Apache Benchmark on it running 5.4? Clear cache, "ab -c 10 -n 100 http://yourdomain/" brings down our intranet from any source.

@mor-mark Ah ok good to know, had me worried. Rackspace Cloud Sites has no SSH access, some quick googling didn't turn up any apache benchmarking information for cloud sites.

Possibly to avoid confusion maybe link a new thread from here? Maybe an admin would need to do it?

Yes, for clarity, I may have a different issue and I have another topic created below, along with an issue logged on GitHub. Though we are having the exact same symptoms as issues with rackspace.

https://forums.modx.com/thread/89475/modx-cache---unexpected---appending-file---flock-issues#dis-post-492339
https://github.com/modxcms/revolution/issues/11199

You can run Apache Benchmark (AB) from any server or even your own personal computer. As long as you can get two concurrent connections to your site the issue (or at least the one we're experiencing) can be recreated.