As a general question, are there any reasons that setting the Staging Mode to "nostage" instead of "stage" could cause performance hits? I was originally using "stage" mode, but after some issues with redeployments, I decided to try "nostage". This caused the application to perform almost two times slower. After switching the staging mode back to "stage" in the console, the slowdown was gone.
I was under the impression that the staging mode only "determines how deployment files are made available to target servers" (from the Oracle documentation page), and would not affect the runtime. Is this normal behaviour? I'm having trouble finding information on any links between staging mode and runtime performance.
Stage or nostage should not impact runtime performance. It is hard for me to find out what might cause your performance slowdown without further information, but one thing I can suggest is to switch back to staging mode if that seems to give you the better performance before you figure out the root cause. As to the redeployment issue you mentioned in your answer, you did not provide any details, but I guess it might be related to WLS still picking up the old files instead of new files. You can do some extra steps during your deployment to fix that
Undeploy your app
Shutdown the whole domain
Delete the tmp/stage/cache directories under each managed servers
Start the servers in the domains
Do a new deployment.
Of course, it sounds cumbersome, but you can automate all these into your deployment scripts.
Related
Recently I have completed migration from M1 to M2. Total of 5 stores reside under single Magento 2 installation in the Cloud now. Page speed is a pain point at this time. Lighthouse and web.dev scans suggesting several areas to be improved, such as bundling JS and reducing JS execution time, as well as minimizing main-thread work. Installed Amasty Page Speed Optimization extension, but it barely made an impact. Installed Magepack JS Bundling tool, and it did make small difference, however still need to get the websites optimized to improve the performance. Can anyone suggest another extension or recommend effective steps to get the sites optimized?
It is difficult to say why your website is slow with limited information.
But you may try following.
Check if site is running in production mode.
All the caches are enabled.
Disable all the custom modules and check if it runs fast with default Magento code?
Try to enable Magento profiler and investigate which code/event etc. is taking more time.
Check Magento logs and Server logs to see if there are any errors or connection timeouts to any third party services.
Once you have some kind of report with which you can identify what is causing slowness. You may decide next course of action.
Unfortunately, I am not much aware of these two terms and I have a feeling that I need to know more about these as I am approaching an app release.
so, if I am running the app on development mode am I not using exactly the same code as production? Like what does it actually change and whats the purpose of it?
If it's in the sense of server than that's understandable, I don't wanna mess with the server that's being used by the users, so I guess i need to connect to a second server - development, however, I am interested to know what does it change in my code? I am still gonna use the same locally stored project right?
Sorry for being so naive!
The development build is used - as the name suggests - for development reasons. You have Source Maps, debugging and often times hot reloading ability in those builds.
React Native includes some very useful tools for development: remote JavaScript debugging in Chrome, live reload, hot reloading, and an element inspector similar to the beloved inspector that you use in Chrome.
The production build, on the other hand, runs in production mode which means this is the code running on your client's side. The production build runs uglify and builds your source files into one or multiple minimized files. There's also no source maps or hot reloading included.
Further more , Production mode is most useful for two things. They are
Testing your app's performance, as Development slows your app down considerably and Catching bugs that only show up in production.
Hope this might help
https://docs.expo.io/versions/latest/workflow/development-mode/
Our medium size website (Kentico 9) does not show search results for a new page added. Index status indicates that a rebuild is required. Does anyone know if rebuilding the smart search indexes may cause an outage to the site? The same functionality in Dev and UAT environments is working fine and does not require a rebuild.
screen shot
It very well could depending on your environment. If your index is very large and you have a lot of traffic, the rebuild process could cause the site to come to a halt because of resource availability. You may post some more information on your environment to make that determination.
YOu can also check the Kentico event log to see what errors are being written there, if any. There could also be .lock files in the /App_Data/Modules/SmartSearch/ folder. Those can cause the index to continue to attempt to rebuild.
We're developing a solution which uses Ektron. As part of our solution we all have local IIS instances (localhost) and deploy to this local instance as part of the development life cycle.
The problem is that after a deployment and once dll's are replaced IIS restarts and the app pool is recycled, this means that Ektron dll's need to reload themselves.
This process takes an extended amount of time.
Is there anyway to improve the loading time of "Ektron"
To some extent, this is the nature of a large app running as a website rather than a web application. Removing the workarea from your local environment is one way to get this compile time down, though this will naturally not work depending on your workflow, for example if you are not using a separate dev DB or if you are storing the workarea in source control.
I have seen some attempts to pre-complile the workarea and keep the working code in a separate project (http://dev.ektron.com/forum.aspx?g=posts&t=10996) but this approach will only speed up your builds, not the recompilation of individual pages that will occur after a build as a result of running as a web site.
The last (and least best-practice) solution is to simply avoid making code changes that cause a recompile, like modifying app_code. Apps running as websites are perfectly happy to recompile a single page's codebehind without regenerating DLLs, which is advantageous for productivity but ultimately discourages good practices like reusing code in libraries. Keep in mind that this is terrible advice, but if you have a deadline and are staring at an ektron page loading every 30 minutes it can be useful to know.
Same problem here. I found this: http://brianpereras.blogspot.com/2013/06/ektron-85-86-workarea-is-slow-compared.html
That says that the help documentation was moved to be retrieved from an online source (documentation.ektron.com). We're running Ektron 9, and I just made this change and it seems much faster on first load (after iisreset).
The solution is to set documentation.ektron.com to 127.0.0.1 in your hosts file.
There is not, this is just how IIS works. Instead of running a local instance of Ektron it's a good idea just to point your web.config file to the database of your test database and copy the /workarea folder to your local PC. You can't edit ektron locally but you can change the data on your test server and it will show up locally.
I'm very new to C.I. but I have recently inherited a project where Team City has just been implemented and I'm slowly getting my head around it. One thing we would like to do is run some Selenium Tests as part of the build process. I've created the selenium tests and can run them successfully via nunit-console on my development machine. The build server builds the project and then deploys it (A web forms application as it happens) to a staging server.
Before each selenium test we set the database to a known state, i.e. to only have certain records in place - that way each test is independent of the others. The problem is the staging server will be used by real "human" testers so this would cause them a problem with the database continually being reset (records being removed etc.) The question is should I really also deploy the application to a virtual directory on the build server and run the selenium tests against that and only deploy to the staging server if those tests pass?
Or have I got this stuff completely wrong? If so how do you do it in your organisation?
I suggest that you do not mix your automated and manual testing by allowing your testers to access the server that is staged for your automated tests. This can cause false negatives both in your automated and your manual tests. These 'bugs' are indeterministic and more than likely never reproducible (a very bad news). This will cause you a lot of unnecessary 'bug reports' and build failures.
So here is what you can do...
In addition to your current setup, you can create an extra staged server for your manual testers. This is the least you should do. You should probably create several of them, one for each tester.
And here comes the rant...
In my current project we recently found out that our testers (we had ~10 of them) reused one server. They claimed that since our app is going to have multiple concurrent users, it was a good idea that while they are testing the individual functionalities, they are also testing how these functionalities act while multiple users are working on the same server. WRONG!
If multiple users are a concern, there should be test cases for the specific concerns. If functionality#1 can interfere with functionality#2, it should be specifically tested and not just be 'tested-by-luck'.
Before this was explained to our manual testers, we had many false bug reports due to the fact that one tester was simply stepping on another tester's toes. (e.g. tester1 deleted a record that tester2 introduced to the system, etc...). This created a lot of unnecessary bug reports and these bugs were never reproducible.
Sorry about the rant, I hoped this still helps :)