Sylius: Can't install project on Windows

[jurchiks]

When running php app/console sylius:install in the console, after the progress bar goes to 37%, something goes wrong and I get blasted with a shitton of stack traces all about Twig.

$ php app/console sylius:install
Installing Sylius...

Step 1 of 4. Checking system requirements.
+------------------------------------+------------------------------------+
| Issue                              | Recommendation                     |
+------------------------------------+------------------------------------+
| sylius.settings.short_open_tag     |                                    |
| sylius.settings.session.auto_start |                                    |
| sylius.extensions.accelerator      | sylius.extensions.accelerator.help |
+------------------------------------+------------------------------------+
Success! Your system can run Sylius properly.

Step 2 of 4. Setting up the database.
Creating Sylius database for environment dev.
It appears that your database already exists. Would you like to reset it? (y/N) y
 3/8 [|||||||||||                 ]  37%PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 4096 bytes) in C:\Users\Juris\Desktop\sylius\vendor\twig\twig\lib\Twig\Node.php on line 229

After checking the install script, it seems the error occurs on the command cache:clear, which is executed in InstallerBundle\Command\InstallDatabaseCommand.php (added on line 83).

This matches the progress percentage, since doctrine:database:drop, doctrine:database:create and doctrine:schema:create have no errors, but when running cache:clear directly, the command does something for at least 20 seconds, then throws an exception that shouldn't occur in a console command:

$ php app/console cache:clear
Clearing the cache for the dev environment with debug true
PHP Warning:  Uncaught UnexpectedValueException: There are not any requests on request stack in C:\Users\Juris\Desktop\sylius\src\Sylius\Component\Channel\Context\RequestBased\ChannelContext.php:78

I know you don't care about Windows, but this doesn't seem like a Windows-only error...

[tristanbes]

Allowed memory size of 134217728 bytes exhausted
You should increase your memory settings inside php, restart php and see if it fixes the error.

[jurchiks]

You know, if 128MB is not enough to CLEAR THE CACHE, then there's something wrong right there.
I increased the memory_limit to 256MB and that helped for the cache part, although it lasted a good two minutes, which is terrible.
On the next step though (loading sample data), it threw the same error, but this time even 256 MB was not enough. I mean cmon guys, have you ever heard about any kind of optimizations?

This is already enough info for me to determine that this project is not good enough for me.

[tristanbes]

Try running any Windows product on 128mb RAM... ;)

Clear cache also generates / warmup the cache. That's generic to Symfony.

I run with memory limit 1go. Just because we're in 2016.

Envoyé de mon iPhone

Le 18 mars 2016 à 23:18, Juris [email protected] a écrit :

You know, if 128MB is not enough to CLEAR THE CACHE, then there's something wrong right there.
I increased the memory_limit to 256MB and that helped for the cache part, although it lasted a good two minutes, which is terrible.
On the next step though (loading sample data), it threw the same error, but this time even 256 MB was not enough. I mean cmon guys, have you ever heard about any kind of optimizations?

This is already enough info for me to determine that this project is not good enough for me.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[jurchiks]

Try running any Windows product on 128mb RAM... ;)

You don't even run Windows, do you? There's plenty of Windows software that runs on 128MB and less. But this isn't Windows software, this is a PHP website, so that argument is not applicable here.

[nakashu]

@jurchiks running it in dev on windows without a problem regullary.

There are couple of things:

• Places where hit the memory limit, are thing development environment stuff. Eg. you wont drop db and load sample data in production
• You are running in development environment, eg most optimalizations are disabled so you will see changes right away
• Cache clearing and warming is 90% done during deployment process. that is run with console most of the time, where memory limits are usually set up quite higher.
• Sylius is still in development and the version is not even beta yet. Optimalization will have its time.

On my local machine, average sized shop - frontend memory consumption is 8-30MB in development environment. In production it goes drastically down.

[jurchiks]

Sylius is still in development and the version is not even beta yet.

So you wouldn't recommend using it for a production site?

[okwinza]

@jurchiks totally not on windows.
Otherwise it's pretty much production-ready, provided you've got some experience with sf2.

[jurchiks]

I want to develop it on windows, obviously it will be hosted on linux.
This is a PHP project, so it should not be platform-dependent.

[okwinza]

This is rather big "PHP project" with tons of dependencies so there are some aspects which behave a little different on windows. This in turn leads to bugs and/or to overall failure.

Your best bet is to use docker.There should be working config somewhere in this repo if i'm not mistaken.

And make sure your memory limit is enough for developing purposes botn in your php.ini and php-cli.ini. 1G should be ok.

[peteward]

Sylius is one of the largest Symfony2 projects written and exposes some interesting issues around memory consumption within the framework and some of the framework's dependent libraries.

As others have mentioned here, clearing the cache of a large project can be a heavy task that grows considerably the larger the project, critically the larger the container, the more dependencies and the more twig templates.

I had the same opinion as you that the amount of memory required sounds insane, but it is a reality of well-architected, large, modern PHP projects on the Symfony framework that you need a lot resource to prepare them.

In Symfony, the main culprit of heavy memory usage in clearing the cache, used in a several of the actions called is the PHP token_get_all() function. This has been proven to eat large amounts of memory when parsing very large strings. It is currently used:

• When compiling the container - Due to Sylius's excellent architecture it has one of the largest Containers that you will find in any open source Symfony project, but it exposes high memory usage here.
• Parsing Twig templates for compilation.
• Parsing Twig templates for assetic asset warmup.

If you really need to clear cache or compile the container under limited memory situations then you can try the following:

• Increase your PHP memory_limit hugely for development and compilation environments. PHP memory_limit was really designed when RAM was much more of a commodity than it is now and it's only real use as a setting now is s safeguard in production to avoid runaway requests.
• Use PHP7!
• Run cache clearing without optional warmers (this will slow down page generation for the first request to each page as twig has to compile, but will prevent running out of memory).
• Apply the fix here from the symfony core team to reduce memory when compiling the container (or wait patiently until it's deployed in the next Symfony release).

I was of the same opinion as you that surely sites shouldn't need this much RAM?! - well, modern PHP applications do need it for building, it's a reality of the PHP ecosystem in 2016. But the above can help you offset this _if you REALLY need to_, but for dev just set a very high PHP memory_limit.

[jurchiks]

Too bad it's based on Symfony...

[axelvnk]

I think this issue can be closed. It's not a windows issue.. It's a symfony issue.

What I do to get this thing running in production, I override the stripComments static method in AppKernel to skip actually stripping docblocks from the container.

public static function stripComments($content) { return $content; }

Obviously this is not ideal but cache is loaded quite fast now and overall performance is great.