There's a bug in Virtualbox that results in small, static files not being transmitted over shared-folders properly. This purported solution is to add "sendfile off;" to the server/location block in Nginx (or a corresponding fix to Apache/etc...) and reloading. This prevents gibberish from being received in your Javascript, CSS, etc..
However, it's not working for me. I'm definitely hitting the right server/location blocks, but, even after reconstructing the Vagrant instance (with the Virtualbox provider), I still get gibberish in my files.
Does anyone have any guesses at what could be going on?
Yes but this can not be solved, you should create a real share on the Host and net use to that share, VB shared folders are a cheap way to get stuff in a VM but don't use it for anything else.
Related
We have some files on our portal that aren't that big to me: 50MB-80MB. On my home connection, it takes <10seconds to download these files. I've had other users test and they experience the same thing.
However, in the office, the connection is terrible. These files don't even download because once the download time gets to about 30-35 seconds, even though it is downloading (just incredibly slow), it triggers a non-descriptive error in the Developer Tools > Network and stops the download. Not seeing anything in any logs that indicates why the download is terminated.
The bigger problem is we now have a few end users with crappy internet who are also experiencing the same issue.
So I'm trying to figure out what we can do on our end. Obviously, we can't tell them, "Well, just get better internet service." It seems like there can be something done on our end to persist the download until it is completed. What that is, I'm not quite sure and that is what I'm looking for help on. Maybe it is a default setting in a dependency somewhere in our stack.
ReactJS FE that uses FileSaver.js for downloads
Django BE using native Django downloading
nginx-ingress for traffic ingress controller to the Kubernetes cluster
The FE uses nginx to serve the FE
The BE uses gunicorn to serve the BE
Any suggestions on what I should do to prevent this timeout on downloads?
I'm thinking the issue is somewhere with nginx-ingress, nginx, and/or FileSaver.js, so investigating those.
Per Saurabh, adjusting the timeout did the trick. I now just start the web server with the -t 300 flag and the users that were having issues no longer do.
We have one particular site that is Symfony and uses the e-commerce bundle Sylius.
Our developers are trying to use Vagrant so we can have similar dev environments. We use Puphpet to generate the Vagrant instance and share the config file.
If we are working on the site/repo natively or on a staging server, all runs fine. Pages load in around 2-3 seconds.
When we are using Vagrant / Virtualbox, it's 30-35 seconds per page load.
So far we've tried
Allocating up to 6GB to the box
Giving up to 4 processors to the box
Turning on NFS for file sync
Turning off all other programs on computers running Vagrant / Virtualbox (chat, other browsers, etc)
None of those things made an impact on page load time.
I can provide 2 things. One is the load trace from Symfony: https://nimbus.everhelper.me/client/notes/share/708707/mvw707mckzm2wq4rlkzc
Since there is so much code to the puphpet config, I put it in a pastebin here: http://pastebin.com/7ciVA5FL
What is OS on a host machine?
My guess would be that file system is slow. Try to run an app outside of shared folder on the guest machine. If it will be fast, then you'll spot a problem at least.
NFS on *nix or mac should be fast enough, are you sure you've succeed to turn it on?
I had this pain once, and finally started to use unison instead of native vagrant's file sharing system (https://www.cis.upenn.edu/~bcpierce/unison/)
Have your tried:
http://www.whitewashing.de/2013/08/19/speedup_symfony2_on_vagrant_boxes.html
or http://jeremybarthe.com/2015/02/02/speed-up-vagrant-environment-symfony2/
I think the first one is already included in Sylius, but not sure.
Also, dynamic image resize/crop may be reading/writing in the host file system and maybe there's a way to also change that (using symlinks or similar)?
vagrant-winnfsd works fine for me for getting NFS to work on Windows.
Apparently this is a rather known issue: Vagrant/VirtualBox/Apache2 Strange Cache Behaviour, http://smotko.si/nginx-static-file-problem/, https://twitter.com/meinharrd/status/580098162716774400, that attempting to use VirtualBox with Nginx or Apache exhibits buggy behavior (modifying a file will update the contents, but not the length, so making it shorter leads to garbage at the end, and making it longer just truncates at the original length). The solution is always to disable sendfile.
So I disabled sendfile and this actually fixed my problem, but now I see all of those static files taking 2-3 seconds to load every time.
Has anyone seen this sort of behavior before? I'm specifically using Boot2Docker to run Nginx and an app in PHP
There is a known issue on github about volume performance in boot2docker: https://github.com/boot2docker/boot2docker/issues/593
In that issue there is an interesting link about a A productive development environment with Docker on OS X.
What about a shared folder in VirtualBox?
Don’t use this feature for nginx inside a VM, create a real shared resource on the host instead.
I've run into an issue with Saltstack version 2014.7.0, where I cannot get network information from Salt.
If I run:
salt-call network.ip_addrs
I get:
Function network.ip_addrs is not available
This only seems to happen on some of my hosts. It seems to effect the almost all of the functions in salt.modules.network, but everything else works as expected.
I suspect there's something in my environment to blame. I am running salt within a CentOS 7 docker container. I followed these instructions to get Systemd running under Docker, and it seems to be functioning just fine, so I don't think that's the issue, but I wouldn't be surprised if it's related. I'm using Docker as a development environment, but I will be using these formula to orchestrate virtual machines in production.
Has anyone encountered the network module not being loaded properly? Is there something that needs to be available for that module to be accessible?
I have other mechanisms to get the IP address, but none that are as easy to work with in other salt formulas.
It turns out my problem was that I had my own custom module called "network" which was obscuring the upstream network module.
I'm pretty sure this was working at some point in the past, so I'm wondering if there might have been a change to salt in a more recent version that would cause it to conflict at a module level instead of merging methods from different modules of the same name, but I suppose it's possible that it never worked.
I have inherited a web application and when trying when trying to put it on the same server on a different IP and IIS site I get a page full of stuff like this in all browsers. (not sure how the server here will output this but it is basically the same as if you were to open a binary in a text editor or bad character encoding).
���r#ə6��{��Ί��&��6�K�MЀh��"Pd�AP;�RN�K9�r��<ϛ���!��GZ�4��J�z�����R'���i�j�uZLe�V`=��&��T!e]rGVx#d��N���V���w>���pc�hw��B>��^�|L�]��3�~-��g��n��n�i�>Z� �ٲ������z_�����U�,i��2��\�+���F��FB���m��r�7�v��7�}�U�N�o�G�K�o?�w凲��و�����ߓ�x!���_?��V��v�/V��olt˭Z����� >M�kwkh&��j�C3�|̓��=�8��jJ����Uo�~��T7�\w�eW�������u*���f0c��}�.����]o������7���|�;}�&O���N�)[ys��+Q��o�T�~����F����c���έm��.�Q�ů�2#P���i�ˠ�~g��u�<| $ۭ>zZ/e��'�;R�'���v�ˠ�����
I've copied the same build and all its files to the site running under another IP, used the <globalization> web.config tag and set all encoding to UTF-8 and for the hell of it I even tried setting it to ASCII.
The application, although written for users in only US cities does make use of localization resource files for Russian and Romanian since it had been outsourced to developers there. I guess they did so to make things easier on developers who may have been less fluent in english, who knows.
Besides using the exact same copy running in production and changing web.config encoding settings I have found it runs fine on my IIS 7/Windows 7 workstation, tried throwing a uncompiled copy up there with .cs files and all, wrote a simple ASPX page that performed a response.write (which came out fine).
So as you can see I am pretty much at a roadblock and decided to ask the fine professional community we have here. Any input you may have on this matter would be highly appreciated.
I fixed it by exporting the IIS settings for the production system that it worked fine on and created a new IIS site from that file. Sadly I could see no difference between the 2 before I did this but if you run into this issue then here is another thing you can add to your list of troubleshooting tasks.
It's probably a long shot based on your description, but from a little Internet digging, a couple of forum posters have mentioned bad NICs corrupting packets. You did say you had the app on a different IP on the server -- does your server have more than 1 NIC?