From 8792ea068f0d79897682516ae74713176af8e33b Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Thu, 18 Sep 2025 11:13:06 -0500 Subject: [PATCH 1/7] supporting blog content local-rag-with-lightweight-elasticsearch --- .../Dataset/meeting_QA-team_wednesday.txt | 3 + .../meeting_development-team_monday.txt | 3 + .../meeting_management-sync_friday.txt | 4 + .../Dataset/report_QA-team.txt | 0 .../Dataset/report_development-team.txt | 1 + .../script.py | 100 ++++++++++++++++++ 6 files changed, 111 insertions(+) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt new file mode 100644 index 00000000..1550401d --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt @@ -0,0 +1,3 @@ +• Maria: “Data imports are failing when addresses contain special characters.” +• Tom: “That matches what we saw last week. We need a parser fix.” +• Maria: “Agreed, let’s log this as a blocker.” \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt new file mode 100644 index 00000000..86aa66d0 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt @@ -0,0 +1,3 @@ +• Alice: “The API is working, but response times are too slow with more than 1,000 queries.” +• John: “We may need to add caching or optimize indexes.” +• Alice: “Let’s prioritize this for the next sprint.” \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt new file mode 100644 index 00000000..810e76af --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt @@ -0,0 +1,4 @@ +• Manager: “Are we on track for the migration deadline next month?” +• Alice: “Development is slightly behind due to performance issues.” +• Maria: “QA also found blockers with data imports.” +• Manager: “Okay, let’s adjust the timeline by two weeks to ensure quality.” \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt new file mode 100644 index 00000000..e69de29b diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt new file mode 100644 index 00000000..5670f6d6 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt @@ -0,0 +1 @@ +The migration to the new CRM is progressing. We finished setting up the database schema and implemented the first batch of API integrations. The main issue is performance under heavy load, especially with customer search. We estimate two more sprints to stabilize. \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py new file mode 100644 index 00000000..044ec4eb --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -0,0 +1,100 @@ +import os +import time + +import requests +from elasticsearch import Elasticsearch + +ES_URL = "http://localhost:9200" +ES_API_KEY = "your-api-key-here" +INDEX_NAME = "team-data" +OLLAMA_URL = "http://localhost:11434/api/generate" +DATASET_FOLDER = "./Dataset" + + +es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) + + +def index_documents(): + docs_count = 0 + for filename in os.listdir(DATASET_FOLDER): + if filename.endswith(".txt"): + filepath = os.path.join(DATASET_FOLDER, filename) + + with open(filepath, "r", encoding="utf-8") as file: + content = file.read() + + doc = { + "file_title": filename, + "file_content": content, + "semantic_field": f"{filename} {content}", + } + + start_time = time.time() + es_client.index(index=INDEX_NAME, document=doc) + index_latency = (time.time() - start_time) * 1000 # ms + + docs_count += 1 + print(f"✓ {filename} | Latency: {index_latency:.0f}ms") + + return docs_count + + +def semantic_search(query, size=3): + start_time = time.time() + search_body = { + "query": {"semantic": {"field": "semantic_field", "query": query}}, + "size": size, + } + + response = es_client.search(index=INDEX_NAME, body=search_body) + + search_latency = (time.time() - start_time) * 1000 # ms + print( + f"🔍 Search completed in {search_latency:.0f}ms" + ) # Print for monitoring purposes + + return response["hits"]["hits"], search_latency + + +def query_ollama(prompt, model="qwen3:4b"): + start_time = time.time() + data = {"model": model, "prompt": prompt, "stream": False} + + response = requests.post(OLLAMA_URL, json=data) + + ollama_latency = (time.time() - start_time) * 1000 # ms + + if response.status_code == 200: + print( + f"🤖 Ollama answered in {ollama_latency:.0f}ms" + ) # Print for monitoring purposes + return response.json()["response"], ollama_latency + else: + return f"Error: {response.status_code}", ollama_latency + + +if __name__ == "__main__": + print("📥 Indexing documents...") + docs_count = index_documents() + + query = "performance issues in the API" + + print(f"\n🔍 Search: '{query}'") + search_results, search_latency = semantic_search(query) + + context = "Information found:\n" + for hit in search_results: + source = hit["_source"] + context += f"File: {source['file_title']}\n" + context += f"Content: {source['file_content']}\n\n" + + prompt = f"{context}\nQuestion: {query}\nAnswer:" + + print("🤖 Asking to model...") + response, ollama_latency = query_ollama(prompt) + + print(f"\n💡 Question: {query}\n📝 Answer: {response}") + + print(f"\n🔍 Search Latency: {search_latency:.0f}ms") + print(f"🤖 Ollama Latency: {ollama_latency:.0f}ms") + print(f"📄 Documents Indexed: {docs_count}") From 3b152381a75d68c24a481cf043d1944e387dcada Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Thu, 18 Sep 2025 11:20:48 -0500 Subject: [PATCH 2/7] app logs --- .../app-logs/results.md | 82 +++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md new file mode 100644 index 00000000..fdcad0dc --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md @@ -0,0 +1,82 @@ +## 📥 Indexing documents... + +✓ meeting_management-sync_friday.txt | Latency: 64ms + +✓ report_development-team.txt | Latency: 17ms + +✓ meeting_development-team_monday.txt | Latency: 10ms + +✓ report_QA-team.txt | Latency: 9ms + +✓ meeting_QA-team_wednesday.txt | Latency: 9ms + +🔍 Search: 'performance issues in the API' + +🔍 Búsqueda completada en 5ms + +🤖 Asking to model... + +🤖 Ollama answered in 29432ms + +## 💡 Question: performance issues in the API + +### 📝 Answer: + + +Okay, the user is asking about performance issues in an API. Let me start by understanding what they need. They might be a developer or a tech lead dealing with slow API responses. First, I should figure out the common causes of API performance problems. + +Hmm, the user didn't provide specific details about their API. So I need to cover the main areas without assuming too much. Let me list out the typical issues: database queries, network latency, code inefficiencies, caching, rate limiting, external dependencies, etc. + +Wait, the user mentioned "performance issues in the API" but didn't specify if it's their own API or a third-party one. I should clarify that. But since the answer section is empty, maybe they want a general guide. + +I recall that common causes include slow database queries, especially if they're not optimized. Maybe they have N+1 queries? Or improper indexing. Also, heavy processing in the backend could be a problem. Like, if the API is doing a lot of computations per request. + +Network issues might be another angle. If the API is hosted on a different server, latency could be high. Or maybe the user is facing timeouts. + +Caching is important too. If the API isn't caching responses, every request goes to the backend. But if they have caching in place and it's not working right, that could cause slowness. + +External dependencies—like calling another API that's slow. That's a common pitfall. Also, rate limiting might be causing delays if the API is hit too hard. + +Wait, the user might need actionable steps. So I should structure the answer into sections: common causes, diagnostic steps, solutions. But the answer is supposed to be short since it's a fill-in. The user's instruction says "Answer:" so they want a concise answer. + +Looking back at the information provided, there's no specific data. So the answer should be a general response. Maybe the user expects a list of possible causes? Like in the answer field. + +Wait, the problem says "Information found:" followed by the question and answer. But the answer is empty. So the task is to generate the answer based on typical knowledge. + +I think the best approach is to list the main causes without being too technical. Let me check standard API performance issues. + +Top causes: +1. Slow database queries (e.g., missing indexes, complex joins) +2. Inefficient code (e.g., unnecessary loops, heavy computations) +3. Lack of caching +4. High network latency +5. External service dependencies +6. Rate limiting or too many requests +7. Inadequate server resources (CPU, memory) + +Also, maybe the API is not using asynchronous processing for long tasks. Or the response size is too big, causing slow transfers. + +The user might be looking for a quick reference. So I'll structure the answer as a bullet list of key points. But since it's an answer field, maybe a concise paragraph. + +Wait, the user's instruction says "Answer:" so I need to fill that part. Let me draft a response. + +"Common causes include slow database queries, inefficient code logic, lack of caching, high network latency, external dependencies, and insufficient server resources. Diagnose using tools like API monitoring, profiling, and logs." + +But maybe they want more specific. Alternatively, if this is for a specific scenario, but the user didn't specify. Hmm. + +Another angle: sometimes performance issues are due to the API design itself, like REST vs. GraphQL, but that's probably too specific. + +I think the safest answer is to list the main points briefly. Let me check similar problems online. For example, common API performance issues are often related to database, code, caching. + +Okay, I'll go with that. + + +## Final Answer: + +Common causes include slow database queries (e.g., missing indexes, N+1 queries), inefficient code logic (e.g., excessive computations, redundant operations), lack of caching, high network latency, external dependency delays, rate limiting, and insufficient server resources (CPU/memory). Diagnose using profiling tools, API monitoring, and log analysis to identify bottlenecks. + +## App performance metrics: + +🔍 Search Latency: 5ms +🤖 Ollama Latency: 29432ms +📄 Documents Indexed: 5 \ No newline at end of file From 40d7e6a7335694f84568f9d84c1656a674d10434 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Thu, 18 Sep 2025 11:24:46 -0500 Subject: [PATCH 3/7] app-logs --- .../app-logs/why-elasticsearch-is-so-cool.md | 62 +++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md new file mode 100644 index 00000000..d1582b29 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/why-elasticsearch-is-so-cool.md @@ -0,0 +1,62 @@ +>>> Why Elastic is so cool? + +That's a **great question**, but there's a **critical clarification first**: **"Elastic" alone isn't a product** — it's almost always a shorthand for **Elasticsearch** (the core search +engine) and the **Elastic Stack** (Elasticsearch + Kibana + Logstash + Beats). + +**Why people say "Elastic is so cool" (and why it's actually *Elasticsearch* that's the star):** + +1. **Real-Time Search & Analytics (The "Cool" Part!)** + Elasticsearch doesn't just *search* — it **indexes, searches, and analyzes data in real time** (millions of events/sec). Unlike traditional databases (which need slow queries or +batch processing), it gives you instant answers. + *Example:* Netflix uses it to show personalized movie recommendations *as you browse* — not after you click "Next" or "Save." + +2. **Handles "Wild" Data (Unstructured + Structured)** + Most data today is messy (text, logs, images, JSON, CSV). Elasticsearch **natively understands** this. + *Example:* A company can search *both* "user feedback in Slack messages" *and* "product prices from a spreadsheet" in one query. + +3. **Scalability That Doesn’t Break** + It’s built to scale **horizontally** (add more servers) without downtime. Handles **petabytes** of data. + *Example:* Airbnb uses it to power their 10M+ listing search across 200+ countries — *without* slowing down. + +4. **The Elastic Stack = Full Power** + Elasticsearch isn’t alone — it’s part of a **complete suite**: + - **Logstash**: Ingests data from anywhere (websites, apps, logs). + - **Kibana**: Visualize data (dashboards, maps, charts). + - **Beats**: Lightweight data shippers (for apps). + *This lets you build end-to-end data pipelines:* **Collect → Process → Search → Visualize** in one flow. + +5. **No More "Slow Queries" (The Real Pain Point)** + Traditional SQL databases struggle with: + - Full-text search (e.g., "show me products with 'sneakers' AND 'black'") + - Real-time analytics (e.g., "how many users clicked 'checkout' in the last 5 mins?") + Elasticsearch solves both **with one query**. + +6. **Open Source (with Enterprise Support)** + Free to use — but Elastic also offers enterprise features (security, ML, etc.) for large teams. *This is why it’s so widely adopted.* + +### Why It’s "So Cool" in Practice: +| **Problem** | **Traditional Tool** | **Elasticsearch** | +|----------------------------|----------------------------|---------------------------------------| +| Real-time product search | Slow (seconds) | Instant (milliseconds) | +| Analyze user behavior | Requires complex SQL | Simple queries + real-time dashboards| +| Handle messy logs | Needs ETL pipelines | Ingests logs *directly* | +| Scale to 10M+ users | Databases become slow | Scales horizontally effortlessly | + +### Real-World Examples: +- **Netflix**: Uses Elasticsearch for 1B+ users to personalize content. +- **GitHub**: Uses it to search code repositories (text + code structure). +- **Healthcare**: Analyzes patient data for real-time alerts (e.g., "risk of sepsis"). +- **Security**: Real-time threat detection (e.g., "suspicious login from Brazil"). + +### Why People Get Confused: +- **"Elastic" = Elasticsearch** (the product) → Not a standalone tool. +- **"The Elastic Stack"** = The full suite (Elasticsearch + Kibana + Logstash + Beats). +- **Not "Elastic" as in rubber bands** (that’s physics, not tech!). + +### The Bottom Line: +**Elasticsearch is "so cool" because it turns messy, real-time data into instant insights — without slowing down.** It’s the reason companies can build **search, analytics, and +monitoring** at scale *without* writing complex code or waiting for results. + +If you meant **"Elastic"** as in the rubber band (physics), that’s **not cool** 😄 — but in tech? **100% cool**. 😎 + +*So next time someone says "Elastic is so cool," you know exactly what they mean!* 🔥 From 89f9988209036ba7298829257848ddf0ada111d7 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Thu, 18 Sep 2025 20:53:07 -0500 Subject: [PATCH 4/7] script changes and docker image --- .../app-logs/results.md | 28 +++------ .../docker-compose.yml | 20 +++++++ .../script.py | 57 ++++++++++--------- 3 files changed, 58 insertions(+), 47 deletions(-) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md index fdcad0dc..853101ac 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md @@ -1,24 +1,9 @@ -## 📥 Indexing documents... - -✓ meeting_management-sync_friday.txt | Latency: 64ms - -✓ report_development-team.txt | Latency: 17ms - -✓ meeting_development-team_monday.txt | Latency: 10ms - -✓ report_QA-team.txt | Latency: 9ms - -✓ meeting_QA-team_wednesday.txt | Latency: 9ms - -🔍 Search: 'performance issues in the API' - -🔍 Búsqueda completada en 5ms +📥 Indexing documents... +🔍 Search: 'Can you summarize the performance issues in the API?' 🤖 Asking to model... -🤖 Ollama answered in 29432ms - -## 💡 Question: performance issues in the API +## 💡 Question: Can you summarize the performance issues in the API? ### 📝 Answer: @@ -77,6 +62,7 @@ Common causes include slow database queries (e.g., missing indexes, N+1 queries) ## App performance metrics: -🔍 Search Latency: 5ms -🤖 Ollama Latency: 29432ms -📄 Documents Indexed: 5 \ No newline at end of file +📄 Documents Indexed: 5 | Bulk Latency: 37ms + +🔍 Search Latency: 32ms +🤖 Ollama Latency: 29411ms | 29.5 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml new file mode 100644 index 00000000..c6e2d188 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml @@ -0,0 +1,20 @@ +services: + ollama: + image: ollama/ollama:latest + container_name: ollama + ports: + - "11434:11434" + volumes: + - ollama_data:/root/.ollama + entrypoint: > + sh -c " + /bin/ollama serve & + sleep 5 && + /bin/ollama run qwen3:4b && + wait + " + restart: unless-stopped + +volumes: + ollama_data: + driver: local \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index 044ec4eb..c4216d25 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -10,12 +10,12 @@ OLLAMA_URL = "http://localhost:11434/api/generate" DATASET_FOLDER = "./Dataset" - es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) def index_documents(): - docs_count = 0 + docs = [] + for filename in os.listdir(DATASET_FOLDER): if filename.endswith(".txt"): filepath = os.path.join(DATASET_FOLDER, filename) @@ -23,20 +23,18 @@ def index_documents(): with open(filepath, "r", encoding="utf-8") as file: content = file.read() - doc = { - "file_title": filename, - "file_content": content, - "semantic_field": f"{filename} {content}", - } + docs.append({"index": {"_index": INDEX_NAME}}) + docs.append({"file_title": filename, "file_content": content}) - start_time = time.time() - es_client.index(index=INDEX_NAME, document=doc) - index_latency = (time.time() - start_time) * 1000 # ms + indexed_docs_count = 0 - docs_count += 1 - print(f"✓ {filename} | Latency: {index_latency:.0f}ms") + if docs: + start_time = time.time() + response = es_client.bulk(body=docs) + bulk_latency = (time.time() - start_time) * 1000 # ms + indexed_docs_count = len(response["items"]) - return docs_count + return indexed_docs_count, bulk_latency def semantic_search(query, size=3): @@ -49,9 +47,6 @@ def semantic_search(query, size=3): response = es_client.search(index=INDEX_NAME, body=search_body) search_latency = (time.time() - start_time) * 1000 # ms - print( - f"🔍 Search completed in {search_latency:.0f}ms" - ) # Print for monitoring purposes return response["hits"]["hits"], search_latency @@ -65,19 +60,27 @@ def query_ollama(prompt, model="qwen3:4b"): ollama_latency = (time.time() - start_time) * 1000 # ms if response.status_code == 200: - print( - f"🤖 Ollama answered in {ollama_latency:.0f}ms" - ) # Print for monitoring purposes - return response.json()["response"], ollama_latency + response_data = response.json() + + eval_count = response_data.get("eval_count", 0) + eval_duration = response_data.get("eval_duration", 0) + tokens_per_second = 0 + + if eval_count > 0 and eval_duration > 0: + tokens_per_second = ( + eval_count / eval_duration * 1_000_000_000 + ) # nanoseconds to seconds (eval_count / eval_duration * 10^9) + + return response_data["response"], ollama_latency, tokens_per_second else: - return f"Error: {response.status_code}", ollama_latency + return f"Error: {response.status_code}", ollama_latency, 0 if __name__ == "__main__": print("📥 Indexing documents...") - docs_count = index_documents() + docs_count, bulk_latency = index_documents() - query = "performance issues in the API" + query = "Can you summarize the performance issues in the API?" print(f"\n🔍 Search: '{query}'") search_results, search_latency = semantic_search(query) @@ -91,10 +94,12 @@ def query_ollama(prompt, model="qwen3:4b"): prompt = f"{context}\nQuestion: {query}\nAnswer:" print("🤖 Asking to model...") - response, ollama_latency = query_ollama(prompt) + response, ollama_latency, tokens_per_second = query_ollama(prompt) print(f"\n💡 Question: {query}\n📝 Answer: {response}") + print(f"📄 Documents Indexed: {docs_count} | Bulk Latency: {bulk_latency:.0f}ms") print(f"\n🔍 Search Latency: {search_latency:.0f}ms") - print(f"🤖 Ollama Latency: {ollama_latency:.0f}ms") - print(f"📄 Documents Indexed: {docs_count}") + print( + f"🤖 Ollama Latency: {ollama_latency:.0f}ms | {tokens_per_second:.1f} tokens/s" + ) From 505ad49a0feff63b7162964ec3a16302196dbad5 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Fri, 19 Sep 2025 17:20:30 -0500 Subject: [PATCH 5/7] Deleting docker-compose, adding tinyllama results, code changes and dataset changes --- .../Dataset/meeting_QA-team_wednesday.txt | 41 ++++++++++- .../meeting_development-team_monday.txt | 35 +++++++++- .../meeting_management-sync_friday.txt | 40 +++++++++-- .../Dataset/report_QA-team.txt | 31 +++++++++ .../Dataset/report_development-team.txt | 31 ++++++++- .../app-logs/results.md | 69 ++++--------------- .../app-logs/tinyLlama-results.md | 15 ++++ .../docker-compose.yml | 20 ------ .../script.py | 57 ++++++++------- 9 files changed, 227 insertions(+), 112 deletions(-) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md delete mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt index 1550401d..78204cb6 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_QA-team_wednesday.txt @@ -1,3 +1,38 @@ -• Maria: “Data imports are failing when addresses contain special characters.” -• Tom: “That matches what we saw last week. We need a parser fix.” -• Maria: “Agreed, let’s log this as a blocker.” \ No newline at end of file +MEETING TRANSCRIPT - QA TEAM +Date: Wednesday, September 18, 2025 +Time: 10:00 AM - 11:30 AM +Participants: Maria (QA Lead), Tom (Senior QA Engineer), Lisa (QA Automation Engineer), Roberto (Manual Testing Specialist) + +[10:02] Maria: Let's review CRM migration testing progress. Tom, report on data import tests? + +[10:03] Tom: Found critical issues. Import failures with special characters in addresses and names. + +[10:06] Tom: UTF-8 parsing problems with accents, currency symbols, and Asian characters. + +[10:08] Tom: 12% of records affected - about 15,000 out of 125,000 total records. + +[10:09] Roberto: Confirmed. Also, failed imports corrupt entire batches. + +[10:12] Lisa: No atomic transactions for batches? + +[10:13] Tom: Correct. Each record processed independently without rollback. + +[10:15] Roberto: Found referential integrity issues - orphaned references between contacts and companies. + +[10:19] Maria: Need three validation types: pre-import, during import, and post-import. + +[10:25] Tom: Recommend smaller migration batches to reduce risk? + +[10:26] Maria: Excellent. Batches of 5,000 records with validation between each. + +[10:30] Maria: Four recommendations: UTF-8 parser fix, atomic transactions, handle orphaned references, small batch migration. + +[10:33] Roberto: Also need concurrency testing during migration. + +[10:40] Maria: Complete additional testing in one week. Feasible? + +[10:42] Tom: Will share test cases today. + +[10:44] Maria: Friday 2 PM meeting before management review. + +[10:45] Lisa: Will prepare testing metrics dashboard. \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt index 86aa66d0..aa6deb24 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_development-team_monday.txt @@ -1,3 +1,32 @@ -• Alice: “The API is working, but response times are too slow with more than 1,000 queries.” -• John: “We may need to add caching or optimize indexes.” -• Alice: “Let’s prioritize this for the next sprint.” \ No newline at end of file +MEETING TRANSCRIPT - DEVELOPMENT TEAM +Date: Monday, September 16, 2025 +Time: 09:00 AM - 10:15 AM +Participants: Alice (Tech Lead), John (Senior Developer), Sarah (Backend Developer), Mike (DevOps Engineer) + +[09:02] Alice: Let's review the search API deployed last week. Any issues? + +[09:03] Sarah: API works but performance degrades with 1,000+ queries per minute. Response times jump from 200ms to 3 seconds. + +[09:05] John: Elasticsearch queries and no caching layer? + +[09:06] Sarah: Exactly. Complex queries are slow, and we need Redis caching. + +[09:07] Mike: Also hitting CPU limits during spikes. Need auto-scaling. + +[09:08] Alice: Three priorities: query optimization, Redis cache, and infrastructure scaling. + +[09:11] Sarah: Propose 15-minute TTL cache with event-based invalidation. + +[09:13] John: I'll optimize bool queries and add calculated index fields. + +[09:17] Mike: Can set up auto-scaling by tomorrow - scale to 6 instances at 70% CPU. + +[09:18] Sarah: Starting Redis today, basic version by Wednesday. + +[09:19] John: New indexes and query optimization ready for testing Wednesday. + +[09:24] Alice: Clear plan. Mike handles scaling, Sarah implements cache, John optimizes queries. + +[09:26] Alice: I'll coordinate with product team on deployment impacts and QA for load testing. + +[09:30] Alice: Meeting Wednesday 3 PM to review progress. Thanks team! \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt index 810e76af..7d516d08 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/meeting_management-sync_friday.txt @@ -1,4 +1,36 @@ -• Manager: “Are we on track for the migration deadline next month?” -• Alice: “Development is slightly behind due to performance issues.” -• Maria: “QA also found blockers with data imports.” -• Manager: “Okay, let’s adjust the timeline by two weeks to ensure quality.” \ No newline at end of file +MEETING TRANSCRIPT - MANAGEMENT SYNC +Date: Friday, September 20, 2025 +Time: 02:00 PM - 03:00 PM +Participants: David (Project Manager), Alice (Tech Lead), Maria (QA Lead), Emma (Product Manager), Carlos (DevOps Manager) + +[14:03] Emma: Good progress. Users report 40% search speed improvement, but support tickets show peak hour performance issues. + +[14:05] Alice: We've identified bottlenecks. Working on Redis caching and Elasticsearch query optimization. + +[14:06] David: Can we resolve issues without impacting October migration date? + +[14:09] Alice: Recommend two-week extension for complete migration due to performance issues. + +[14:10] Maria: QA agrees. Found data import blockers with special characters and integrity issues. + +[14:12] Maria: Need one week to fix issues, another for complete re-testing. + +[14:14] Carlos: Infrastructure supports extension for proper rollback and disaster recovery testing. + +[14:15] Emma: Could we do partial migration on original date? + +[14:17] Alice: Yes. Contact management module first, reports and analytics in phase two. + +[14:21] Maria: Phased migration ideal for QA - validate each module independently. + +[14:22] David: Proposal: Phase 1 - Contact management October 15th. Phase 2 - Complete migration October 30th. + +[14:23] Alice: Reasonable timeline for performance fixes. + +[14:24] Emma: Works from product perspective. Will update stakeholder communications. + +[14:25] Maria: QA commits to these timelines. + +[14:26] Carlos: Will prepare deployment strategies for both phases. + +[14:32] David: Carlos, send deployment calendar by Monday. Thanks team! \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt index e69de29b..c5730a84 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_QA-team.txt @@ -0,0 +1,31 @@ +WEEKLY REPORT - QA TEAM +Week of September 16-20, 2025 +Prepared by: Maria Gonzalez, QA Lead + +=== EXECUTIVE SUMMARY === +QA team identified critical issues in CRM migration testing. Significant problems in legacy data import and referential integrity require immediate attention. + +=== TESTING COMPLETED === +- Functional: Contact management (100%), Authentication (100%), Search (75%), Analytics (60%) +- Data import: 125,000 legacy records tested, 12 critical issues found +- Performance: Core modules complete, identified issues with 500+ concurrent users + +=== CRITICAL ISSUES === +**QA-2025-001 - Data Import Failures** +- UTF-8 parsing problems with special characters +- 15,000 records affected (12% of total) +- Escalated to development + +**QA-2025-002 - Transaction Integrity** +- Failed imports leave batches in inconsistent state +- No atomic transactions for batches +- Requires architecture redesign + +**QA-2025-003 - Orphaned References** +- 2,300 records with invalid company/contact references +- Pending business logic decision + +=== METRICS === +- Test cases executed: 847 of 1,200 (70.6%) +- Pass rate: 79.3%, Automation coverage: 36% +- Bugs: 28 total (4 critical, 8 high, 12 medium, 4 low) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt index 5670f6d6..932c920b 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/Dataset/report_development-team.txt @@ -1 +1,30 @@ -The migration to the new CRM is progressing. We finished setting up the database schema and implemented the first batch of API integrations. The main issue is performance under heavy load, especially with customer search. We estimate two more sprints to stabilize. \ No newline at end of file +WEEKLY REPORT - DEVELOPMENT TEAM +Week of September 16-20, 2025 +Prepared by: Alice Thompson, Tech Lead + +=== EXECUTIVE SUMMARY === +Development team completed critical infrastructure components but identified performance bottlenecks requiring attention before production deployment. + +=== KEY ACCOMPLISHMENTS === +- Database schema and indexes completed for CRM +- 12 of 18 API endpoints integrated with authentication +- Contact management: 95% complete, Search: 80%, Analytics: 70% + +=== TECHNICAL CHALLENGES === +- Critical: Search API degrades at 1,000+ queries/minute (200ms to 3+ seconds) +- Root cause: Complex Elasticsearch queries without caching layer +- Multi-filter searches average 1.2 seconds execution time + +=== ACTION PLAN NEXT WEEK === +1. Redis cache implementation (Sarah) - Basic by Wednesday, complete by Friday +2. Elasticsearch query optimization (John) - Testing ready Wednesday +3. Auto-scaling setup (Mike) - Scale to 6 instances at 70% CPU + +=== METRICS === +- Story points: 43 of 50 completed (86%) +- Bugs: 7 reported, 12 resolved +- Code coverage: 78% (target: 80%) + +=== TIMELINE === +- October 15 Contact Management: 85% confidence, 2 sprints remaining +- October 30 Complete Migration: 90% confidence, 4 sprints remaining \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md index 853101ac..2626190d 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/results.md @@ -1,68 +1,23 @@ 📥 Indexing documents... -🔍 Search: 'Can you summarize the performance issues in the API?' -🤖 Asking to model... +🔍 Search: 'Can you summarize the performance issues in the API?' -## 💡 Question: Can you summarize the performance issues in the API? +## 🤖 Asking to model: llama3.2 +### 💡 Question: +Can you summarize the performance issues in the API? ### 📝 Answer: +According to the transcript, the performance issues in the API are: - -Okay, the user is asking about performance issues in an API. Let me start by understanding what they need. They might be a developer or a tech lead dealing with slow API responses. First, I should figure out the common causes of API performance problems. +1. Response times increase from 200ms to 3 seconds when handling 1,000+ queries per minute. +2. Complex Elasticsearch queries are slow, with an average execution time of 1.2 seconds. +3. Performance degrades during spikes. -Hmm, the user didn't provide specific details about their API. So I need to cover the main areas without assuming too much. Let me list out the typical issues: database queries, network latency, code inefficiencies, caching, rate limiting, external dependencies, etc. - -Wait, the user mentioned "performance issues in the API" but didn't specify if it's their own API or a third-party one. I should clarify that. But since the answer section is empty, maybe they want a general guide. - -I recall that common causes include slow database queries, especially if they're not optimized. Maybe they have N+1 queries? Or improper indexing. Also, heavy processing in the backend could be a problem. Like, if the API is doing a lot of computations per request. - -Network issues might be another angle. If the API is hosted on a different server, latency could be high. Or maybe the user is facing timeouts. - -Caching is important too. If the API isn't caching responses, every request goes to the backend. But if they have caching in place and it's not working right, that could cause slowness. - -External dependencies—like calling another API that's slow. That's a common pitfall. Also, rate limiting might be causing delays if the API is hit too hard. - -Wait, the user might need actionable steps. So I should structure the answer into sections: common causes, diagnostic steps, solutions. But the answer is supposed to be short since it's a fill-in. The user's instruction says "Answer:" so they want a concise answer. - -Looking back at the information provided, there's no specific data. So the answer should be a general response. Maybe the user expects a list of possible causes? Like in the answer field. - -Wait, the problem says "Information found:" followed by the question and answer. But the answer is empty. So the task is to generate the answer based on typical knowledge. - -I think the best approach is to list the main causes without being too technical. Let me check standard API performance issues. - -Top causes: -1. Slow database queries (e.g., missing indexes, complex joins) -2. Inefficient code (e.g., unnecessary loops, heavy computations) -3. Lack of caching -4. High network latency -5. External service dependencies -6. Rate limiting or too many requests -7. Inadequate server resources (CPU, memory) - -Also, maybe the API is not using asynchronous processing for long tasks. Or the response size is too big, causing slow transfers. - -The user might be looking for a quick reference. So I'll structure the answer as a bullet list of key points. But since it's an answer field, maybe a concise paragraph. - -Wait, the user's instruction says "Answer:" so I need to fill that part. Let me draft a response. - -"Common causes include slow database queries, inefficient code logic, lack of caching, high network latency, external dependencies, and insufficient server resources. Diagnose using tools like API monitoring, profiling, and logs." - -But maybe they want more specific. Alternatively, if this is for a specific scenario, but the user didn't specify. Hmm. - -Another angle: sometimes performance issues are due to the API design itself, like REST vs. GraphQL, but that's probably too specific. - -I think the safest answer is to list the main points briefly. Let me check similar problems online. For example, common API performance issues are often related to database, code, caching. - -Okay, I'll go with that. - - -## Final Answer: - -Common causes include slow database queries (e.g., missing indexes, N+1 queries), inefficient code logic (e.g., excessive computations, redundant operations), lack of caching, high network latency, external dependency delays, rate limiting, and insufficient server resources (CPU/memory). Diagnose using profiling tools, API monitoring, and log analysis to identify bottlenecks. +These issues are attributed to the lack of caching and a complex Elasticsearch query setup. ## App performance metrics: +✅ Indexed 5 documents in 96ms -📄 Documents Indexed: 5 | Bulk Latency: 37ms +🔍 Search Latency: 20ms -🔍 Search Latency: 32ms -🤖 Ollama Latency: 29411ms | 29.5 tokens/s \ No newline at end of file +🤖 Ollama Latency: 36772ms | 24.7 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md new file mode 100644 index 00000000..8c500d14 --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md @@ -0,0 +1,15 @@ +📥 Indexing documents... + +🔍 Search: 'Can you summarize the performance issues in the API?' + +## 🤖 Asking to model: TinyLlama + +### 💡 Question: Can you summarize the performance issues in the API? +#### 📝 Answer: +InfoRama has identified some issues with the seaRCSearch API, which was deployed last week. The performance of the API is causing delays and bottlenecks for key components such as query optimization, Redis cache, and infrastructure scaling. The team is working on a Redis cache implementation and Elasticsearch query optimization, but they need to get the SeaRCSearch API to scale efficiently by 6 instances at 70% CPU. The DeveloPMent Team has set three priorities: query optimization, Redis cache, and infrastructure scaling. The team is working on testing their progress and setting up automated scaling for load testing. In addition to these issues, the team identified complex Elasticsearch queries without a cchinig layer, which led to time-consuming and inefficient execution times. + +✅ Indexed 5 documents in 152ms + +🔍 Search Latency: 29ms + +🤖 Ollama Latency: 19178ms | 38.9 tokens/s \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml deleted file mode 100644 index c6e2d188..00000000 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/docker-compose.yml +++ /dev/null @@ -1,20 +0,0 @@ -services: - ollama: - image: ollama/ollama:latest - container_name: ollama - ports: - - "11434:11434" - volumes: - - ollama_data:/root/.ollama - entrypoint: > - sh -c " - /bin/ollama serve & - sleep 5 && - /bin/ollama run qwen3:4b && - wait - " - restart: unless-stopped - -volumes: - ollama_data: - driver: local \ No newline at end of file diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py index c4216d25..91ef339f 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/script.py @@ -2,7 +2,7 @@ import time import requests -from elasticsearch import Elasticsearch +from elasticsearch import Elasticsearch, helpers ES_URL = "http://localhost:9200" ES_API_KEY = "your-api-key-here" @@ -10,31 +10,38 @@ OLLAMA_URL = "http://localhost:11434/api/generate" DATASET_FOLDER = "./Dataset" -es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) +es_client = Elasticsearch(ES_URL, api_key=ES_API_KEY) -def index_documents(): - docs = [] - for filename in os.listdir(DATASET_FOLDER): +def build_documents(dataset_folder, index_name): + for filename in os.listdir(dataset_folder): if filename.endswith(".txt"): - filepath = os.path.join(DATASET_FOLDER, filename) + filepath = os.path.join(dataset_folder, filename) with open(filepath, "r", encoding="utf-8") as file: content = file.read() - docs.append({"index": {"_index": INDEX_NAME}}) - docs.append({"file_title": filename, "file_content": content}) + yield { + "_index": index_name, + "_source": {"file_title": filename, "file_content": content}, + } - indexed_docs_count = 0 - if docs: +def index_documents(): + try: start_time = time.time() - response = es_client.bulk(body=docs) - bulk_latency = (time.time() - start_time) * 1000 # ms - indexed_docs_count = len(response["items"]) - return indexed_docs_count, bulk_latency + success, _ = helpers.bulk( + es_client, build_documents(DATASET_FOLDER, INDEX_NAME) + ) + + end_time = time.time() + bulk_latency = (end_time - start_time) * 1000 # ms + + return success, bulk_latency + except Exception as e: + print(f"❌ Error: {str(e)}") def semantic_search(query, size=3): @@ -45,15 +52,14 @@ def semantic_search(query, size=3): } response = es_client.search(index=INDEX_NAME, body=search_body) - search_latency = (time.time() - start_time) * 1000 # ms return response["hits"]["hits"], search_latency -def query_ollama(prompt, model="qwen3:4b"): +def query_ollama(prompt, model): start_time = time.time() - data = {"model": model, "prompt": prompt, "stream": False} + data = {"model": model, "prompt": prompt, "stream": False, "think": False} response = requests.post(OLLAMA_URL, json=data) @@ -78,11 +84,13 @@ def query_ollama(prompt, model="qwen3:4b"): if __name__ == "__main__": print("📥 Indexing documents...") - docs_count, bulk_latency = index_documents() + success, bulk_latency = index_documents() + + time.sleep(2) # Wait for indexing to complete - query = "Can you summarize the performance issues in the API?" + query = "Can you summarize the performance issues in the API?" - print(f"\n🔍 Search: '{query}'") + print(f"🔍 Search: '{query}'") search_results, search_latency = semantic_search(query) context = "Information found:\n" @@ -93,13 +101,14 @@ def query_ollama(prompt, model="qwen3:4b"): prompt = f"{context}\nQuestion: {query}\nAnswer:" - print("🤖 Asking to model...") - response, ollama_latency, tokens_per_second = query_ollama(prompt) + ollama_model = "llama3.2" + print(f"🤖 Asking to model: {ollama_model}") + response, ollama_latency, tokens_per_second = query_ollama(prompt, ollama_model) print(f"\n💡 Question: {query}\n📝 Answer: {response}") - print(f"📄 Documents Indexed: {docs_count} | Bulk Latency: {bulk_latency:.0f}ms") - print(f"\n🔍 Search Latency: {search_latency:.0f}ms") + print(f"✅ Indexed {success} documents in {bulk_latency:.0f}ms") + print(f"🔍 Search Latency: {search_latency:.0f}ms") print( f"🤖 Ollama Latency: {ollama_latency:.0f}ms | {tokens_per_second:.1f} tokens/s" ) From b8e502a4fad36b15981afa26c5105c2de01d013b Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Sat, 20 Sep 2025 13:54:39 -0500 Subject: [PATCH 6/7] tinyLlama results --- .../app-logs/tinyLlama-results.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md index 8c500d14..69ed311f 100644 --- a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/tinyLlama-results.md @@ -6,7 +6,7 @@ ### 💡 Question: Can you summarize the performance issues in the API? #### 📝 Answer: -InfoRama has identified some issues with the seaRCSearch API, which was deployed last week. The performance of the API is causing delays and bottlenecks for key components such as query optimization, Redis cache, and infrastructure scaling. The team is working on a Redis cache implementation and Elasticsearch query optimization, but they need to get the SeaRCSearch API to scale efficiently by 6 instances at 70% CPU. The DeveloPMent Team has set three priorities: query optimization, Redis cache, and infrastructure scaling. The team is working on testing their progress and setting up automated scaling for load testing. In addition to these issues, the team identified complex Elasticsearch queries without a cchinig layer, which led to time-consuming and inefficient execution times. +During the week of September 16-20, 2025, the Development Team identified complex Elasticsearch queries and no automatic cachining layer. They completed SeaRChe search optimization but encountered performance bottlenecks requiring attention before production deployment. The team worked on implementing critical infrastructure components such as database schema and indexes, but also identified performance issues with seaRChe searches, and 95% of the remaining queries were considered critical. Despite these challenges, critical components completed by the end of the week for the upcoming migration on October 15th. The team worked on Elasticsearch query optimization and Redis cache implementation, as well as automated testing to ensure proper rollback and disaster recovery, while preparing deployment strategies for both phases of the project. ✅ Indexed 5 documents in 152ms From 401d76c7dc91ddd0e08061601407b0ccb32d0882 Mon Sep 17 00:00:00 2001 From: Delacrobix Date: Sun, 21 Sep 2025 07:30:42 -0500 Subject: [PATCH 7/7] qwen3:4b model results --- .../app-logs/qwen3:4b-results.md | 106 ++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md diff --git a/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md new file mode 100644 index 00000000..1048cbdf --- /dev/null +++ b/supporting-blog-content/local-rag-with-lightweight-elasticsearch/app-logs/qwen3:4b-results.md @@ -0,0 +1,106 @@ +📥 Indexing documents... + +🔍 Search: 'Can you summarize the performance issues in the API?' + +## 🤖 Asking to model: qwen3:4b + +### 💡 Question: Can you summarize the performance issues in the API? +#### 📝 Answer: + +`` + +We are given three files: + 1. meeting_development-team_monday.txt (transcript from Monday, Sept 16, 2025) + 2. report_development-team.txt (weekly report for week of Sept 16-20, 2025) + 3. meeting_management-sync_friday.txt (transcript from Friday, Sept 20, 2025) + +The question asks: "Can you summarize the performance issues in the API?" + +We need to look for information about API performance issues in these files. + +From the first file (meeting_development-team_monday.txt): + - At [09:03] Sarah: "API works but performance degrades with 1,000+ queries per minute. Response times jump from 200ms to 3 seconds." + - At [09:05] John: "Elasticsearch queries and no caching layer?" + - At [09:06] Sarah: "Exactly. Complex queries are slow, and we need Redis caching." + - At [09:13] John: "I'll optimize bool queries and add calculated index fields." + - Also, in the same meeting: [09:17] Mike: "Also hitting CPU limits during spikes. Need auto-scaling." + +From the second file (report_development-team.txt): + - In "TECHNICAL CHALLENGES": + - Critical: Search API degrades at 1,000+ queries/minute (200ms to 3+ seconds) + - Root cause: Complex Elasticsearch queries without caching layer + - Multi-filter searches average 1.2 seconds execution time + +From the third file (meeting_management-sync_friday.txt): + - [14:03] Emma: "Good progress. Users report 40% search speed improvement, but support tickets show peak hour performance issues." + +So, the key performance issues in the API (specifically the search API) are: + +1. The search API degrades significantly when handling more than 1,000 queries per minute, with response times increasing from 200ms to 3 seconds (or more). +2. The root cause is complex Elasticsearch queries without a caching layer. +3. Multi-filter searches take an average of 1.2 seconds to execute. +4. The team has been working on: + - Implementing Redis caching (with a proposed 15-minute TTL and event-based invalidation) + - Optimizing Elasticsearch queries (specifically bool queries and adding calculated index fields) + - Setting up auto-scaling to handle CPU spikes (to 6 instances at 70% CPU) + +Additionally, the meeting on Friday (Sept 20) notes that users have seen a 40% improvement in search speed but there are still peak hour performance issues (as reported in support tickets). + +Therefore, the summary of performance issues in the API (focusing on the search API) is: + +- The search API experiences a critical performance degradation when the query rate exceeds 1,000 queries per minute, causing response times to jump from 200ms to 3 seconds or more. +- The root cause is complex Elasticsearch queries without a caching layer, leading to slow response times for multi-filter searches (averaging 1.2 seconds). +- The team is addressing this with Redis caching, Elasticsearch query optimization, and infrastructure scaling. + +We are to write a concise summary. + +Let me structure the answer: + +The API (specifically the search API) has the following performance issues: +1. Under heavy load (1,000+ queries per minute), response times degrade from 200ms to 3+ seconds. +2. Root cause: Complex Elasticsearch queries without a caching layer. +3. Multi-filter searches average 1.2 seconds execution time. + +The team is working on fixing these by implementing Redis caching, optimizing Elasticsearch queries, and setting up auto-scaling. + +We don't need to include the Friday meeting's 40% improvement because the question is about the issues that were identified (the current state). The meeting on Friday mentions that users report 40% improvement (so that's a positive note) but the issues (peak hour performance) are still present. + +So, the summary should focus on the issues as they were identified in the Monday meeting and the report. + +Answer: + +The search API experiences significant performance degradation when handling more than 1,000 queries per minute, with response times increasing from 200ms to 3 seconds or more. The root cause is complex Elasticsearch queries without a caching layer, which also results in multi-filter searches taking an average of 1.2 seconds to execute. The development team is addressing these issues through Redis caching implementation, Elasticsearch query optimization, and infrastructure scaling. + +`` + +Based on the meeting transcripts and weekly report provided, here's a concise summary of the API performance issues: + +### Key Performance Issues in the Search API: +1. **Critical Degradation Under Load**: + - Response times jump from **200ms to 3+ seconds** when handling **1,000+ queries per minute** (identified in Monday meeting and weekly report). + - Multi-filter searches average **1.2 seconds** execution time. + +2. **Root Cause**: + - **Complex Elasticsearch queries** without a caching layer (confirmed by Sarah in Monday meeting). + - No Redis caching implementation (directly cited as the bottleneck). + +3. **Secondary Impact**: + - Infrastructure is hitting **CPU limits during traffic spikes** (reported by Mike in Monday meeting), requiring auto-scaling. + +4. **Current Progress**: + - Users have seen a **40% speed improvement** (per Friday meeting), but peak-hour performance issues persist in support tickets. + - The team is addressing this through: + - Redis caching (15-min TTL with event-based invalidation) + - Elasticsearch query optimization (bool queries + calculated index fields) + - Auto-scaling (target: 6 instances at 70% CPU) + +### Why This Matters for Deployment: +The issues are critical enough that the migration timeline was adjusted to **phase the deployment** (Contact management first on Oct 15, full migration on Oct 30) to ensure stability before production. Without these fixes, the API would risk significant slowdowns during high-traffic periods. + +*Summary derived from all three files, with focus on API performance specifics (search API) as per the question.* + +✅ Indexed 5 documents in 151ms + +🔍 Search Latency: 39ms + +🤖 Ollama Latency: 137790ms | 14.3 tokens/s \ No newline at end of file