currently I am a bit lost or maybe have just a mental blockade.
The topic for my question is a 1.7.3.3 Prestashop currently hosted at shared hosting. Due to slow performance and long TTFB I am currently moving it to a VPS running Plesk, hosted on DigitalOcean.
Now comes the Part where I am a bit lost: I copied the files via WGET, dumped the Database and applied permissions (to my knowledge) correct. Shop comes up at the new Plesk-Host under new domain without issues.
As soon as I am trying to enable MySQL-caching I am able to edit the pages with Apollo Pagebuilder, but not save them anymore. At least the changes don't show up at front office. If I switch back to filecache, changes are propagated as intended, but the modules-page in the backend doesn't work anymore (e.g. error 500, can be fixed by removing /app/cache/prod and app/cache/dev)
So, to summarize my issue: If I enable filecache, everything except the module-page works, if I enable MySQL-cache, everything except Apollo Pagebuilder-propagation works.
What I already tried:
I have reinstalled Apollo Pagebuilder, but this rather completely breaks my Front Office (means I'd have to rebuild everything from scratch, as the current status doesn't seem to be read properly).
Exported, reimported and "update and fixed" Apollo, not successful :(
Only thing that comes to my mind as a fix would be sacrificing something to the gods, but I'd rather not do that.
Environment:
Ubuntu 16.04 LTS; Plesk Onyx 17.8.11; Prestashop 1.7.3.3; PHP 7.1.26
If no one had this problem before, maybe someone has an idea on what to delete to just enable the modules in the backoffice. I'd be willing to take MySQL caching as non-available.
Thank you in advance for your help.
Ok, I think I found the answer. As the server including cache was migrated, it cached the database-connection as well. (Fortunately it wasn't able to write on the previous DB).
So if ever someone faces the same issue:
prestaroot/app/cache/prod/appProdProjectContainer.php stores the connectionstrings at 2 positions.
Once in: protected function getDoctrine_Dbal_DefaultConnectionService() //**around line 670
and once around line 5000. Easiest would be to just search for your previous connection-credentials.
Also you need to make sure that in prestaroot/app/cache/prod/appParameters.php the same, valid, credentials are existant.
Hope it will help someone one day.
Related
I have a very annoying problem as shortly described in the title. As I don't know which settings would make sense to post here and due to the fact, that exactely the same web application was running before on a Server 2008 with IIS 7 seamlessly, I try to explain the occuring misbehaviour as good as possible. I'd appriciate your ideas or hints very much.
Our web application was running for years now on the 2008 server with IIS7, PHP5.6 in FastCGI Mode. We authenticate our users by "Windows Authentication" (NTLM/Negotiate) against Active Directory and therefor just letting the users enter their domain users credentials at start of the session. Actually we allways used named sessions like this: SESS_[TIMESTAMP] and looped the timestamp through the whole applications session untill it was destroyd by whatever - closing, leaving, etc.
Now we migrated the web application to a new Server 2019 with IIS10 and PHP7.4. The application it self works as expected and absolutely with no problems at all. The only thing causing a critical situation is as follows:
I enter the web application on my machine, enter the credentials and - as expectet - am in. I see my Username at the top, everything is ok. As I go through workflows and data manipulations it's also working correctly. BUT: If my colleague in his homeoffice now enters the web application and starts working at the same time as I do, very often I see his username at the top of my browser window and he is me... (???) As we both then press F5 sometimes, the session changes back and forth. As our users (inside company) work with security sensitive data, this is indeed a showstopper.
As far as I can say, I really checked all settings in IIS and php.ini against the settings on the old server and also searched the web for days now. With absolutely no success.
I even commented out the section at my sessions initiation that sets a custom session_name. And indeed I'm not using a custom folder for session files.
The only thing I'm quite sure is that the misbehaviour results out of a misconfiguration in IIS: If I only open a test-file with phpinfo(), I can reproduce the same behaviour. The AUTH_USER, REMOTE_USER and LOGON_USER are changing back and forth between another users DOMAIN\username and mine.
Does anybody have had this interesting but annoying behaviour also? Any ideas or hints where to apply the lever?
Thank you so much for your input.
New information to my question:
I found out that the most significant difference to the old server is a load balancer! It seams that the load balancing causes this problem as the old server was not balanced.
Any suggestions or ideas how to deal with this?
I'm a bit confused by a problem that has only become more apparently lately and I'm hoping that someone might be able to point me in the direction of either where I might look for appropriate settings, or if I am running into another problem they have come across before.
I have a Laravel application and a private server that I use for our little museum. Now as the application has become more complex, the lag is noticeable and you can see how it almost lines up the connections, finishing one request before moving along to the next, whether it be api, ajax, view responses, whatever.
I am running Apache 2.4.29 and my Ubuntu Server is 18.04.1.
I have been looking around but not much has helped, in regards to connections settings, if I look at my phpinfo() I see this Max Requests Per Child: 0 - Keep Alive: on - Max Per Connection: 100 but I believe these are just fine the way they are.
If I check my memory I think it says I have 65 GB of available memory, with 5 being used in caching. When reviewing the live data, the memory never crosses into the GB territory and solely remains in the MB territory. This server is absolutely only used for this Laravel project, so I don't have to worry about messing with other projects, I'd just like to make sure this application is getting the best use it can for its purpose.
I'd appreciate any suggestions, I know there's a chance the terms I am searching for are incorrect, or maybe just outdated, so if there are any potential useful resources out there, I'd appreciate those as well.
Thank you so much!
It's really hard to be able to tell since there a lot of details lacking but here some things that can give you a direction of where to look:
Try downloading htop via apt-get and see what happens on your CPU/RAM load with each request to the server.
Do you use php-fpm to manage the php requests? This might help in finding out if the problem lies in your PHP code or in apache configuration
Did you try deploying to a different server? Do you still see the lagging on the other server as well? If not, this indicates a misconfiguration problem and not an issue with your code.
Do you have other processes that are running in the background and might slow things down? Cron? Laravel Queue?
If you try to install another app on the server (let's say phpmyadmin) is it slow as well or it works fine?
Try to take it from here. Best of luck.
Basicaly, we have tons of category. And when I edit a plugin or a page, there is a category tree.
On the actual production, displaying this tree in backend take just few seconds.
But now, on migration server (which is supposed to be more powerful), its taking way way much more time to display this tree, like, 8 times longer. And i don't know why, cause settings are the same.
I tried many things, even updating index, (but, that didnt fix anything).
So, for me, its a server configuration issue, but i know nothing about that.
Can someone advice me, cause i dont know where to look now.
Thank you !
we found a solution to my problem!
After working with sysadmin, we realized that the problem was our MySQL version. We were using a MySQL server version 5.6, and for some reason, typo3 didnt like it. So we set the server as our actual production: MariaDB 10.0.30, and we saw a huge improvment.
(Editing a plugin took something like 1.3 min with MySQL server, and now it takes 15 sec with MariaDB)
Maybe someone has explainations to this improvment?
(We are aware that having 1500 categories is a terrible idea, TYPO3 is not supposed to work like that, but thats not our decision, and we will manage to change/improve that in the future)
I'm trying to move a Magento 1.7 site to a WebFaction 512MB plan. Currently it's on a several-GB Linode (and it absolutely rocks), but we have to move it onto our own server now and I'm having trouble getting it to perform well (typical page load is anywhere from 45s to several minutes, often timing out at 5 mins).
As mentioned in the title, I'm running Nginx with fastcgi_pass to the PHP-FPM socket (php 5.5.0, w/zend opcode). FWIW, I've already moved our Wordpress site to this server, and it's performing great under basically the same setup. I've also got a similar setup running on my local VM, similar PHP settings, and it doesn't have any trouble delivering a page in 3-5s. I've done lots of profiling with XDebug, and I'm still at a loss - it says that about 90% of the time is spent in spl_autoload (handled by lib/Varien/Autoload), but I don't know if there's anything I can actually do about that. I've echoed get_include_path() and it doesn't include anything weird, so... I just don't know.
Here's some relevant config info, at pastebin:
Nginx config
php-fpm.conf
php.ini
I'm at my wits end, and am basically hoping for at the very least, a simple sanity check: Magento on Webfaction, 512MB, PHP Fastcgi - is that crazy? Not sure if it matters, but we've only got like 75 products. Let me know if there's other info that might help, I've got the php "slow logs", xdebug... yeah. I'm just unable to see the problem at this point, but I feel like I've got the tools to ferret it out, whatever it might be. Thanks in advance!
I'm afraid that this will come down to the underpowered environment. Correct me if I am wrong but your hosting is probably a VPS and sometimes, no matter how much optimisation you do - it's often easier to upgrade the hosting.
I'm at a loss why you would move from a VPS to a shared hosting provider like Webfaction. If you bought a dedicated webfaction server why are you limited to only 512mb?
The problem was not with my app or my nginx/php settings at all, it turns out the server my account is on was totally overloaded and has since been dealt with. My app now loads really fast, basically as you would expect.
Running Magento Community 1.6.1 on Apache, MySQL.
Hi, I have a huge problem with visitors getting locked out from our site by receiving empty response from server. Any user that has anything in the cart when any product is updated (actually just pressing save is enough), will get locked out by receiving empty_response from the web server.
Users gain access again if they remove their session cookie, and/or we clear the sessions folder in /var/, but until then all they get is empty_response from the web server.
Rolling back the database to one a few days older than the first symptoms kills the problem, without having to replace any files.
No logs or exceptions are produced.
It took a while to cause the problem, and even a bit longer to find the cause, so rolling back to a database backup from before the problem is not an option.
Have read a lot about cookie lifetimes, etc, but nothing of that has been related to this. Furthermore - being able to verify with a functional database allowed me to copy the settings (actually copying the content of core_config_data) from the functional database to a copy of the current live database, for more test. Results were the same…
So, ending up here… would be extremely thankful for any tips, hints or directions that put me on the right track!
Thanks for reading my post, and many thanks in advance for spending your time reflecting over this issue
you should try
database repair tool
clear all logs in database
re-save customer groups
inspect cookie settings with fiddler or any other similar tool
verify that your server clock is correct
enable error messages
inspect server error logs to see if there is any logs related to this