next boost

ยาใหม่

next-boost เพิ่มเลเยอร์แคชลงในแอปพลิเคชัน SSR (การแสดงผลฝั่งเซิร์ฟเวอร์) ของคุณ มันถูกสร้างขึ้น แต่เดิมสำหรับ Next.js และควรทำงานกับแอปพลิเคชันที่ใช้ node.js http.Server

next-boost ประสบความสำเร็จในการแสดงที่ยอดเยี่ยมโดยการแสดงหน้าเว็บหน้าบน worker_threads ในขณะที่ให้บริการแคชบนเธรดหลัก

หากคุณคุ้นเคยกับ Next.js next-boost อาจถือเป็นการดำเนินการฟื้นฟูแบบคงที่ที่เพิ่มขึ้นซึ่งทำงานร่วมกับ getServerSideProps และมันไม่ได้หมายถึงการใช้กับ getStaticProps ซึ่งถัดไป js จะทำแคชให้คุณ

$ yarn add @next-boost/next-boost
$ yarn add @next-boost/redis-cache # using load-balancer and cluster
$ yarn add @next-boost/hybrid-disk-cache # simple site with disk cache 

คุณสมบัติ

• การแทนที่แบบดรอปอินสำหรับโหมดการผลิตของ next.js: next start
• การลดเซิร์ฟเวอร์ TTFB อย่างมาก (เวลาถึงครั้งแรก)
• กระบวนการหลักที่ไม่ปิดกั้นสำหรับการให้บริการแคชและการใช้ worker_threads สำหรับ SSR
• คำขอพร้อมกันกับการแสดงผลครั้งแรกและส่วนที่เหลือเสิร์ฟจากแคช
• รอยเท้าขนาดเล็กที่มีน้อยกว่า 200 loc
• ใช้ในการผลิตด้วย 300k หน้าแคช
• 2 อะแดปเตอร์แคชอย่างเป็นทางการ
  • @next-boost/redis-cache
    • สำหรับการใช้ภายในคลัสเตอร์
    • ตรวจสอบ .next-boost.redis.js สำหรับการกำหนดค่าตัวอย่าง
  • @next-boost/hybrid-disk-cache
    • ไม่มีขีดจำกัดความจุหน่วยความจำและใช้งานได้ดีใน VPS ราคาถูก
    • ประสิทธิภาพที่ยอดเยี่ยมและอาจมีประสิทธิภาพที่ดีกว่าแคชระบบไฟล์บริสุทธิ์
    • การพกพาบนแพลตฟอร์มหลัก
    • ตรวจสอบ .next-boost.hdc.js สำหรับการกำหนดค่าตัวอย่าง

ใช้ CLI next-boost กับ next.js

หลังจากติดตั้งแพ็คเกจเพียงแค่เปลี่ยนสคริปต์เริ่มต้นตั้งแต่ next start เป็น next-boost อาร์กิวเมนต์บรรทัดคำสั่งของ next start ทั้งหมดเช่น -p สำหรับการระบุพอร์ตนั้นเข้ากันได้

 "scripts": {
    ...
    "start": "next-boost", // previously `next start`
    ...
  },

ตัวอย่าง

มีตัวอย่างภายใต้ examples/nodejs ซึ่งทำงานกับ http.Server ธรรมดา

หากต้องการใช้กับ express.js และ next.js โปรดตรวจสอบ examples/with-express

ผลงาน

โดยการใช้ worker_threads การแสดงผล SSR ของ CPU หนักจะไม่ปิดกั้นกระบวนการหลักจากการให้บริการแคช

นี่คือการเปรียบเทียบการใช้ ApacheBench ในโพสต์บล็อกที่ดึงมาจากฐานข้อมูล HTML prerendered และการดำเนินการ dB ใช้เวลาประมาณ 10 ~ 20ms หน้าใช้เวลาประมาณ 200ms สำหรับ next.js ในการแสดงผล

$ /usr/local/bin/ab -n 200 -c 8 http://127.0.0.1:3000/blog/posts/2020/3/postname

