Cytat(Pyton_000 @ 4.12.2017, 21:32:56 )

No tak, trochę przekoloryzowałem z tym natywnie

Chodzi o to że nie wymagany już jest virtualBox który zwalniał prze swoje montowania FS
Tak, ale wciąż są dwa różne systemy plików, z dwiema różnymi cechami (uprawnienia, przestrzenie, symlinki, ioevents etc), takie połączenie między dwoma systemami musi zapewne lecieć po jakiejś wewnętrznej sieci (SMB), problemem nie są tyle co duże pliki, co dużo małych plików. Dlatego czasy odczytów są fatalne. I zawsze będą.
Cytat(markonix @ 5.12.2017, 02:24:13 )

Tak, przez natywność rozumiem Hyper-V, który jest też formą wirtualizacji tyle, że dostępną od razu w Win 10.
Nie laptop, komputer stacjonarny.
Głównie mnie ciekawi ten objaw opóźnienia, który jest proporcjonalny do przerwy, maksymalnie dochodzi do 10 sekund.
Na razie czym idę dalej tym jest gorzej więc wątpię aby to się samo rozwiązało.
Jak nie ma jakichś ciekawych rozwiązań dla Laradock'a to będę próbował jeszcze na próbę spróbować jakiś inny, czysty obraz z samą podstawą bo jestem ciekaw czy to problem z samym Laradockiem, Dockerem na Win czy czymś innym.
Odpal sobie
Kod
docker volume ls
a następnie sprawdź ile masz volumenów, oraz w jaki sposób one są podmontowane. Dla przykładu, w katalogu projektu będziesz miał najczęściej: katalog ".git" który może być spory, katalog ".idea" jeżeli korzystasz z phpstorma i zapewne temu podobne. Wszystkie te katalogi są ci w ogóle niepotrzebne w samym kontenerze, a ciągłe aktualizacje w tych katalogach po prostu nadużywa i tak już wolnego "połączenia" pomiędzy wirtualką z dockerem a samym windowsem/makiem. A z tego co widzę po tych plikach, to tam nawet baza danych jest zmontowana lokalnie, co daje kolejny ogromny narzut. Użyj jakiegoś innego rozwiązania, gdzie będziesz miał rzeczy które są ci potrzebne i porównaj czy wciąż będzie to chodzić tak gównianie.
Cytat(batman @ 5.12.2017, 07:27:28 )

To nie jest wina Windowsa, tylko Dockera. Działa on natywnie tylko na Linuksie, pozostałe systemy muszą w jakiś sposób "wirutalizować" środowisko, w którym pracują. Najgorzej jest, gdy korzysta się z volumes. Znalazłem trzy rozwiązania problemu, z których przetestowałem dwa. Oba działają raczej średnio. Aktualnie przymierzam się do skorzystania z docker machine i kontenerów postawionych na virtual boksie.
P.S.
W grudniu wychodzi nowa wersja aplikacji na maca (i prawdopodobnie na windowsa). Może udało im się naprawić problem wydajności.
To jest wina windowsa, jak i osx'a. Gdyby te systemy w jakiś łatwiejszy sposób umożliwiały czy to wirtualizowanie czy konteneryzowanie innych systemów, o obsłudze innych niż "słuszne" NTFS systemów plików nie wspominając (oczywiście w przypadku windowsa), to by się to wszystko lepiej integrowało. A tak z racji sporych różnic pomiędzy systemami, powstała proteza, żeby użytkownicy windowsa czy osx'a nie byli gorsi i mieli swojego "natywnego" dockera, bo wiadomo, teraz kontenery są hiper popularne. Na codzień pracuje na osx'ie, wcześniej pracowałem głównie na ubuntu i przejście było najbardziej bolesne, kiedy się okazało jakim kastratem jest osx pod względem narzędzi developerskich na których dotychczas pracowałem. Nie zrozumcie mnie źle, windows, mak czy linuks to są dobre systemy i każde z nich ma swoje zalety i wady. Jako że dla mnie istotny jest development, to z automatu na samym końcu ląduje windows. Maka mocno ratuje społeczność i uniksowa kompatybilność. Gdyby stworzyli coś zupełnie swojego, zapewne byłoby tak samo jak z windowsem..
Aby podsumować ten wywód, na windowsie czy maku istotne jest to co montujecie. Jak twój projekt jest w katalogu `~/projects/my-project` a w katalogu projektu istotne są tylko katalogi `~/projects/my-project/vendor` i `~/projects/my-project/src`; to montujcie tylko te dwa katalogi, zamiast całego katalogu z projektem. Nie montujcie plików z bazy danych - użyjcie named volumes (nie przepadną wam dane, ale nie będziecie tego montować lokalnie). Jak pracujecie na wersjach developerskich aplikacji, mimo wszystko włączajcie cache i inne. Jeżeli w projekcie macie pliki które mają różną wielkość znaków, pilnujcie żeby odwołania do tych plików były prawidłowe, z racji tego że windows czy mak ignorują wielkość znaków (na maku można to wyłączyć) to będzie wam szukało plików w kilku wariantach, co będzie minimalnie wolniejsze.
Jeżeli mimo tego aplikacja działa wolno, a dockera używacie bo to jest "fajne", to zastanówcie się nad po prostu instalacją projektu lokalnie. U mnie używam kontenerów w developmencie, stagingu oraz produkcji. Nie mniej, debugowanie kodu lokalnie, w kontenerach do których nie ma się łatwego dostępu (w przypadku maków ułomna jest też sieć, nie istnieje interfejs docker0 dzięki któremu można dostać się do kontenera po jego IP, trzeba wszystko bindować lokalnie i dostawać się po localhost..), staram się aby tylko bazy danych działały w kontenerach, a samą aplikacje odpalam lokalnie i łącze się do tych baz danych. Nie ma innego wyjścia, trzeba sobie jakoś radzić..