I'm not sure which link in the chain is causing the problem. I just finished setting up Discourse on Vagrant on a Windows machine. Everything seems to be working fine, except that it took a good 86000ms (a minute and a half!) for Discourse to load in the browser. Something tells me that it's not supposed to be that slow. Where can I look for problems that might be causing this?
This is the most relevant discussion on the forum.
http://meta.discourse.org/t/development-mode-super-slow/2179
Make sure you have allocated enough resources in the virtual machine.
You can also try this in the development configs
#config/environments/development.rb
config.cache_classes = true
This made a huge difference to my render time. From 8 minutes to 30 seconds. Still a bit slow though.
I had the same issue in my VM when testing Discourse. What you actually have to do is change a config setting for WEBrick. Look for your WEBrick config which is usually in /usr/lib/ruby/1.9.3/webrick/config.rb yours could be different, it all depends on your particular setup.
Then change this line
:DoNotReverseLookup => nil,
to this
:DoNotReverseLookup => true,
Restart WEBrick and you should be good to go.
Related
I am working on Laravel with docker.
If I run php unit test in mac os, it takes few seconds.
However on windows 10, it takes few mins.
Is there anyway to fix this problem?
Thanks.
If you're running on a non-Linux OS, Docker has to virtualise your file system, and this requires a certain amount of time per file. For programs that are compiled into one executable, this is less of a problem at runtime (but clearly with its own compilation-time implications), but for scripting languages like PHP this can mean that every request runs super slowly, since every file that is used has to be 'translated' every time it is read. This is also a problem on Docker for Mac (so you're actually experiencing problems there, too, but less so, since at least it's a Linux system under the hood.) Linux is, I believe, completely virtualised on Windows which is going to add even more time.
This Reddit discusses the problem to an extent:
https://www.reddit.com/r/docker/comments/7xvlye/docker_for_macwindows_performances_vs_linux/
With this being particularly interesting (I have not tried it myself):
https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly
There is also a good community-created solution which we have used to solve our Docker for Mac problem. I don't see why their Windows options wouldn't work similarly well in your case. You can find it here:
https://github.com/EugenMayer/docker-sync/wiki/docker-sync-on-Windows
It basically sets up an intermediate service that copies all the files over into an intermediate volume (that uses the 'correct' filesystem) only when the file is updated, therefore speeding up run speed immensely.
I know it looks like quite an intimidating process, but this problem is fundamental, so you're going to have to do a certain amount of work to fix things!
FWIW I had that working on Docker 4 Mac, but it added a layer of complexity to our dev process that I found annoying, so in the end I've got myself a Linux box for work. To be honest, installing Linux as dual boot on my Windows machine (which has been my at-home solution) was probably easier than tweaking Docker 4 Mac to my satisfaction, so you might want to consider that. I have used this page twice:
https://itsfoss.com/install-ubuntu-1404-dual-boot-mode-windows-8-81-uefi/
And it's worked fine each time. One caveat - it suggests a low amount of disk for your root (/) volume, but Docker gets mounted on root so give it around 100G (not the 10-20G that page recommends.)
I am working with a SuSE machine (cat /etc/issue: SUSE Linux Enterprise Server 11 SP1 (i586)) running Postgresql 8.1.3 and the Slony-I replication system (slon version 1.1.5). We have a working replication setup going between two databases on this server, which is generating log shipping files to be sent to the remote machines we are tasked to maintain. As of this morning, we ran into a problem with this.
For a while now, we've had strange memory problems on this machine - the oom-killer seems to be striking even when there is plenty of free memory left. That has set the stage for our current issue to occur - we ran a massive update on our system last night, while replication was turned off. Now, as things currently stand, we cannot replicate the changes out - slony is attempting to compile all the changes into a single massive log file, and after about half an hour or so of running, it trips over the oom-killer issue, which appears to restart the replication package. Since it is constantly trying to rebuild that same package, it never gets anywhere.
My first question is this: Is there a way to cap the size of Slony log shipping files, so that it writes out no more than 'X' bytes (or K, or Meg, etc.) and after going over that size, closes the current log shipping file and starts a new one? We've been able to hit about four megs in size before the oom-killer hits with fair regularity, so if I could cap it there, I could at least start generating the smaller files and hopefully eventually get through this.
My second question, I guess, is this: Does anyone have a better solution for this issue than the one I'm asking about? It's quite possible I'm getting tunnel vision looking at the problem, and all I really need is -a- solution, not necessarily -my- solution.
We are using watir webdriver to test our applications. Currently I have 20 watir tests kicking off every 1 or 3 minutes on a linux server. Due to the way firefox works, we would constantly have tests fail to run because of it's locking port 7055 during launch. Tests that start at the same time would eventually time out if the port wasn't released in time.
After tons of experimenting, I seem to have been able to get around this issue by modifying this file:
gems/selenium-webdriver-2.21.1/lib/selenium/webdriver/firefox/launcher.rb
I added this bit of code near the top to assign a random locking port instead of just the default 7055. This seems to have helped a lot, only seeing the rare failure now.
Asking if there is a better way to do this or if this could introduce any problems?
### added to attempt to reduce unable to open firefox issues
if #port == 7055 then
#port += rand(2000)
puts "PORT: #{#port}"
end
Anyone else messed with this? I'm pretty new to ruby so guessing there is a far better way to script that.
Thanks for any input you can provide.
Instead of modifying the firefox launcher.rb I think you are better off incorporating some logic at each of your scripts. Something like this might help!
Have a look at the link below:
Ruby - check if a port is open
I'm having a very strange problem. I'm using dfs-datastores Pail abstraction to write data to HDFS in Java. I don't think the Pail piece is important to the problem though.
When it calls org.apache.hadoop.fs.FileSystem getFS(java.lang.String path) with a path on my local filesystem it pauses for about 2 minutes seemingly doing nothing then returns. This is on my laptop.
The weird thing is that it worked really fast when I was on the network at my office today, but now that I'm home it's doing it again. I'm running Ubuntu 10.10 64-bit with Java 1.7.
Anyone have any ideas what it's doing? What could be different between being at work and being at home?
UPDATE:
I've been stepping through code with the debugger and it seems to be having trouble in Configuration.loadResource(). It's calling that multiple times and it will take 5-10 seconds to return from that function.
UPDATE2:
I've narrowed this down a little further. The biggest hang up seems to be when it calls KerberosName.setConfiguration(). Which would explain why it runs fast at work since the Active Directory acts as a Kerberos server. I don't have one here at home, so it can't find one. Now they question is why in the world it's trying to load the Java Kerberos stuff.
I found a solution (or at least a work around). I installed the krb5-kdc package and now my little program runs fast without any unexplained pauses. After this I removed krb5-kdc, tested and it was still running fast. I removed /etc/krb5.conf and it started doing the pause again. It looks like using the Hadoop library on Ubuntu (at least) requires a /etc/krb5.conf file.
Maybe this will help someone else.
I've run into this problem before and the solution has usually been to restart IIS. Basically I've made a number of changes to a .wsc file on our server. But when it runs it doesn't run the new code changes I made. I've verified this with event logging at the beginning of the file and it doesn't show up.
My problem is that obviously restarting IIS on our production server is something I'm loathe to do, but we need this running today. I've tried re-registering the file but to no avail.
The server is a 32-bit Server 2008 OS. And the code is running, it still generates the file it is supposed to, but like I said, it's not using the latest changes.
Any other info I can provide, please leave a comment and I'll edit.
Thank you,
Jeff
Edit: Oisin, thanks for the reply and yes I know I hate VBScript, and anything related to it including these Window Script Components. I've expressed such feelings to my manager, but it's a dirty job and someone has to do it!
Yes it's using a Server.CreateObject to call the component.
ANSWER: I've since realized my mistake. I was only 'registering' it over and over, when I should have first 'unregester'ed it the 'register'ed it. Man I feel stupid, but haste makes waste as they say.
Thanks for the response and link!
Eek, you mean WSC as in a Windows Script Component? I haven't written one of them since 2000.
Are you loading it using CreateObject (e.g. it's registered as a COM object via regsvr32), or are you using a file-based moniker to load it? (not registered).
If it's registered, it probably is cached until app restart. If you switched to a file based moniker, e.g. like: Set o = GetObject("script:c:\path\obj.wsc"), you might get away with runtime changes to the .wsc file.
(man, how did I even remember this)
more info here - quick before it's archived! :D
http://www.microsoft.com/technet/scriptcenter/resources/scriptshop/default.mspx
-Oisin