Avez-vous identifié le point de ralentissement de votre application?
Varnish et Squid sont des reverse proxy qui vont soulager le serveur
web en requêtes http et qui vont être plutôt lourds à mettre en place
(comme vous l'avez souligné en plus sous windows).
Par expérience, un conseil général si vo
@Magnus mac solution worked for me but only when the directories are
empty. Had problems when cache/log files existed before running
command.
On Mar 28, 6:42 pm, Venzon wrote:
> I solved this issue by adding unmask() in first line of my kernel file
> because my admin is not going to change a
The changes have been submitted in a PR:
https://github.com/symfony/symfony/pull/620
On Apr 22, 10:25 am, Victor Berchet wrote:
> I should have something ready with a breaking new API for the cache
> warmers later today...
>
> Hope this can be integrated in Sf2.0
>
> On Apr 21, 2:20 pm, Victor Be
I should have something ready with a breaking new API for the cache
warmers later today...
Hope this can be integrated in Sf2.0
On Apr 21, 2:20 pm, Victor Berchet wrote:
> Lukas,
>
> There is the event debug panel, I have nothing more.
>
> I was thinking of adding the priorities there when I did
I solved this issue by adding unmask() in first line of my kernel file
because my admin is not going to change any group rights...
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscrib
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
you could also run the commands with
sudo -u www-data ...
or have a console where you "sudo su www-data" and then run the commands
as user www-data. this way, you won't have to retype your password if
you repeat the command after a longer idle time.
c
AFAIK setuid doesn't work on shell scripts by security reasons.
at least on linux.
Tyrael
On Fri, Mar 25, 2011 at 10:00 AM, Miha Vrhovnik wrote:
> I have moved all the directories that have to be writable by websever under
> one dir app/var and was then for long time executing the 3 commands by
I have moved all the directories that have to be writable by websever under
one dir app/var and was then for long time executing the 3 commands by hand.
A couple of days ago I then created a simple shell script which I now run
instead.
#!/bin/sh
./console cache:clear
./console cache:warmup
chown
Le 28/02/2011 21:34, Kris Wallsmith a écrit :
It looks like the ORM saves auto-generated proxy classes to the database:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L155
The MongoDB ODM as well:
https://github.com/doctrine/mongodb-odm/blob/master/lib/
It looks like the ORM saves auto-generated proxy classes to the database:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L155
The MongoDB ODM as well:
https://github.com/doctrine/mongodb-odm/blob/master/lib/Doctrine/ODM/MongoDB/Proxy/ProxyFactory.php#L151
On 28.02.2011, at 21:22, Benjamin Eberlei wrote:
> auto generating proxies generates the proxy on EVERY request.
oh .. thats pretty bad indeed.
ok then, i guess this means that such users need to configure cache warming for
just the bare minimum, like proxies. in this case we should again not
auto generating proxies generates the proxy on EVERY request.
On Mon, 28 Feb 2011 19:44:55 +0100
Lukas Kahwe Smith wrote:
>
> On 28.02.2011, at 17:17, Benjamin Eberlei wrote:
>
> > One reason cache warming was introduced are Doctrine Proxies, they NEED to
> > be generated on the first request
On 28.02.2011, at 17:17, Benjamin Eberlei wrote:
> One reason cache warming was introduced are Doctrine Proxies, they NEED to
> be generated on the first request or otherwise you are using the
> auto-generate strategy which is very slow on multi user enviornments and
> has the risk of cache slams
One reason cache warming was introduced are Doctrine Proxies, they NEED to
be generated on the first request or otherwise you are using the
auto-generate strategy which is very slow on multi user enviornments and
has the risk of cache slams (granted, first request generation has the
cache-slam prob
On 02/27/2011 11:47 AM, Lukas Kahwe Smith wrote:
That being said what is the target audience for this feature?:
1) people that do not want to bother themselves to call the CLI command
2) people that do not have access to the CLI command
I do not think we really need to deal with 1), this group s
Hi Kris,
I'm afraid not ("this should already be fixed in our release. But it
seems not to be").
Obviously this is something that won't be easily repeatable, so I
understand any scepticism. Despite my best efforts, I've been unable
to.
On a tangent, regarding http://trac.symfony-project.org/ch
So, it sounds like this has been a productive discussion then? Am I
correct in understanding the issue is resolved?
--
Kris Wallsmith | Release Manager
kris.wallsm...@symfony-project.com
Portland, Oregon USA
http://twitter.com/kriswallsmith
On Sep 1, 2009, at 5:24 AM, Jarno Rantanen wrote:
>
Hi,
Continuing this discussion with myself, I found a ticket regarding this:
http://trac.symfony-project.org/ticket/5729
This was fixed in the 1.2 branch in [15257], but since 1.2.4 (which is
the exact version we're running) was tagged in [15266] this should
already be fixed in our release. But
Hello,
Happened again today, and we had time to get a copy of the broken config
cache file and compare it to the properly generated one. Here's a diff:
$ diff config_factories.yml.php_ok config_factories.yml.php_broken
3c3
< // date: 2009/09/01 09:10:19
---
> // date: 2009/09/01 09:06:56
34c34
that whas it!
thank you very much!
On 6/11/07, Alexander Deruwe <[EMAIL PROTECTED]> wrote:
>
>
> On 11 Jun 2007, at 09:23, Oriol Mercadé wrote:
> > My routing yml is something like
> >
> > es_homepage:
> > url: /es/
> > param: { module: home, action: index, sf_culture: es }
> >
> > en_homepage
On 11 Jun 2007, at 09:23, Oriol Mercadé wrote:
> My routing yml is something like
>
> es_homepage:
> url: /es/
> param: { module: home, action: index, sf_culture: es }
>
> en_homepage:
> url: /en/
> param: { module: home, action: index, sf_culture: en }
>
> homepage:
> url: /:sf_culture/
21 matches
Mail list logo
