litestack 0.1.1 → 0.1.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 025c78f9b04863bfce9f09dae2181b735187d0ff8852ff0a474ce59fc4f3b7fc
-  data.tar.gz: f4d950cbfef0e9b0e6642196b2efa0953dd8d988de54168ff9934bb257d6c729
+  metadata.gz: 52b25ab2fd70ef40c8199c431e07638853915a131036abb52d1fef267a70cb13
+  data.tar.gz: 8f2bcf6c6fbc6d50e18664f74235b4242c79faa65317b1dcd7263ed0aa928161
 SHA512:
-  metadata.gz: 29bb82387bac7b66cf2e335fc072ff79613de006ead064cbbf01746b1c57687b47c5bf875af7e173273ca8ba961dfc561595dfb9fd1527f92989444e294be4ea
-  data.tar.gz: ae523a47ebeed583670541bec755c39559e6a24230aaf7fa074e262a7410e64dd6e5c4f82af9b9d40dc8ef39748bac6bc38656a00a2a0066957a10af02573a9e
+  metadata.gz: 1fa0edf72ea893a29f71f7398f685954243dd2cbd61080624ff91f49f389bf067c76cac491520f91c7f2470f568444d37eff0b72787d5f8418d6abbc869fd7c8
+  data.tar.gz: 75be276d72526cc1f68e204929822c8ba846b1d476d2d429de5c5e2e298df748b62de9d5c804912384ddec515505e6a42e0d9e09e4f27a3d27ff942f423a904c

data/BENCHMARKS.md

