The build of a meteor project takes a long time if performed in a docker image (> 30 min) but if done on a local machine ore directly on the server without docker everything works fine (2-10 min).
After some research I still do not know how to tackle this issue. Can anyone provide me with further instruction how to debug my docker? The performance seems really bad.
What should be the minimum server hardware to get a quick build time? The project itself is not large.
Related
R-shiny Application loads pretty quickly if run locally but seems to take an inordinate amount of time to load when run through shinyproxy. I have tried tweaking the heartbeat and load-wait times, and springboot although slow doesn't seem to account for all the delay, I'm running centos7 with the latest shinyproxy rpm install. Docker has been configured correctly (the containers do start eventually).
The shiny logs don't give much detail other than starting docker and proxy enabled.
Has anyone come across an issue similar to this before? Is this normal?
I think it is normal due that shinyproxy needs to start a docker service for every user that log on your app.
After I save my javascript file meteor will rebuild app but it takes so long time (I have to wait for 15 minute or more)
Are there solutions to solve it.
Thanks!
Based on my personal experience,
In general case, when you quit building in between there might be some folders undeleted like below images.
In such case, delete such folders first.
If you are using Windows, RAM can be issue. If you machine has very little memory allocated then building the ever growing Meteor project become very annoying. I came to know this when I upgraded my machine from 1st generation core i5-6GB DDR2 RAM-500GB HDD to 2nd generation core i7-8GB DDR3 RAM- 248GB SSD storage drive. Machine configuration plays a vital role for Meteor building for development env and production env. Earlier configuration took 6 min to build but new configuration took less than a minute for me now.
If you have any antivirus software running behind the scene then it too might cause the slow speed for meteor build process.
My goal is to follow "Deploying a Meteor app with Nginx from scratch" tutorial available here
After installing Meteor, Node, Forever and Git, do the npm install, I try to "run meteor" to see if it works.
After downloading meteor-tools, the process begins to extract meteor-tools... looks like it is hanging for a couple minutes and then stops without any warning.
So my guess is that something causes the extraction to quit, but i don't know what exactly.
Yes, Meteor likes plenty of RAM. I would recommend using Phusion Passenger with nginx for Meteor, it's very easy to set up, and their tutorials/getting started is very good:
https://www.phusionpassenger.com/library/install/nginx/install/oss/
I haven't found the exact reason. However, I got it working. I was using a DigitalOcean server (512Mb/20G). I tried with a big server (16G/160G) and it works.
So I guess my server Ram OR Disk capacity was too small.
Edit:
setting up smaller configuration, i noticed that the minimum for Meteor to work is: 2Gb of RAM and 40Gb Disk.
I want to start a new WordPress project with another developer. The decisions we made are:
We want to use Bedrock as the WP structure
we want to use Sage as the WP theme
We put the project in a GIT repository
I now ask myself if we should use Trellis, Valet or Docker.
My personal opinion is that Trellis / Docker is a bit too much for a project with two developers working on it. Additionally my experience with Vagrant is not very positive, as it was very slow when I used it. My favorite would be Valet, because it's so slim. The repository I would use is Beanstalk, from there I would trigger my deployments to my test and live system.
Additionally I am not 100% sure if my server to which I want deploy my project also needs Docker installed - does anybody knows that? And what happens when my server runs on Apache and not Nginx?
Now that Docker has native Mac and Windows apps you wouldn't need Vagrant for local dev, and running a series of Docker containers is much faster than a full-fledged VM with Vagrant+VirtualBox. Right now I have MariaDB + PHP-FPM + Nginx + WordPress + PHPMyAdmin, and the whole thing is really fast relative to my previous experience with Vagrant. Faster as in: faster initial install, faster to start/stop, faster to make changes and have them reflected after a restart. I just replaced MySQL with MariaDB in a matter of minutes (mostly fumbling with having the proper syntax in my docker-compose file).
The beauty of Docker appears precisely when you want to switch components (say Apache vs. Nginx). In WordPress' case, they provide images on Docker Hub that either include Apache or PHP-FPM (in the latter case you just add a Nginx container to your stack).
That said I just got started with Docker and there are some kinks to figure out, but it's worth figuring out.
I haven't deployed with Docker yet but I plan to test that next once I've got local dev fully working as intended. It's optional though, you could always deploy with Git webhooks or whatever you were using up to now.
I have an ASP.NET website that I want to test with Selenium. I want to setup a Jenkins instance on a "staging" virtual machine, to run the tests automatically.
The problem is that the tests run very slowly - several times slower than on my development machine. A single, simple test can take more than 2-3 minutes.
I'd like to know if this is to be expected, if there are any obvious pitfalls for such a testing setup as mine, and if there's anything I can do to profile and improve the performance of the test suite.
Info:
Tests run on a 2.7GHz 2GB Ram virtual machine with Windows 7 64bit.
My dev machine is similar, but with a 32-bit Win installation.
The following is done by Jenkins:
The website gets checked out from source control, and configured with a custom web.config. The main differences are that it's compiled in release mode and it connects to a database on a different machine(also a virtual machine, on the same server).
IIS is monitoring the website's directory and automatically reloads changes.
The following command is run (directories sanitized): nunit-console Selenium-Project-Dir /labels
The tests are run on the Chrome webdriver.
The selenium project uses NUnit and WebRunner.
Driver instances are created once - before all tests, in a [SetUp] attribute inside a [SetUpFixture] class. They are deleted once, in the class's [TearDown] attribute.
A sample test looks like this:
[Test, Combinatorial]
public void AnExistingUserCanLogin(
[ValueSource(typeof(Drivers), "Good")]
IWebDriver driver)
{
// This function clicks on some buttons and fills in some forms.
LoginUser(driver);
// Make sure the user is now logged in
Assert.IsTrue(driver.ElementIsPresent(By.ClassName("imgUserAvatar")));
Assert.IsTrue(driver.ElementIsPresent(By.CssSelector("a.my-profile")));
Assert.IsTrue(driver.ElementIsPresent(By.CssSelector("a.logout")));
}
(The "Drivers" class contains lazily-instances webdriver instances of FF, IE, Chrome. You can guess what the "Good" static property of the class instances)
The fact that it is a VM should not be a problem, and RAM sounds like it is good. What OS is being run though? Some of the Windows OS have significant speed differences between the different bit versions (because of demands on hardware). This is especially noticeable in Vista but I have noticed a difference between Windows 7 and Server 2003.
I have found that there is a huge problem if the machine running the 64bit VM is a 32bit machine. It often seems to work well for a while and then as it continues to run tests will slow down. Which should be a duh but the main thing is that there may be too many VMs being run from the same place. Other programs will be affected by this and that can help troubleshoot if your VMs are on a company farm.
The other factor that has made a significant difference is if you are running the tests against different browsers. IE8 and IE9 will take the same selenium command and run them at different speeds. I don't know why this is, I just know that I have seen it. Make sure the staging machine has the current version of Chrome (or at least the same as your dev machine).
How the staging machine is networked to the database might be making a difference. This seems like a very small chance but if there is firewall crap between the two VMs that can have significant impact on time.
The only other thing I can think of that might be changing the length of time is if there are other programs being executed on the on the staging machine at the same time. Checking the CPU usage might helpful. Personally, I have noticed that my VM uses a lot more of the CPU than my personal machine. If this is the case the only solution I have found so far is to give the VM more processing power or to only run the test and nothing else.
Good luck!