我尝试使用php event 扩展中的 EventHttp::setDefaultCallback.
发现在回调调用过程中,如果代码出现异常,在终端并不会打印异常消息。我必须使用try catch 捕获才可以。
按照我的理解,在fpm下如果出现异常,那么PHP会将错误打印到输出流上面去。那么也就是浏览器能接收到了。
这种终端启动的情况按说默认也应该打印输出到终端才对啊。为啥一点反应都没有。
百思不得其解,特来请教
一个默默无闻的PHP程序员,专注于后端!
没有足够的数据
魔王卷子 提出了问题 · 2月28日
我尝试使用php event 扩展中的 EventHttp::setDefaultCallback.
发现在回调调用过程中,如果代码出现异常,在终端并不会打印异常消息。我必须使用try catch 捕获才可以。
按照我的理解,在fpm下如果出现异常,那么PHP会将错误打印到输出流上面去。那么也就是浏览器能接收到了。
这种终端启动的情况按说默认也应该打印输出到终端才对啊。为啥一点反应都没有。
百思不得其解,特来请教
我尝试使用php event 扩展中的 EventHttp::setDefaultCallback.发现在回调调用过程中,如果代码出现异常,在终端并不会打印异常消息。我必须使用try catch 捕获才可以。按照我的理解,在fpm下如果出现异常,那么PHP会将错误打印到输出流上面去。那么也就是浏览器能接...
关注 1 回答 0
魔王卷子 回答了问题 · 1月22日
可以尝试在执行完毕后手动执行 fastcgi_finish_request() 试试看
可以尝试在执行完毕后手动执行 fastcgi_finish_request() 试试看
关注 3 回答 2
魔王卷子 回答了问题 · 1月22日
自己执行map,然后在里面执行 slice 进行处理
自己执行map,然后在里面执行 slice 进行处理
关注 3 回答 2
魔王卷子 回答了问题 · 2020-12-10
首先定义配置:
// file: config/mail.php
'mailers' => [
'demo' => [
'transport' => 'smtp',
'host' => env('MAIL_HOST', 'smtp.mailgun.org'),
'port' => env('MAIL_PORT', 587),
'encryption' => env('MAIL_ENCRYPTION', 'tls'),
'username' => env('MAIL_USERNAME'),
'password' => env('MAIL_PASSWORD'),
'timeout' => null,
'auth_mode' => null,
],
],
这里的demo
是我们设置的第二个邮件。那么调用的方法可以是:
IlluminateSupportFacadesMail::mailer("demo");
后面跟的就是你要操作的方法即可。
首先定义配置: {代码...} 这里的demo是我们设置的第二个邮件。那么调用的方法可以是: {代码...} 后面跟的就是你要操作的方法即可。
关注 3 回答 1
魔王卷子 赞了文章 · 2020-10-08
laravel-markdown-editor--markdown编辑器
此扩展包兼容laravel5.8以上版本
composer require wjcms/laravel-markdown-editor
//cconfig/app.php
'providers' => [
//添加如下一行
wjcms\laravelmd\LaravelmdServiceProvider::class,
]
php artisan vendor:publish --provider="wjcms\laravelmd\LaravelmdServiceProvider"
1.在blade模版引入
@include('layouts.md.md')
2.父模版中需要添加上
#注意在scripts上边需要引入jquery
@stack('styles')
@stack('scripts')
3.修改md.blade.php文件的 imageUploadURL修改为接口路径
4.创建service服务uploadservice.php,实现如下方法。
public function upload(UploadedFile $file)
{
$path = '/uploads/'.$file->store(date('y/m'), 'uploads');
return $this->save($file, $path);
}
//注意这里还需要创建Attachment模型和数据库(包含path,extension,name三个字段)
protected function save(UploadedFile $file, $path)
{
return Attachment::create([
'path'=>$path,
'extension'=>$file->extension(),
'name'=>$file->getClientOriginalName()
]);
}
5.admin控制器创建方法
/**
* 图片上传方法
*/
public function uploadPic(Request $request, UploadService $uploadService)
{
$res = $uploadService->upload($request->file('editormd-image-file'));
return response()->json([
'success'=>1,
'message'=>'图片上传成功',
'url'=> $res->path
]);
}
6.routes/web.php文件添加路由
use App\Http\Controllers\Admin;
//注意这里是laravel8的写法,之前版本自行修改
Route::prefix('admin')->name('admin.')->group(function () {
Route::post('upload', [Admin\AdminController::class,'uploadPic'])->name('upload');
}
就可以发现markdown编辑器可以使用了。
查看原文
原文连接:[链接]laravel-markdown-editor--markdown编辑器说明此扩展包兼容laravel5.8以上版本准备工作安装扩展包 {代码...} 配置providers {代码...} 拷贝相关文件到项目文件夹中 {代码...} 使用1.在blade模版引入 {代码...} 2.父模版中需要添加上 {代码...} 3.修...
赞 1 收藏 0 评论 0
魔王卷子 回答了问题 · 2020-09-27
/**
* 把返回的数据集转换成Tree
* @param array $list 要转换的数据集
* @param string $pid parent标记字段
* @param string $level level标记字段
* @return array
* @author 麦当苗儿 <zuojiazi@vip.qq.com>
*/
function list_to_tree($list, $pk='id', $pid = 'pid', $child = '_child', $root = 0) {
// 创建Tree
$tree = array();
if(is_array($list)) {
// 创建基于主键的数组引用
$refer = array();
foreach ($list as $key => $data) {
$refer[$data[$pk]] =& $list[$key];
}
foreach ($list as $key => $data) {
// 判断是否存在parent
$parentId = $data[$pid];
if ($root == $parentId) {
$tree[] =& $list[$key];
}else{
if (isset($refer[$parentId])) {
$parent =& $refer[$parentId];
$parent[$child][] =& $list[$key];
}
}
}
}
return $tree;
}
{代码...} 来源:[链接]
关注 3 回答 2
魔王卷子 收藏了文章 · 2020-07-21
Last-Modified: 2019年7月10日21:58:43
项目生产环境出现大量TIME_WAIT(数千个), 需要一一排查
先上总结:
统计TIME_WAIT 连接的本地地址
netstat -an | grep TIME_WAIT | awk '{print $4}' | sort | uniq -c | sort -n -k1
# ... 前面很少的略过
# 2 127.0.0.1:56420
# 442 192.168.1.213:8080
# 453 127.0.0.1:9000
分析:
经过确认, nginx 的配置文件中存在一行
# 不启用 keep-alive
keepalive_timeout 0;
尝试抓取 tcp 包
tcpdump tcp -i any -nn port 8080 | grep "我的ip"
# 其中某一次连接的输出如下
# 20:52:54.647907 IP 客户端.6470 > 服务端.8080: Flags [S], seq 2369523978, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
# 20:52:54.647912 IP 服务端.8080 > 客户端.6470: Flags [S.], seq 1109598671, ack 2369523979, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
# 20:52:54.670302 IP 客户端.6470 > 服务端.8080: Flags [.], ack 1, win 256, length 0
# 20:52:54.680784 IP 客户端.6470 > 服务端.8080: Flags [P.], seq 1:301, ack 1, win 256, length 300
# 20:52:54.680789 IP 服务端.8080 > 客户端.6470: Flags [.], ack 301, win 123, length 0
# 20:52:54.702935 IP 服务端.8080 > 客户端.6470: Flags [P.], seq 1:544, ack 301, win 123, length 543
# 20:52:54.702941 IP 服务端.8080 > 客户端.6470: Flags [F.], seq 544, ack 301, win 123, length 0
# 20:52:54.726494 IP 客户端.6470 > 服务端.8080: Flags [.], ack 545, win 254, length 0
# 20:52:54.726499 IP 客户端.6470 > 服务端.8080: Flags [F.], seq 301, ack 545, win 254, length 0
# 20:52:54.726501 IP 服务端.8080 > 客户端.6470: Flags [.], ack 302, win 123, length 0
上述具体的ip已经被我批量替换了, 不方便暴露服务器ip
分析:
修改 nginx 配置
keepalive_timeout 65;
reload nginx
nginx -s reload
再次抓包
tcpdump tcp -i any -nn port 8080 | grep "我的ip"
# 21:09:10.044918 IP 客户端.8217 > 服务端.8080: Flags [S], seq 1499308169, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
# 21:09:10.044927 IP 服务端.8080 > 客户端.8217: Flags [S.], seq 2960381462, ack 1499308170, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
# 21:09:10.070694 IP 客户端.8217 > 服务端.8080: Flags [.], ack 1, win 256, length 0
# 21:09:10.077437 IP 客户端.8217 > 服务端.8080: Flags [P.], seq 1:302, ack 1, win 256, length 301
# 21:09:10.077443 IP 服务端.8080 > 客户端.8217: Flags [.], ack 302, win 123, length 0
# 21:09:10.198117 IP 服务端.8080 > 客户端.8217: Flags [P.], seq 1:671, ack 302, win 123, length 670
# 21:09:10.222957 IP 客户端.8217 > 服务端.8080: Flags [F.], seq 302, ack 671, win 254, length 0
# 21:09:10.222980 IP 服务端.8080 > 客户端.8217: Flags [F.], seq 671, ack 303, win 123, length 0
# 21:09:10.247678 IP 客户端.8217 > 服务端.8080: Flags [.], ack 672, win 254, length 0
注意看上面很有意思的地方:
再次查看连接状态
netstat -an | grep TIME_WAIT | awk '{print $4}' | sort | uniq -c | sort -n -k1
# ...忽略上面
# 1 127.0.0.1:60602
# 1 127.0.0.1:60604
# 344 127.0.0.1:9000
此时发现已经没有处于 TIME_WAIT 的连接了.
经过网上查找资料, 整理:
当前 nginx 配置
upstream phpserver{
server 127.0.0.1:9000 weight=1;
}
修改nginx配置使其与fastcgi的连接使用长连接
upstream phpserver{
server 127.0.0.1:9000 weight=1;
keepalive 100
}
fastcgi_keep_conn on;
说明:
keepalive
指定nginx每个worker与fastcgi的最大长连接数, 当长连接不够用时, 此时新建立的连接会在请求结束后断开(由于此时指定了 HTTP1.1, fastcgi不会主动断开连接, 因此nginx这边会出现大量 TIME_WAIT, 需谨慎(未验证)keepalive
数量指定 100 (未测试)此处题外话, 如果 nginx 是作为反向代理, 则需增加如下配置:
# 将http版本由1.0修改为1.1
proxy_http_version 1.1;
# 清除"Connection"头部
proxy_set_header Connection "";
proxy_pass
将请求转发给后端这里, 理解一下 proxy_pass
与 fastcgi_pass
区别
客户端 --http--> 前端负载均衡Nginx --proxy_pass--> 业务服务器Nginx --fastcgi_pass--> 业务服务器 php-fpm
再次确认 tcp 连接情况
netstat -antp | grep :9000 | awk '{print $(NF-1)}' | sort | uniq -c
# 6 ESTABLISHED
# 1 LISTEN
ok, 问题解决.
另一种解决方法:
若 nginx 与 fast-cgi 在同一台服务器上, 则使用 unix域 会更为高效, 同时避免了 TIME_WAIT 的问题.
经过上面优化后, TIME_WAIT数量从上千个大幅下降到几十个, 此时发现TIME_WAIT中的存在大量的 127.0.0.1:6379, 6379是redis服务的默认端口....
赶紧改业务代码去, 将 $redis->connect(...)
改成 $redis->pconnect(...)
说明:
pconnect
表示 php-fpm 与 redis 建立 tcp 连接后, 在本次http请求结束后仍维持该连接, 下次新的请求进来时可以复用该连接, 从而复用了tcp连接.Last-Modified: 2019年7月10日21:58:43 项目生产环境出现大量TIME_WAIT(数千个), 需要一一排查 先上总结: nginx 未开启 keep-alive 导致大量主动断开的tcp连接 nginx 与 fastcgi(php-fpm) 的连接默认是短连接, 此时必然出现 TIME_WAIT 状态确认 统计TIME_WAIT 连接的...
魔王卷子 赞了文章 · 2020-07-21
Last-Modified: 2019年7月10日21:58:43
项目生产环境出现大量TIME_WAIT(数千个), 需要一一排查
先上总结:
统计TIME_WAIT 连接的本地地址
netstat -an | grep TIME_WAIT | awk '{print $4}' | sort | uniq -c | sort -n -k1
# ... 前面很少的略过
# 2 127.0.0.1:56420
# 442 192.168.1.213:8080
# 453 127.0.0.1:9000
分析:
经过确认, nginx 的配置文件中存在一行
# 不启用 keep-alive
keepalive_timeout 0;
尝试抓取 tcp 包
tcpdump tcp -i any -nn port 8080 | grep "我的ip"
# 其中某一次连接的输出如下
# 20:52:54.647907 IP 客户端.6470 > 服务端.8080: Flags [S], seq 2369523978, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
# 20:52:54.647912 IP 服务端.8080 > 客户端.6470: Flags [S.], seq 1109598671, ack 2369523979, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
# 20:52:54.670302 IP 客户端.6470 > 服务端.8080: Flags [.], ack 1, win 256, length 0
# 20:52:54.680784 IP 客户端.6470 > 服务端.8080: Flags [P.], seq 1:301, ack 1, win 256, length 300
# 20:52:54.680789 IP 服务端.8080 > 客户端.6470: Flags [.], ack 301, win 123, length 0
# 20:52:54.702935 IP 服务端.8080 > 客户端.6470: Flags [P.], seq 1:544, ack 301, win 123, length 543
# 20:52:54.702941 IP 服务端.8080 > 客户端.6470: Flags [F.], seq 544, ack 301, win 123, length 0
# 20:52:54.726494 IP 客户端.6470 > 服务端.8080: Flags [.], ack 545, win 254, length 0
# 20:52:54.726499 IP 客户端.6470 > 服务端.8080: Flags [F.], seq 301, ack 545, win 254, length 0
# 20:52:54.726501 IP 服务端.8080 > 客户端.6470: Flags [.], ack 302, win 123, length 0
上述具体的ip已经被我批量替换了, 不方便暴露服务器ip
分析:
修改 nginx 配置
keepalive_timeout 65;
reload nginx
nginx -s reload
再次抓包
tcpdump tcp -i any -nn port 8080 | grep "我的ip"
# 21:09:10.044918 IP 客户端.8217 > 服务端.8080: Flags [S], seq 1499308169, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
# 21:09:10.044927 IP 服务端.8080 > 客户端.8217: Flags [S.], seq 2960381462, ack 1499308170, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
# 21:09:10.070694 IP 客户端.8217 > 服务端.8080: Flags [.], ack 1, win 256, length 0
# 21:09:10.077437 IP 客户端.8217 > 服务端.8080: Flags [P.], seq 1:302, ack 1, win 256, length 301
# 21:09:10.077443 IP 服务端.8080 > 客户端.8217: Flags [.], ack 302, win 123, length 0
# 21:09:10.198117 IP 服务端.8080 > 客户端.8217: Flags [P.], seq 1:671, ack 302, win 123, length 670
# 21:09:10.222957 IP 客户端.8217 > 服务端.8080: Flags [F.], seq 302, ack 671, win 254, length 0
# 21:09:10.222980 IP 服务端.8080 > 客户端.8217: Flags [F.], seq 671, ack 303, win 123, length 0
# 21:09:10.247678 IP 客户端.8217 > 服务端.8080: Flags [.], ack 672, win 254, length 0
注意看上面很有意思的地方:
再次查看连接状态
netstat -an | grep TIME_WAIT | awk '{print $4}' | sort | uniq -c | sort -n -k1
# ...忽略上面
# 1 127.0.0.1:60602
# 1 127.0.0.1:60604
# 344 127.0.0.1:9000
此时发现已经没有处于 TIME_WAIT 的连接了.
经过网上查找资料, 整理:
当前 nginx 配置
upstream phpserver{
server 127.0.0.1:9000 weight=1;
}
修改nginx配置使其与fastcgi的连接使用长连接
upstream phpserver{
server 127.0.0.1:9000 weight=1;
keepalive 100
}
fastcgi_keep_conn on;
说明:
keepalive
指定nginx每个worker与fastcgi的最大长连接数, 当长连接不够用时, 此时新建立的连接会在请求结束后断开(由于此时指定了 HTTP1.1, fastcgi不会主动断开连接, 因此nginx这边会出现大量 TIME_WAIT, 需谨慎(未验证)keepalive
数量指定 100 (未测试)此处题外话, 如果 nginx 是作为反向代理, 则需增加如下配置:
# 将http版本由1.0修改为1.1
proxy_http_version 1.1;
# 清除"Connection"头部
proxy_set_header Connection "";
proxy_pass
将请求转发给后端这里, 理解一下 proxy_pass
与 fastcgi_pass
区别
客户端 --http--> 前端负载均衡Nginx --proxy_pass--> 业务服务器Nginx --fastcgi_pass--> 业务服务器 php-fpm
再次确认 tcp 连接情况
netstat -antp | grep :9000 | awk '{print $(NF-1)}' | sort | uniq -c
# 6 ESTABLISHED
# 1 LISTEN
ok, 问题解决.
另一种解决方法:
若 nginx 与 fast-cgi 在同一台服务器上, 则使用 unix域 会更为高效, 同时避免了 TIME_WAIT 的问题.
经过上面优化后, TIME_WAIT数量从上千个大幅下降到几十个, 此时发现TIME_WAIT中的存在大量的 127.0.0.1:6379, 6379是redis服务的默认端口....
赶紧改业务代码去, 将 $redis->connect(...)
改成 $redis->pconnect(...)
说明:
pconnect
表示 php-fpm 与 redis 建立 tcp 连接后, 在本次http请求结束后仍维持该连接, 下次新的请求进来时可以复用该连接, 从而复用了tcp连接.Last-Modified: 2019年7月10日21:58:43 项目生产环境出现大量TIME_WAIT(数千个), 需要一一排查 先上总结: nginx 未开启 keep-alive 导致大量主动断开的tcp连接 nginx 与 fastcgi(php-fpm) 的连接默认是短连接, 此时必然出现 TIME_WAIT 状态确认 统计TIME_WAIT 连接的...
赞 3 收藏 2 评论 3
查看全部 个人动态 →
使用illuminate组件实现了独立的Laravel迁移功能
注册于 2015-12-10
个人主页被 1.9k 人浏览
推荐关注