ไม่ใช่เกณฑ์มาตรฐานทางวิทยาศาสตร์ แต่การปรับปรุงมีขนาดใหญ่อย่างเห็นได้ชัด

ด้วย next start (ข้อมูลที่ดึงมาด้วย getServerSideProps ):

 Document Length:        76424 bytes
Concurrency Level:      8
Time taken for tests:   41.855 seconds
Complete requests:      200
Failed requests:        0
Total transferred:      15325600 bytes
HTML transferred:       15284800 bytes
Requests per second:    4.78 [#/sec] (mean)
Time per request:       1674.185 [ms] (mean)
Time per request:       209.273 [ms] (mean, across all concurrent requests)
Transfer rate:          357.58 [Kbytes/sec] received

ด้วย Drop-in next-boost cli:

 Document Length:        78557 bytes
Concurrency Level:      8
Time taken for tests:   0.149 seconds
Complete requests:      200
Failed requests:        0
Total transferred:      15747600 bytes
HTML transferred:       15711400 bytes
Requests per second:    1340.48 [#/sec] (mean)
Time per request:       5.968 [ms] (mean)
Time per request:       0.746 [ms] (mean, across all concurrent requests)
Transfer rate:          103073.16 [Kbytes/sec] received

แม้จะมีประสิทธิภาพสูงกว่าหน้าสร้างหน้าคงที่ของ JS ( getStaticProps ) จัดการคำขอ 2 ~ 2.5x ต่อวินาทีในสภาพแวดล้อมของฉัน

มันทำงานอย่างไร

next-boost ใช้แคชฝั่งเซิร์ฟเวอร์ในลักษณะของการค้างในขณะที่ได้รับการตรวจสอบ เมื่อมีการเข้าถึงหน้าหมดอายุ ( stale ) แคชจะเสิร์ฟและในเวลาเดียวกันกระบวนการพื้นหลังจะดึงเวอร์ชันล่าสุด ( revalidate ) ของหน้านั้นและบันทึกลงในแคช

การกำหนดค่าต่อไปนี้จะแคชการจับคู่ uris ^/blog.* rules การจับคู่หน้าเว็บเท่านั้นจะได้รับการจัดการโดย next-boost และไม่มีกฎ exclude

 module . exports = {
  rules : [ { regex : '^/blog.*' , ttl : 300 } ] ,
}

มีพารามิเตอร์ 2 ตัวในการควบคุมพฤติกรรมของแคช:

• ttl (time-to-live) : หลังจากวินาที ttl แคชจะถูกประเมินใหม่ และ ttl ของหน้าแคชจะได้รับการอัปเดตเมื่อหน้ามีการตรวจสอบหน้าใหม่
• tbd (time-before-deletion) : เมื่อหน้าไม่ถูกตีอีกครั้งในวินาที ttl + tbd มันจะถูกลบออกจากแคชอย่างสมบูรณ์

ด้านบน: เฉพาะหน้าแคชที่มี URL เริ่มต้นด้วย /blog

ประเพณีขั้นสูง

การลบ/retralidating URL เดียว

ด้วยการส่ง Get With Header x-next-boost:update ไปยัง URL แคชจะถูกประเมินใหม่ และหากหน้าไม่มีอีกต่อไปแคชจะถูกลบ

$ curl -H x-next-boost:update https://the_server_name.com/path_a

การลบแบบแบทช์/refalidating

หากคุณต้องการลบหน้า mutiple ในครั้งเดียวคุณสามารถเรียกใช้ SQL บนแคชโดยตรง:

sqlite3 /cache_path/cache.db " update cache set ttl=0 where key like '%/url/a%'; "

สิ่งนี้จะบังคับให้ URL ทั้งหมดที่มี /url/a ได้รับการประเมินใหม่เมื่อเข้าถึงครั้งต่อไป

การลบ cache_path จะลบแคชทั้งหมด

การกรองพารามิเตอร์แบบสอบถาม

โดยค่าเริ่มต้นแต่ละหน้าที่มี URL ที่แตกต่างกันจะถูกแคชแยกกัน แต่ในบางกรณีคุณต้องการ /path_a?utm_source=twitter เพื่อเสิร์ฟด้วยเนื้อหาเดียวกันของ /path_a paramFilter สำหรับการกรองพารามิเตอร์แบบสอบถาม

 // in .next-boost.js
{
  ...
  paramFilter : ( p ) = > p !== 'utm_source'
}

การเปลี่ยนคีย์แคช

โดยค่าเริ่มต้น URL จะใช้เป็นคีย์สำหรับหน้าแคช หากคุณต้องการเซิร์ฟเวอร์หน้าจากโดเมนที่แตกต่างกันหรือโดยตัวแทนผู้ใช้ที่แตกต่างกันคุณสามารถใช้ฟังก์ชั่นนี้เพื่อกำหนดเองคีย์แคช

หมายเหตุ:

• หากมีข้อยกเว้นใด ๆ ที่ถูกโยนออกจากฟังก์ชั่นนี้หรือค่าที่ส่งคืนไม่ใช่ string เซิร์ฟเวอร์ของคุณจะพัง

 // in .next-boost.js
{
  ...
  cacheKey : ( req ) = > ( req . headers . host || '' ) + ':' + req . url
}

การใช้ Rules Resolver

หรือคุณสามารถจัดเตรียมฟังก์ชั่นแทนอาร์เรย์ภายในการกำหนดค่าของคุณ

 // in .next-boost.js
{
  ...
  rules : ( req ) = > {
      if ( req . url . startsWith ( '/blog' ) ) {
          return 300
      }
  }
}

ฟังก์ชั่นควรส่งคืน ttl ที่ถูกต้องสำหรับคำขอ หากฟังก์ชั่นส่งคืน 0 หรือค่า falsy คำขอจะไม่ถูกแคช

พลังที่มาจากวิธีนี้คือคุณสามารถตัดสินใจได้ว่าคำขอถูกแคชหรือไม่แบบไดนามิกมากขึ้น

ตัวอย่างเช่นคุณสามารถเพิกเฉยต่อคำขอทั้งหมดจากผู้ใช้ที่ได้รับการรับรองความถูกต้องตามส่วนหัว:

 // in .next-boost.js
{
  ...
  rules : ( req ) = > {
      if ( req . headers . authorization ) {
          return false
      }

      return 10 // cache all other requests for 10 seconds
  }
}

นอกจากนี้คุณยังสามารถรับกฎที่ซับซ้อนมากขึ้นได้ง่ายขึ้นผ่าน Regex ตัวอย่างเช่นคุณต้องการ TTL ที่แตกต่างกันสำหรับหน้าการแบ่งหน้าแต่ละหน้า

 // in .next-boost.js
{
  ...
  rules : ( req ) = > {
    const [ , p1 ] = url . split ( '?' , 2 )
    const params = new URLSearchParams ( p1 )

    return {
        1 : 5000 ,
        2 : 4000 ,
        3 : 3000 ,
        4 : 2000
    } [ params . get ( 'page' ) ] || 1000
  }
}

ในขณะที่คุณจะต้องเขียนกฎ Regex ที่ซับซ้อนหรืออาจมีกฎมากกว่านั้นเป็นเรื่องง่ายที่จะทำผ่าน JS Logic

ในท้ายที่สุดถ้าคุณชอบเขียน regex แต่ต้องการใช้ประโยชน์จากตรรกะ JS คุณสามารถใช้การจับคู่ภายในตัวจัดการกฎได้ตลอดเวลา

ตัวเลือกที่กำหนดค่าได้ทั้งหมด

หากพร้อมใช้งาน .next-boost.js ที่รูทโครงการจะถูกใช้ หากคุณใช้ Next-Boost โดยทางโปรแกรมชื่อไฟล์สามารถเปลี่ยนแปลงได้ในตัวเลือกที่คุณส่งไปยัง CachedHandler

เคล็ดลับ: หากคุณใช้ CLI next-boost กับ next.js คุณอาจต้องการใช้ไฟล์ config

และนี่คือตัวอย่าง .next-boost.sample.js ใน repo

 interface HandlerConfig {
  filename ?: string
  quiet ?: boolean
  cache ?: {
    ttl ?: number
    tbd ?: number
    path ?: string
  }
  rules ?: Array < URLCacheRule > | URLCacheRuleResolver
  paramFilter ?: ParamFilter
  cacheKey ?: CacheKeyBuilder
}

interface URLCacheRule {
  regex : string
  ttl : number
}

type URLCacheRuleResolver = ( req : IncomingMessage ) => number

type ParamFilter = ( param : string ) => boolean
type CacheKeyBuilder = ( req : IncomingMessage ) => string

การตัดไม้

การบันทึกถูกเปิดใช้งานโดยค่าเริ่มต้น หากคุณใช้ next-boost โดยทางโปรแกรมคุณสามารถปิดการใช้งานบันทึกโดยผ่านธงบูลีนที่ quiet เป็นตัวเลือกสำหรับ CachedHandler

...
const cached = await CachedHandler ( args , { quiet : true } ) ;
...

นอกจากนี้ยังมีธง --quiet หากคุณใช้บรรทัดคำสั่ง

ข้อ จำกัด

• สำหรับสถาปัตยกรรมที่มีเซิร์ฟเวอร์การเรนเดอร์ที่มีความสมดุลหลายครั้งประโยชน์ของการใช้งาน next-boost นั้นมี จำกัด จนกว่า URL จะถูกโจมตีบนเซิร์ฟเวอร์แบ็กเอนด์ทุกเครื่องมันก็ยังสามารถพลาดแคชได้ ใช้พร็อกซีย้อนกลับด้วยการสนับสนุนแคช (Nginx, Varnish ฯลฯ ) สำหรับสิ่งนั้น
• GET และคำขอ HEAD เท่านั้น
• worker_threads ใช้และเป็นคุณสมบัติ Node.js 12+

คำถามที่พบบ่อย

สังเกตเกี่ยวกับเซิร์ฟเวอร์ที่กำหนดเองของ next.js

next-boost ทำงานเป็นการแทนที่ในสถานที่สำหรับ next start โดยใช้คุณสมบัติเซิร์ฟเวอร์ที่กำหนดเองของ next.js

ในหน้าลิงก์ด้านบนคุณสามารถดูประกาศต่อไปนี้:

ก่อนที่จะตัดสินใจใช้เซิร์ฟเวอร์ที่กำหนดเองโปรดทราบว่าควรใช้เมื่อเราเตอร์ในตัวของ Next.js ไม่สามารถปฏิบัติตามข้อกำหนดของแอพของคุณได้ เซิร์ฟเวอร์ที่กำหนดเองจะลบการเพิ่มประสิทธิภาพประสิทธิภาพที่สำคัญเช่นฟังก์ชั่นที่ไม่มีเซิร์ฟเวอร์และการเพิ่มประสิทธิภาพแบบคงที่อัตโนมัติ

Next-boost มีไว้เพื่อใช้ใน Cloud VPS หรือคอนเทนเนอร์ดังนั้นฟังก์ชั่น Serverless จึงไม่เป็นปัญหาที่นี่ สำหรับ Automatic Static Optimization เพราะเราไม่ได้ทำ app.render ใด ๆ ที่นี่มันยังคงใช้งานได้ดีเช่นเคย

ทำไม sqlite

นี่คือบทความเกี่ยวกับเวลาที่จะไม่ใช้ sqlite และสำหรับวัตถุประสงค์หลักของ Next-Boost: SSR ที่เร็วกว่ามากสำหรับ VPSS ราคาต่ำเท่าที่ฉันรู้มันเป็นตัวเลือกที่ดีที่สุด

ใบอนุญาต

MIT ลิขสิทธิ์ 2020 Rakuraku Jyo