@@ -0,0 +1,104 @@
+# Litestack Benchmarks
+
+This is a set of initial (simple) benchmars, designed to understand the baseline performance for different litestack components against their counterparts. 
+These are not real life scenarios and I hope I will be able to produce some interesting ones soon.
+
+> ![litedb](https://github.com/oldmoe/litestack/blob/master/assets/litedb_logo_teal.png?raw=true)
+
+### Point Read
+
+```ruby
+Post.find(id) #ActiveRecord
+Post[id] #Sequel
+```
+This maps to "SELECT * FROM posts WHERE id = ?"
+
+|Prcoess Count|ActiveRecord:PostgreSQL|ActiveRecord:litedb|Sequel:PostgreSQL|Sequel:litedb|
+|-:|-:|-:|-:|-:|
+|1|1.3K q/s|6.5K q/s|1.8K q/s|17.4K q/s|
+|2|2.6K q/s|13.9K q/s|3.5K q/s|33.2K q/s|
+|4|4.9K q/s|24.5K q/s|5.9K q/s|58.7K q/s|
+|8|6.9K q/s|31.8K q/s|9.3K q/s|86.6K q/s|
+
+### Multi Reads
+
+```ruby
+Post.where(user_id: id).limit(5) # ActiveRecord and Sequel
+```
+This maps to "SELECT * FROM posts WHERE user_id = ? LIMIT 5"
+
+|Prcoess Count|ActiveRecord:PostgreSQL|ActiveRecord:litedb|Sequel:PostgreSQL|Sequel:litedb|
+|-:|-:|-:|-:|-:|
+|1|345 q/s|482 q/s|937 q/s|1.1K q/s|
+|2|751 q/s|848 q/s|1.3K q/s|2.3K q/s|
+|4|1.4K q/s|1.6K q/s|3.4K q/s|4.0K q/s|
+|8|2.6K q/s|2.8K q/s|5.1K q/s|6.6K q/s|
+
+### Point Update
+
+```ruby
+Post.update(id, {updated_at: updated_at} # ActiveRecord
+Post[id].update({updated_at: updated_at}) # Sequel
+```
+This maps to "Update posts SET updated_at = ? WHERE id = ?"
+
+|Prcoess Count|ActiveRecord:PostgreSQL|ActiveRecord:litedb|Sequel:PostgreSQL|Sequel:litedb|
+|-:|-:|-:|-:|-:|
+|1|125 q/s|484 q/s|129 q/s|2.1K q/s|
+|2|265 q/s|576 q/s|333 q/s|2.5K q/s|
+|4|481 q/s|693 q/s|704 q/s|2.3K q/s|
+|8|898 q/s|748 q/s|1.2K q/s|2.4K q/s|
+
+It is clear the Litedb enjoys a clear advantage for reads and is very competitive for updates until many processes are relentlessly trying to write at the same time non stop.
+For most applications, even with higher level of concurrency, Litedb will scale super well for reads and provide a very good baseline for writes.
+
+> ![litecache](https://github.com/oldmoe/litestack/blob/master/assets/litecache_logo_teal.png?raw=true)
+
+For testing the cache we attempted to try writing and reading different payload sizes with a fixed key size
+
+### Write
+
+|Payload Size (bytes)|Redis|litecahce|
+|-:|-:|-:|
+|10|4.2K q/s|11.0K q/s|
+|100|4.7K q/s|11.6K q/s|
+|1000|4.0K q/s|7.0K q/s|
+|10000|3.4K q/s|2.4K q/s|
+
+### Read
+
+|Payload Size (bytes)|Redis|litecahce|
+|-:|-:|-:|
+|10|5.0K q/s|69.4K q/s|
+|100|5.0K q/s|90.7K q/s|
+|1000|4.5K q/s|70.9K q/s|
+|10000|3.7K q/s|26.9K q/s|
+
+### Increment an int value
+
+|Redis|litecahce|
+|-:|-:|
+|5.1K q/s|16.9K q/s|
+
+It is not even a contest! litecache delivers way higher peroformance, specially in reading performance which is arguably the most important metric for a cache.
+
+> ![litejob](https://github.com/oldmoe/litestack/blob/master/assets/litejob_logo_teal.png?raw=true)
+
+Two scenarios were benchmarked, an empty job and one with a 100ms sleep to simulate moderate to heavy network IO. Sidekiq was tested against litejob
+
+### No-op Job
+
+|Sidekiq|Litejob:threads|litejob:fibers|
+|-:|-:|-:|
+|1.4K j/s|1.6K j/s|4.9K j/s|
+
+### IO Simulated Job
+
+|Sidekiq: 5 threads|Sidekiq: 25 threads|Litejob:threads|litejob:fibers|
+|-:|-:|-:|-:|
+|48 j/s|239 j/s|457 j/s|3.2K j/s|
+
+Running Litejob with fibers is producing much faster results than any threaded solution. Still though, threaded Litejob remains ahead of Sidekiq in all scenarios. 
+
+
+

data/README.md

@@ -5,6 +5,9 @@ litestack is a revolutionary gem for Ruby and Ruby on Rails that provides an all
 
 Compared to conventional approaches that require separate servers and databases, LiteStack offers superior performance, efficiency, ease of use, and cost savings. Its embedded database and cache reduce memory and CPU usage, while its simple interface streamlines the development process. Overall, LiteStack sets a new standard for web application development and is an excellent choice for those who demand speed, efficiency, and simplicity.
 
+You can read more about why litestack can be a good choice for your next web application **[here](WHYLITESTACK.md)**, you might also be interested in litestack **[benchmarks](BENCHMARKS.md)**.
+
+
 litestack provides integration with popular libraries, including:
 
 - Rack
@@ -16,9 +19,9 @@ litestack provides integration with popular libraries, including:
 
 With litestack you only need to add a single gem to your app which would replace a host of other gems and services, for example, a typical Rails app using litestack will no longer need the following services:
 
-- PostgreSQL
-- Redis
-- Sidekiq
+- Database Server (e.g. PostgreSQL, MySQL)
+- Cache Server (e.g. Redis, Memcached)
+- Job Processor (e.g. Sidekiq, Goodjob)
 
 To make it even more efficient, litestack will detect the presence of Fiber based IO frameworks like Async (e.g. when you use the Falcon web server) or Polyphony. It will then switch its background workers for caches and queues to fibers (using the semantics of the existing framework). This is done transparently and will generally lead to lower CPU and memory utilization.
 

data/WHYLITESTACK.md

@@ -16,6 +16,8 @@ This ease of setup and configuration is due to Litestack's design philosophy, wh
 
 This simplicity is a significant advantage for developers, as it allows them to focus on writing code and delivering features rather than dealing with the complexities of database and infrastructure management. By simplifying the setup process, Litestack can help reduce the time and cost required to get your application up and running, enabling you to focus on delivering value to your users.
 
+That's not to say we hate on complex solutions, actually, we believe complexity has its place, elsewhere!.
+
 ## Simple can be cutting edge
 Another benefit of Litestack is its deep integration with state of the art Ruby IO libraries like Async and Polyphony. This allows for even greater performance improvements and improved efficiency, as these libraries can help manage concurrency and parallelism in your web application.
 

data/bench/bench_jobs_raw.rb

@@ -1,15 +1,17 @@
 #require 'polyphony'
 require 'async/scheduler'
 require './bench'
-require './skjob.rb'
-require './uljob.rb'
 
 Fiber.set_scheduler Async::Scheduler.new
 
-count = 1000
+count = 10000
+require './skjob.rb'
+require './uljob.rb'
+
+puts Litesupport.environment
 
 t = Time.now.to_f
-# make sure sidekiq is started with skjob.rb as the job-     
+puts "make sure sidekiq is started with skjob.rb as the job"     
 bench("enqueuing sidekiq jobs", count) do |i|
   SidekiqJob.perform_async(count, t)
 end

data/bench/skjob.rb

@@ -4,7 +4,7 @@ class SidekiqJob
   include Sidekiq::Job
   @@count = 0
   def perform(count, time)
-    sleep 0.01  
+    sleep 0.1  
     @@count += 1
     if @@count == count  
       puts "finished in #{Time.now.to_f - time} seconds (#{count / (Time.now.to_f - time)} jps)"

data/bench/uljob.rb

@@ -6,7 +6,7 @@ class MyJob
   @@count = 0
 #  self.queue = :normal
   def perform(count, time)
-    sleep 1
+    #sleep 0.1
     @@count += 1
     if @@count == count  
       puts "UL finished in #{Time.now.to_f - time} seconds (#{count / (Time.now.to_f - time)} jps)"

data/lib/litestack/litejobqueue.rb

@@ -32,7 +32,7 @@ class Litejobqueue
   DEFAULT_OPTIONS = {
     config_path: "./litejob.yml",
     path: "./queue.db",
-    queues: [["default", 1, "spawn"]],
+    queues: [["default", 5]],
     workers: 1,
     sleep_intervals: [0.001, 0.005, 0.025, 0.125, 0.625, 3.125]
   }

data/lib/litestack/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Litestack
-  VERSION = "0.1.1"
+  VERSION = "0.1.2"
 end       

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: litestack
 version: !ruby/object:Gem::Version
-  version: 0.1.1
+  version: 0.1.2
 platform: ruby
 authors:
 - Mohamed Hassan
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2023-02-25 00:00:00.000000000 Z
+date: 2023-02-26 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: sqlite3
@@ -45,6 +45,7 @@ executables: []
 extensions: []
 extra_rdoc_files: []
 files:
+- BENCHMARKS.md
 - CHANGELOG.md
 - Gemfile
 - LICENSE.txt
@@ -64,6 +65,9 @@ files:
 - bench/bench_queue.rb
 - bench/bench_rails.rb
 - bench/bench_raw.rb
+- bench/queue.db
+- bench/queue.db-shm
+- bench/queue.db-wal
 - bench/rails_job.rb
 - bench/skjob.rb
 - bench/uljob.rb