meenie / munee

Munee: Standalone PHP 5.3 Asset Optimisation & Manipulation
https://munee.herokuapp.com/
MIT License
833 stars 92 forks source link

loadding website too long #78

Open jksbill opened 9 years ago

jksbill commented 9 years ago

the first time i visit my website use munee, it loadding too long, is that normal?

meenie commented 9 years ago

@jksbill, sorry, just saw this. Before you were using Munee, did you find that it loaded fast the first time?

If you were to clear your browser cache, is it slow to load again? Or is it slow to load if you modify an asset running through Munee and then reload the page? If it's the former, then it's most likely either your ISP's connection to the server your website is hosted on and it has a rather slow connection. The subsequent times you load the page, the assets will be cached locally in your browser. If it's the later, then your server may need more processing power to recompile the assets faster.

bezumkin commented 9 years ago

After updating Munee with composer I see this

Fatal error: Maximum execution time of 30 seconds exceeded in /home/test23/.../munee/vendor/sabberworm/php-css-parser/lib/Sabberworm/CSS/Parser.php on line 592

On line 590 is

private function substr($sString, $iStart, $iLength) {
        if ($this->oParserSettings->bMultibyteSupport) {
            return mb_substr($sString, $iStart, $iLength, $this->sCharset);
        } else {
            return substr($sString, $iStart, $iLength);
        }
    }

This happends each time after clear cache. Next load is normal.

It seems that this PR fixing the problem.

elkangaroo commented 9 years ago

I can confirm huge speed issues with munee 1.6.0.

The good thing: images are not effected (yay!). The not so good thing: javascripts are minorly effected (just a bit slower than before). The bad and really ugly thing: stylesheets are majorly effected (a f***ing lotta slower than before)!

I've done some non-scientific (5 requests each by hand) benchmarks to show the extend. Each request was made with empty browser cache and empty munee file cache.

Here's the result for TTFB (Time to first Byte):

# munee 1.5.20
> css (204kB, combine 11 files, minify) :: TTFB 197ms, 193ms, 178ms, 205ms, 210ms
> js (197kB, combine 14 files, minify) :: TTFB 1.02s, 989ms, 960ms, 996ms, 909ms

# munee 1.6.2
> css (204kB, combine 11 files, minify) :: TTFB 31.14s with PHP Fatal error:  Maximum execution time of 30 seconds exceeded
> js (197kB, combine 14 files, minify) :: TTFB 1.26s

after page refresh
> css (204kB, combine 11 files, minify) :: TTFB 13.25s

# munee 1.6.2 with fix by @bezumkin
> css (204kB, combine 11 files, minify) :: TTFB 3.21s, 3.26s, 3.16s, 3.51s, 3.18s
> js (197kB, combine 14 files, minify) :: TTFB 1.27s, 1.36s, 1.25s, 1.24s, 1.27s

That said, I think it's clear that the css parse time has become unacceptable. As mentioned by @bezumkin, the mb_substr seems to be the reason for most of the processing time, but even after the fix, css parsing is still ~15 times slower than with munee 1.5.20.

More profiling is needed to verify where the processing time is gone, as there has been quiet some changes from munee 1.5.20 to 1.6.0, including the new css minfier and css parser.

As sabberworm/php-css-parser doesn't seem to be actively maintained, maybe it's a good idea to look for alternatives (or fork it and fix the performance, I did not yet look into the library).

~ Alex

meenie commented 9 years ago

Thanks a ton for this Alex! I will definitely look into alternatives for the css parser this weekend. I feel awful that this has been plaguing Munee for so long ><. To be honest, I haven't actually used this library in a long time because I use Grunt or Gulp to do all my processing during deployment.

meenie commented 9 years ago

This has been temporarily fixed by #83. Will keep this open to keep track of the issue. Thanks @bezumkin !