I have many tests in laravel app.
They make POST/GET requests and check responses.
Every test is performed using DatabaseMigrations trait.
On my laptop it takes about 20 seconds for every test to be finished.
I do not want to write different repositories for different types of queries so that I can later mock them (extra work).
May be there is a better solution?
You should use in memory testing using SQLite:
'testing' => [
'driver' => 'sqlite',
'database' => ':memory:',
'prefix' => '',
],
In this case, migrations and seeders will create data filled tables really quick.
Related
redis info memory:
used_memory_human:1.95G
used_memory_rss_human:1.93G
used_memory_peak_human:2.04G
used_memory_peak_perc:95.63%
I use Laravel Horizon and it is the only thing that uses redis.
Now it reached 2GB limit and stay like this
First question:
Why there is 2 GB limit and how to increase it? maxmemory set to 0
Second question:
I think there not that much jobs pending on Laravel Horizon to fill up 2GB, looks like trimmer or something not working. Jobs are small, not much information stored. There is about 1-2k jobs per hour and maybe pending around 3-4k.
My trim settings from horizon.php:
'trim' => [
'recent' => 60,
'pending' => 43200,
'completed' => 60,
'recent_failed' => 10080,
'failed' => 10080,
'monitored' => 10080,
],
Where to look next? Everithing working so far but I don't like the situation. Once with big batch of jobs we faced allocate memory issue (Allowed memory size of 536870912 bytes exhausted)
I have a problem with the laravel queue system. For performance purposes we use laravel queuing system with amazons SQS for heavier calculations. This works fine at least for most of our jobs. Some of them where the raw calculation time is about 25 seconds keep blocking the queue in the "Procesing" state for 6 minutes.
We did log the complete handle function of the job and the output was right at any time. As a matter of fact the last log statement (end of the function) was printed 20 seconds after entering the function. The data was calculated as expected and the database was up to date but the job was still "Processing".
After we intentionally crashed the job at the end of the handle function the calculated data was stored perfectly but obviously the queue crashed as well. So i guess it has to be something happing after the handle function. Maybe something with allocated memory?
The config of the queue is the default sqs driver configuration:
'sqs' => array(
'driver' => 'sqs',
'key' => env('AWS_KEY', 'secret'),
'secret' => env('AWS_SECRET', 'secret'),
'queue' => env('AWS_SQS_QUEUE', 'secret'),
'region' => env('AWS_SQS_REGION', 'secret'),
),
Edit:
I found out it is not only the queue but when I execute the job as a command the same behavior appears:
I print "Done." as the last statement in the command and after it gets printed the console halts for a few seconds before returning to the console input.
When I comment out the part where the most queries are the issue is gone, like the more queries I use the more I have to wait for the console.
I hope any of you guys know what causes this behavior and how we can fix it.
Thanks in advance
Ok I found the issue.
The problem was that telescope was enabled. So after the code was executed telescope was busy logging all requests and cache hits.
After disabling telescope there was no delay any more.
Running laravel 5.4 using DB sessions driver. Randomly I have thousands of
update `sessions` set `payload` where id ....
when viewing the process list via mysql.
Seems like Laravel decides to update tons of sessions suddenly, causing the whole database to become unresponsive (DB running on dedicated server) and the max connections gets filled up pretty quick. I have a long session lifetime (as I don't want to log out the users) and in result the sessions table is quite huge.
I tried to limit the lottery to 0, 100 in case that would have been causing the issue but it has not helped.
Any ideas what could cause this / what I could try?
sessions table is INNODB, indexes in id and user_id
I had the same issue last week.
Your mind blows because you really don't know what is going on or even worse: what it's causing this issue.
I was using the database session drive for nearly 2 years and this situation never happened before.
The solution was to change the session drive to REDIS.
In config/session.php change the connection key:
'connection' => 'session'
In config/database.php add the following lines on redis entry:
'redis' => [
'cluster' => false,
'default' => [
'host' => env('REDIS_HOST', 'localhost'),
'password' => env('REDIS_PASSWORD', null),
'port' => env('REDIS_PORT', 6379),
'database' => 0,
],
'session' => [
'host' => env('REDIS_HOST', 'localhost'),
'password' => env('REDIS_PASSWORD', null),
'port' => env('REDIS_PORT', 6379),
'database' => 1,
],
],
The reason to add one more entry 'session' is:
If you run:
php artisan cache:clear
ALL OF YOUR SESSIONS WILL BE CLEARED TOO, not only the cache itself.
So, to avoid that, just add this new entry.
You can find more info here:
Redis As Session Driver With Laravel
I have installed Laravel Horizon to mange my queues, and inside the published config there are these settings:
'local' => [
'supervisor-1' => [
'connection' => 'redis',
'queue' => ['default'],
'balance' => 'simple',
'processes' => 3,
'tries' => 3,
],
],
In the processes setting:
How can I determine the number of processes I should use in a real
world app?
Is there a limit?
This is really a guess until your application is in the real world. You need to balance acceptable wait times for jobs to kick off with projections on how often jobs will be scheduled and how long they will take to run. A reasonable upper limit is going to be heavily dependent on the hardware you're running on and the overall server workload.
It's probably not worth spending too much time on this ahead of time vs monitoring it and dialing it in as you get up and running.
I have a performance issue in one private API of Proces interface of Work In Process "wip_movProc_priv.processIntf". It takes around 2.5 Minutes for all transaction and
When I run this API in R12.1.3 instance it not take this much amount of time.
wip_movProc_priv.processIntf (p_group_id => p_group_id,
p_proc_phase => WIP_CONSTANTS.MOVE_VAL,
p_time_out => 0,
p_move_mode => 3, --WIP_CONSTANTS.ONLINE,
p_bf_mode => WIP_CONSTANTS.ONLINE,
p_mtl_mode => WIP_CONSTANTS.ONLINE,
p_endDebug => 'T',
p_initMsgList => 'T',
p_insertAssy => 'T',
p_do_backflush => 'F',
x_returnStatus => x_returnstatus);
Please help me.
Thanks,
Yasin Musani
This question has actually far too little detail to be answered.
Typically, the majority of time spent for Oracle EBS code execution is due to few badly performing SQLs.
You can identify the offending SQLs by looking at the AWR or SGA e.g. using Blitz Reports DBA AWR SQL Performance Summary or DBA SGA SQL Performance Summary and would then need to analyze further why these are not executing properly.