I turn on caching the component by editing cache.yml file in my module
_startpage:
enabled: true
contextual: true
lifetime: 60
There was no time difference after that but I think the component is cached because there is a symfony cache box over it (With cache info). I realized that the number of queries to DB is the same as without caching - component for sure execute some queries so why the number of queries did not changed?
Solved.
factories.yml
view_cache:
class: sfFileCache
param:
automatic_cleaning_factor: 0
cache_dir: %SF_TEMPLATE_CACHE_DIR%
lifetime: 86400
prefix: %SF_APP_DIR%/template
Related
In a Symfony 4.3 application with Elastcsearc 6.8 plus friendsofsymfony/elastica-bundle v5.1.0
an index creation task takes 18 minutes to complete either with or without enqueue/enqueue-bundle 0.9.12 and enqueue/fs 0.9.12. Is there a package I'm missing (altho' enqueue says it's a complete solution) or a configuration error?
fos_elasitica.yaml:
fos_elastica:
serializer: ~
clients:
default: { host: localhost, port: 9200 }
indexes:
house_date:
types:
house_date:
serializer:
groups: [house_date]
persistence:
# the driver can be orm, mongodb or phpcr
driver: orm
model: App\Entity\Contact
provider: ~
finder: ~
enqueue.yaml:
enqueue:
default:
transport: '%env(resolve:ENQUEUE_DSN)%'
client: ~
enqueue_elastica:
transport: '%enqueue.default_transport%
'
Edit:
After much exploration I've inched along but without ultimate success. Added was enqueue/elastica-bundle and enqueue.yaml has been edited to appear as above.
[An identical installation in Windows reaches a 256M memory limit at about 54% completion, again regardless of the presence of the enqueue components.]
It is likely true that the seemingly long time to populate the index was the result of an improper definition. The definition incorporated four entities (via relationships). By changing Contact to Household, which has a one to many relationship with Contact, time to populate the index was reduced was reduced by a factor of 10. As a result I'm abandoning this question and marking it Answered.
I have a reporting application build with Symfony 2.8.14/ Doctrine. One of my reports takes about 2 minutes to run and executes a series of queries (https://dba.stackexchange.com/questions/157981/reporting-query-blocks-other-query-but-isolation-level-read-uncommitted-set/159495#159495).
I have found that the locking appears to be happening at Symfony level, because the same pages can be loaded no problem if I switch into app_dev.php/ or run the MySQL queries on the command line, while the report is running.
Is there a connection limit or other locking I could have turned on accidentally?
My Doctrine configuration
# Doctrine Configuration
doctrine:
dbal:
default_connection: default
connections:
default:
driver: pdo_mysql
host: "%database_host%"
port: "%database_port%"
dbname: "%database_name%"
user: "%database_user%"
password: "%database_password%"
charset: UTF8
options:
1001: true
orm:
auto_generate_proxy_classes: "%kernel.debug%"
default_entity_manager: default
entity_managers:
default:
connection: default
naming_strategy: doctrine.orm.naming_strategy.underscore
mappings:
AppBundle: ~
FOSUserBundle: ~
errorlog:
connection: default
naming_strategy: doctrine.orm.naming_strategy.underscore
mappings:
AppBundle: ~
Apache2 configuration - mpm-itk
<IfModule mpm_itk_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 150
MaxConnectionsPerChild 0
</IfModule>
Not using PHP-FPM as stated in comments, but using mod_php:
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
I'm running MySQL 5.7.11 on m4.2xlarge which according to this: http://pushentertainment.com/rds-connections-by-instance-type/ allows for 2500+ connections.
Almost every time I've encountered locking that wasn't in the database, it has been PHP session serialization.
With the default Symfony NativeFileSessionHandler, PHP will wait to obtain a file lock before opening the session file; the lock won't be released until session is closed (ie the request is finished). This helps avoid race conditions between processes reading/writing session data.
If this is the cause then opening 2 tabs in the same browser (print $session->getId to confirm the session ID is shared) will block, but trying with different browsers (different session IDs) will not block. Be aware that depending on the state of ignore_user_abort() previous requests cancelled in the browser but still processing will also block any new requests.
As to why this would work on dev/prod, differences in session handler settings in your config file will do this.
Alternately, if that's not the cause I'd use strace -p PID and /proc/PID to determine what system call the apache/PHP process is blocked on (can be annoying to work out which is the blocked process but you only have 5 apache processes and a 2 minute window to find the right one)
It's not caused by the symfony, its caused by the webserver. You can refer to my post about the laravel another php mvc frame requests.
To solve this run the time cost process in the background.
I have a weird issue, when I checked my app/log/dev.log I can see almost all of my queries in my dev.log being logged in real time:
[2015-01-27 06:57:22] doctrine.DEBUG: SELECT t0.username A ....
[2015-01-27 06:57:23] doctrine.DEBUG: SELECT t0.username A ...
[2015-01-27 06:57:23] doctrine.DEBUG: SELECT s0_.id ......
I have no idea why this is happening, since I am running the site on production mode also when I check monolog in my config.yml, this is what I see:
monolog:
handlers:
pictures:
type: stream
path: %kernel.logs_dir%/pictures_%kernel.environment%.log
level: info
instagram:
type: stream
path: %kernel.logs_dir%/instagram_%kernel.environment%.log
level: info
here's what my config_dev.yml looks like:
imports:
- { resource: config.yml }
framework:
router: { resource: "%kernel.root_dir%/config/routing_dev.yml" }
profiler: { only_exceptions: false }
web_profiler:
toolbar: true
intercept_redirects: false
monolog:
handlers:
main:
type: stream
path: %kernel.logs_dir%/%kernel.environment%.log
level: debug
firephp:
type: firephp
level: info
assetic:
use_controller: false
hip_mandrill:
disable_delivery: true
any idea how this could be happening?
You should use prod env on your production server. In the prod env doctrine's logging is disabled by default.
But if you want to disable logging at all (in all environments) you need to set up a config.yml like that:
doctrine:
dbal:
connections:
conn1:
driver: ...
...
logging: false
profiling: false
Reference: https://symfony.com/doc/current/bundles/DoctrineBundle/configuration.html
I encountered a similar issue with dev.log being generated on prod environment. I figured out from the log entries that what was causing my issue was a scheduled cron job calling a custom symfony command. Modifying the entry to app/console with --env=prod for my crontab since stopped dev.log being generated. i.e.
app/console --env=prod custom:command
Must have missed that section of the book :)
As I struggled with the same problem and my .log file was increasing its size the straight solution was when running the consumer use the flag --no-debug
php bin/console messenger:consume async_email_handler --no-debug
I have set the gc_maxlifetime in my config.yml file to 300. But its not working. Symfony2 still takes the value set in php.ini
Symfony version is 2.4.4
Try setting the cookie_lifetime parameters of the session config key.
session:
cookie_lifetime: 300 # override php.ini config
as described here
hope this help
Here is my approach (gotten from Drupal configuration):
set handler to native_file (i'd use PDOSessionHanlder, but seems it's not very stable);
create a seesions directory under app folder;
config.yml file:
session:
handler_id: session.handler.native_file
cookie_domain: %cookie_domain%
name: SFSESSID
cookie_lifetime: 2000000 # change this if you want
save_path: "%kernel.root_dir%/sessions"
gc_divisor: 100
gc_maxlifetime: 200000 # change this if you want
gc_probability: 1
We are using symfony 1.4 on our development machine
traditional way to cache partial in symfony is by editing cache.yml
something:
enabled: true
lifetime: true
this will store cache on the disk
but we want to store cache on memcache instead on disk.
so, the question is how to cache symfony partial in memcache
Symfony partial cache work like all other cache in symfony: it refers to view_cache part of apps/frontend/config/factories.yml.
For example, if you want to store your cache in SQLite database:
all:
view_cache:
class: sfSQLiteCache
param:
database: %SF_TEMPLATE_CACHE_DIR%/cache.db
So if you want to store these information into Memcached, you should use the sfMemcacheCache.class.php class:
all:
view_cache:
class: sfMemcacheCache
param:
servers:
server1:
host: localhost
port: 11211
persistent: true
OR
all:
view_cache:
class: sfMemcacheCache
param:
host: localhost
port: 11211
persistent: true