接口返回?cái)?shù)據(jù)是124b

現(xiàn)在你的服務(wù)器ab壓測(cè)第三方接口，看下能壓到多少，先不走webman

第三方接口只能從代碼程序端發(fā)起他們接口是這個(gè)protobuf協(xié)議，不能直接發(fā)起請(qǐng)求

第三方接口不是http協(xié)議？

1臺(tái)多高的服務(wù)器能抗住還是要負(fù)載均衡部署下

$url = '';
$client = new \GuzzleHttp\Client();
$response = $client->post($url, [
'body' => $serializedRequest,
'headers' => ['Content-Type' => 'application/x-protobuf']
]);
$serializedResponse = $response->getBody()->getContents();
現(xiàn)在是這樣寫(xiě)的

如果對(duì)方支持keep alive，那你的客戶(hù)端每次都不要new，做單例長(zhǎng)連接，避免每次都要建立連接

要怎么寫(xiě)一下

基于http的keep alive，你要先確認(rèn)對(duì)方是否支持keep alive；
然后guzzle帶上頭Connection keep alive；
然后創(chuàng)建的client對(duì)象用單例實(shí)現(xiàn)，具體可自行百度，大概就是靜態(tài)屬性?xún)?chǔ)存，判斷是否是null，如果是就new，如果不是就拿來(lái)直接用

支持的keep alive；

    $request = new HEC();
    $request->setRequestId($request_id);
    $request->setChannel('999');
    $request->setRequestTime($request_time);
    $device = new PLI();
    $device->setImei($imei); 在這個(gè)post之前還有這些new 是不是也要改成單列

只需要保證你創(chuàng)建的連接是復(fù)用就行了，我不清楚HEC PLI這些地方是否有涉及到連接的創(chuàng)建，但client那里是有涉及到網(wǎng)絡(luò)連接的

HEC PLI 這些實(shí)例化 就是剛剛設(shè)置那些字段設(shè)置參數(shù)值

那這些不必，只需要減少網(wǎng)絡(luò)連接的創(chuàng)建和銷(xiāo)毀即可，通常來(lái)說(shuō)網(wǎng)絡(luò)連接的創(chuàng)建和銷(xiāo)毀是最耗時(shí)的，其他的其實(shí)沒(méi)太大影響，復(fù)用tcp連接就行了

厲害了大佬 改成單例，配置沒(méi)變性能提高了40%呀

非常感謝

你的這些HEC PLI等對(duì)象數(shù)據(jù)內(nèi)容如果都是通過(guò)get set來(lái)進(jìn)行賦值而不是依賴(lài)默認(rèn)值的話(huà)，其實(shí)也可以做成單例，復(fù)用這些對(duì)象，畢竟對(duì)象是占用php的堆，依賴(lài)php自身的GC的，同樣可以提高性能。

這也就是為什么很多框架有DI容器，主要是為了復(fù)用所創(chuàng)建出來(lái)的對(duì)象，避免整體框架過(guò)多的創(chuàng)建和銷(xiāo)毀對(duì)象，從而給php的gc帶來(lái)比較大的清理壓力，這樣的思路同樣適用于java體系。

在底層需要了解那些是分配在堆上，哪些分配在棧上，語(yǔ)言的GC方案是如何的，從而就可以寫(xiě)出一些性能較高的業(yè)務(wù)

學(xué)習(xí)

請(qǐng)問(wèn)下還有什么方案可以限制的我對(duì)外接口的qps，比如我設(shè)置5000，超過(guò)的請(qǐng)求我全部丟棄，也不返回?cái)?shù)據(jù)，因?yàn)榉祷財(cái)?shù)據(jù)也會(huì)占用服務(wù)器帶寬

限制所有人不是單ip，所有請(qǐng)求1秒內(nèi)不能超過(guò)5000，超過(guò)就全部丟棄，也不返回?cái)?shù)據(jù)

令牌桶