Apsy

apsy

Welcome to HackerNoon’s interview series. This section is curated by our Editorial team to spotlight bold and disruptive startups across the globe. If you’ve been nominated, and answer these questions Startups-Of-The-Year create a brand profile here. Hey Hackers, Apsy has been nominated in HackerNoon's annual Startup of the Year awards in Los Angeles, US. Please vote for us . here Read more about us below to understand why we deserve your vote. Meet Apsy Our start-up is called , a cool name rooted in Apps, but to us, it means “making app-building a breeze!” We are the first to introduce a fully AI-powered app builder. Our users speak their minds as our AI builds them. Apsy What makes us a different startup from others who offer tools to build apps is that we're all about letting your ideas flow while our AI does the heavy lifting. You dream it, speak it, and our AI builds it. Unlike traditional DIY tools, we take care of all the techy stuff, so our users don't have to. With Apsy, your creativity is the only limit. My Role Tooraj, a double Ph.D. dynamo in Economics and Computer Science, is a seasoned tech exec with a penchant for AI algorithms. A Y-Combinator and Techstars alumni is now driving his second startup, Apsy, towards reimagining software development. With a vision to make it simpler and cost-effective through AI, Tooraj is steering tech's future. How We're Disrupting/Improving the app development industry Building an app with traditional methods feels like a tough mountain to climb, right? But at Apsy, we're turning that hike into a fun walk in the park! Just chat with our AI about your brilliant app idea, answer a few clever questions it throws at you, and ta-da! Your app is up and running in a snap - we're talking hours, not months! We're shaking up the app-making game, making it a piece of cake for everyone, not just the coding wizards. Apsy isn't just transforming app development but the whole software landscape and tech entrepreneurship. Exciting times are ahead! Standing Out from The Crowd Do you remember how difficult building an app was in the good old days? Costly developers, scary DIY journeys, and months of learning only to end up with an 'okay-ish' app. Well, not anymore! We Apsy all you need to do is share your big idea, answer a few questions from our smarty-pants AI, and boom! It starts crafting screen options for you. And the best part? You can add your finishing touches and have a fabulous, tailor-made app ready to shine in just a few hours. And all this without burning a hole in your pocket! Building an app has never been this fun and easy, right? Our Predictions/Thoughts on the App Development Industry in 2023 The tech industry, specifically app development, is experiencing a significant shift towards no-code and low-code solutions. However, their complexity often presents challenges. Here, AI-driven platforms like Apsy come into play, simplifying app creation without needing users to be coding experts. As we move further into 2023 and beyond, we predict a surge in AI integration into app development owing to the rising demand for rapid, cost-effective digital solutions. The growth of AI sophistication will enable a better understanding of user needs and the delivery of high-quality, personalized apps. This AI infusion will transform the technological landscape and democratize the digital space, fostering innovation and promoting tech entrepreneurship. As Apsy, we're excited to pioneer this transformative journey, making app development more accessible and enjoyable. What word defines the state of app development in 2023? If you're asking about the vibe of app development in 2023, it's all 'Mind-to-Machine'! Just picture this - you come up with a killer app idea, chat about it, and voila, our AI buddy gets it done. No fuss, no code, just pure creativity! This exciting 'Mind-to-Machine' era is giving everyone the power to turn their app dreams into reality. It's like having a chat with a friend who happens to be a coding genius. So, buckle up, folks! We're on a fun-filled, game-changing journey that's turning the tech world on its head! Why we decided to participate in HackerNoon's Startup of the Year awards We jumped into HackerNoon's Startup of the Year awards because we're shaking things up with our 'Mind-to-Machine' tech at Apsy and wanted to share this cool innovation with fellow tech enthusiasts. Plus, who doesn't love a good challenge? We saw it as a great chance to learn, grow, and have some fun while competing with other innovative startups. So, here we are, all set to dazzle at the awards. Fingers crossed, folks! Final Thoughts At Apsy, we're on an exciting mission in 2023, transforming app development and making it accessible for all. We're thrilled to bring our innovation to HackerNoon's Startup of the Year awards, showcasing our approach, learning from peers, and embracing challenges. So, we invite you to on this thrilling journey, where we'll turn dreams into digital realities together! join us Don’t forget to ! Vote for us today

Vote for Apsy in HackerNoon's Startups of the Year 2023

To help researchers and developers in academia and beyond, Alibaba has now published its Cluster Data V2018 for all to explore In IT articles about internet applications, you will often find words such as “large scale” and “mass requests”. These applications all run in large-scale data centers, and readers generally have many questions about those environments. For example, what is the operating status of each machine in the data center? What kinds of applications are running? What are the characteristics of these applications? With the exception of a few senior experts, it is rare for students and corporate researchers to understand these details. Today, Alibaba shares a real dataset for computer clusters: (attached at the end of article). This dataset provides a full record of details for the servers and running tasks in Alibaba’s production cluster. With the release of this data, Alibaba hopes to engage its peers in academia and the wider industry and to promote further development within the industry. Alibaba Cluster Data V2018 Drawing on insights from Lin Shi, a technical expert at the Ali System Software Division, this article offers an in-depth introduction to this unique dataset, as well as findings from academic research with the previous year’s data. Releasing the Dataset: A Resource for Exploration In 2015, Alibaba tried to deploy latency insensitive batch computing tasks and latency sensitive online services to the same batch of machines in its data center, with the goals of allowing redundant resources to be fully utilized and improving the overall utilization of these machines. After more than three years of trial demonstrations, structural adjustments, and optimization of resource isolation, this program has now moved into the mass production phase. Average resource utilization of clusters has since increased from 10% to 45% using colocation technology (i.e. the technology that allows running online service and batch workloads on same machine). In addition, through various optimization methods, more tasks can now be run in the data center, and the average transaction cost of the 11.11 Global Shopping Festival has been reduced by 17% per 10,000 transactions. Though some readers will understand this achievement and how it was accomplished, many are likely to have questions such as what exactly the computer cluster looks like after optimization, or what colocation means and why it matters. In releasing the Alibaba Cluster Data V2018 dataset, Alibaba hopes to help interested students and researchers answer those questions and better understand large-scale data centers. Using the dataset, individuals can learn more about how Alibaba has increased resource utilization to 45% via colocation; how many tasks Alibaba runs each day; and what the resource requirements of the business are. How individuals use this dataset depends entirely on their needs. Making Use of the Data At 50 GB compressed and 270 GB uncompressed, Alibaba Cluster Data V2018 is a large dataset with many different uses. In six files, it has data for 4000 servers, corresponding online application containers, and operation of offline computing tasks for up to eight days. With Alibaba Cluster Data V2018, individuals can do the following: · Understand the servers and the characteristics of running tasks in today’s advanced data centers. · Experiment with various algorithms for task management and cluster optimization in scheduling and operations, and write papers about them. · Use the data to learn how to conduct data analysis, and reveal more techniques and methodologies that have not yet been discovered. The following are examples of questions the data can be used to answer: · E-commerce businesses face different pressures during daytime and nighttime. How can we improve overall resource utilization with these peaks and valleys? · How many dependencies does Alibaba’s longest DAG have? · How long does a container typically exist? · What is the typical lifetime of a computational task? · Multiple instances of a task are theoretically similar to each other, but do they all run at the same time? In fact, academics have already used Alibaba cluster data for a range of crucial analysis and research. In 2017 and 2018, a number of prominent academic papers were published based on of the first wave of data shared in Alibaba Cluster Data V2017. The following sections show examples of academic uses of the dataset, many of which have been featured in academic conferences such as OSDI. LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation — Yizhou Shan, Yutong Huang, Yilun Chen, and Yiying Zhang; Purdue University. (OSDI’18 Best Paper Award recipient) Imbalance in the Cloud: An Analysis on Alibaba Cluster Trace — Chengzhi Lu et al. (BIGDATA 2017) Characterizing Co-located Datacenter Workloads: An Alibaba Case Study — Yue Cheng, Zheng Chai, Ali Anwar. (APSys2018) The Elasticity and Plasticity in Semi-Containerized Co-locating Cloud Workload: a View from Alibaba Trace — Qixiao Liu and Zhibin Yu. (SoCC2018) Looking Forward: Updates in V2018 There are two major differences that distinguish the new V2018 dataset from the previous year’s V2017 dataset featured in the above research. First, the V2018 dataset includes the DAG information of some of our production batch workloads. This means that offline computing tasks like those commonly used in Map Reduce, Hadoop, Spark, and Flink are arranged in the form of a Directed Acyclic Graph (DAG), which shows parallelism, dependencies between tasks, and so on. As such, this dataset is the now the largest available DAG dataset from an actual production environment. The following figure illustrates and example of a DAG: Second, the V2018 dataset is considerably larger in scale than the previous set, which contained data for approximately 1300 machines over a 24-hour period. The new version includes data for 4000 machines over a period of 8 days. With so much having been accomplished using V2017 dataset, Alibaba looks forward to the developments to come as researchers begin work with the new dataset in 2019. (The original article is written by Ding Haiyang丁海洋) Alibaba Cluster Data V2018 Download link: [machine_meta]( http://clusterdata2018pubus.oss-us-west-1.aliyuncs.com/machine_meta.tar.gz) [machine_usage]( http://clusterdata2018pubus.oss-us-west-1.aliyuncs.com/machine_usage.tar.gz) [container_meta]( http://clusterdata2018pubus.oss-us-west-1.aliyuncs.com/container_meta.tar.gz) [container_usage]( http://clusterdata2018pubus.oss-us-west-1.aliyuncs.com/container_usage.tar.gz) [batch_task]( http://clusterdata2018pubus.oss-us-west-1.aliyuncs.com/batch_task.tar.gz) [batch_instance]( http://clusterdata2018pubus.oss-us-west-1.aliyuncs.com/batch_instance.tar.gz) Alibaba Tech First hand and in-depth information about Alibaba’s latest technology → Facebook: . Twitter: . “Alibaba Tech” “AlibabaTech”

Open Season for Research: Alibaba Releases Cluster Data from 4000 Servers

Security firm Asymmetric Research will serve as a core security contributor to the Bitcoin Layer 2 protocol Stacks and join its signer network, according to an announcement made Tuesday. The firm has begun security auditing of the upcoming sBTC asset while participating in the protocol's delegation program. Asymmetric Research, known for securing major protocols including Wormhole, Solana, and Cosmos, brings substantial expertise to the Bitcoin L2 landscape. The firm currently acts as the security partner for Jump Crypto and several prominent DeFi projects, while also contributing to Solana's new validator client, Firedancer. The move strengthens the security infrastructure around sBTC, a forthcoming programmable Bitcoin asset scheduled for release in Q4 2024. sBTC aims to provide a trust-minimized, decentralized way to use Bitcoin in smart contracts and decentralized applications, maintaining a 1:1 backing with Bitcoin. As a network signer, Asymmetric Research joins over 30 institutional node operators, including BitGo, Blockdaemon, Copper, and Figment, in securing the deposit and withdrawal process between BTC and sBTC. This extensive signer network represents one of the largest decentralized security implementations in the Bitcoin ecosystem. The value of building on Bitcoin comes down to security — ecosystems must prioritize security at all layers as they seek to unlock the Bitcoin economy. With Asymmetric Research, the Stacks ecosystem is adding yet another high-caliber entity to the mix of industry leaders collaborating to make sBTC the best version of programmable BTC available. Stacks core developers and Asymmetric share a commitment to protecting users and developers, and in addition to being a match in technical pedigree, are culturally aligned groups that will enhance each other’s thoughtful and rigorous approaches.” Mitchell Cuevas, Executive Director at The Stacks Foundation said. Jonathan Claudius, CEO at Asymmetric Research, commented on the collaboration: "Asymmetric Research is proud to participate in the Stacks ecosystem as it pioneers trust-minimized, decentralized assets like sBTC." The security enhancement comes amid broader developments in the Bitcoin L2 space, where developers are working to activate Bitcoin's estimated $1.2 trillion in latent capital for decentralized finance applications. The integration of Asymmetric Research adds to existing security measures, including: A decentralized network of validators and signers


100% Bitcoin finality at the consensus level


Multiple independent security audits


An ongoing Immunefi bug bounty program


Dedicated penetration testing throughout 2024


Consultation with the Staking Defense League The protocol's native token, STX, which functions as gas for transactions, was the first cryptocurrency to undergo an SEC-qualified sale in the United States. The ecosystem currently encompasses more than 30 contributing organizations, including developer tooling companies, wallet providers, and investment funds focused on Bitcoin layer 2 development. Don’t forget to like and share the story! Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program. HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR Security firm Asymmetric Research will serve as a core security contributor to the Bitcoin Layer 2 protocol Stacks and join its signer network, according to an announcement made Tuesday. The firm has begun security auditing of the upcoming sBTC asset while participating in the protocol's delegation program. Asymmetric Research, known for securing major protocols including Wormhole, Solana, and Cosmos, brings substantial expertise to the Bitcoin L2 landscape. The firm currently acts as the security partner for Jump Crypto and several prominent DeFi projects, while also contributing to Solana's new validator client, Firedancer. The move strengthens the security infrastructure around sBTC, a forthcoming programmable Bitcoin asset scheduled for release in Q4 2024. sBTC aims to provide a trust-minimized, decentralized way to use Bitcoin in smart contracts and decentralized applications, maintaining a 1:1 backing with Bitcoin. As a network signer, Asymmetric Research joins over 30 institutional node operators, including BitGo, Blockdaemon, Copper, and Figment, in securing the deposit and withdrawal process between BTC and sBTC. This extensive signer network represents one of the largest decentralized security implementations in the Bitcoin ecosystem. The value of building on Bitcoin comes down to security — ecosystems must prioritize security at all layers as they seek to unlock the Bitcoin economy. With Asymmetric Research, the Stacks ecosystem is adding yet another high-caliber entity to the mix of industry leaders collaborating to make sBTC the best version of programmable BTC available. Stacks core developers and Asymmetric share a commitment to protecting users and developers, and in addition to being a match in technical pedigree, are culturally aligned groups that will enhance each other’s thoughtful and rigorous approaches.” The value of building on Bitcoin comes down to security — ecosystems must prioritize security at all layers as they seek to unlock the Bitcoin economy. With Asymmetric Research, the Stacks ecosystem is adding yet another high-caliber entity to the mix of industry leaders collaborating to make sBTC the best version of programmable BTC available. Stacks core developers and Asymmetric share a commitment to protecting users and developers, and in addition to being a match in technical pedigree, are culturally aligned groups that will enhance each other’s thoughtful and rigorous approaches.” Mitchell Cuevas, Executive Director at The Stacks Foundation said. Mitchell Cuevas, Executive Director at The Stacks Foundation said. Jonathan Claudius, CEO at Asymmetric Research, commented on the collaboration: "Asymmetric Research is proud to participate in the Stacks ecosystem as it pioneers trust-minimized, decentralized assets like sBTC." The security enhancement comes amid broader developments in the Bitcoin L2 space, where developers are working to activate Bitcoin's estimated $1.2 trillion in latent capital for decentralized finance applications. The integration of Asymmetric Research adds to existing security measures, including: A decentralized network of validators and signers 100% Bitcoin finality at the consensus level Multiple independent security audits An ongoing Immunefi bug bounty program Dedicated penetration testing throughout 2024 Consultation with the Staking Defense League A decentralized network of validators and signers A decentralized network of validators and signers 100% Bitcoin finality at the consensus level 100% Bitcoin finality at the consensus level Multiple independent security audits Multiple independent security audits An ongoing Immunefi bug bounty program An ongoing Immunefi bug bounty program Dedicated penetration testing throughout 2024 Dedicated penetration testing throughout 2024 Consultation with the Staking Defense League Consultation with the Staking Defense League The protocol's native token, STX, which functions as gas for transactions, was the first cryptocurrency to undergo an SEC-qualified sale in the United States. The ecosystem currently encompasses more than 30 contributing organizations, including developer tooling companies, wallet providers, and investment funds focused on Bitcoin layer 2 development. Don’t forget to like and share the story! Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program. HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR Vested Interest Disclosure: This author is an independent contributor publishing via our business blogging program . HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR Vested Interest Disclosure: business blogging program business blogging program

Asymmetric Research Joins Stacks Ecosystem as Security Contributor to Bitcoin L2

One of my favorite interview questions is “What do such words as async and await tell you?” because it opens up an opportunity to have an interesting discussion with an interviewee… Or it doesn’t because they float on this topic. In my opinion, it is drastically important to understand why we use this technique. I feel like many developers prefer to rely on the “it is the best practice” statement and use asynchronous methods blindly. This article shows the difference between asynchronous and synchronous methods in practice. Tools .NET Web API application (test target) 2 Azure SQL Databases 2 Azure App Service on Windows (hosts the application) Azure App Insights (to gather metrics) locust framework (to simulate user load). Configuration I will run a benchmark in the following way. Two independent locust instances are running on two machines. Locust instances simulate a user that does the following: The user from the locust host 1 hits the synchronous endpoint of the App Service 1, gets the response, and stays idle for 0.5–1 seconds (the exact time delay is random). Repeats till the end of the experiment. The user from the locust host 2 behaves precisely the same, with only one difference — he hits the asynchronous endpoint of App Service 2. Under the hood, each App Service connects to its own database and executes a SELECT query that takes five seconds and returns a few rows of data. See the controller’s code below for references. I’ll use Dapper to make a call to the database. I’d like to draw your attention to the fact that the asynchronous endpoint calls the database asynchronously as well (QueryAsync<T>). It's worth adding that I deploy the same code to both app services. During the test, the number of users grows evenly to the target number (Number of Users). The speed of growth is controlled by a Spawn Rate parameter (number of unique users to join per second) — the higher the number is, the quicker the users are being added. The spawn rate is set to 10 users/s for all experiments. All experiments are limited to 15 minutes. You may find machine configuration details in the Technical Details section of the article. Metrics requests per minute — shows the number of requests that the application actually processed and returned a status code.
thread count — shows the number of threads the app service consumes.
median response time, ms The red lines refer to asynchronous, and the blue lines — to the synchronous endpoint, respectively. That’s it about theory. Let’s start. Experiment #1 number of users: 75 (per service) We can see that both endpoints perform similarly — handling around 750 requests per minute with a median response time of 5200 ms. The most fascinating graph in this experiment is a thread trend. You can see significantly higher numbers for the synchronous endpoint (a blue graph) — more than 100 threads! That’s expected, though, and matches the theory — when a request comes in, and the application makes a call to the database, the thread is blocked because it has to wait for a roundtrip to complete. Therefore, when another request comes in, the application has to produce a new thread to handle it. The red graph — the asynchronous endpoint thread count— proves different behavior. When a request comes in and the application makes a call to the database, the thread returns to a thread pool instead of being blocked. Therefore, when another request comes in, this free thread is reused. Despite incoming requests growing, the application doesn’t require any new threads, so their count remains the same. It’s worth mentioning the 3rd metric — median response time. Both endpoints showed the same result — 5200 ms. So, there is no difference in terms of performance. Now, it is time to pull up the stakes. Experiment #2 number of users: 150 We doubled the load. The asynchronous endpoint handles this task successfully—its request per minute rate floats around 1500. The synchronous brother eventually reached a comparable number of 1410. But if you look at the graph below, you will see that it took 10 minutes! The reason is that the synchronous endpoint reacts to a new user's arrival by creating another thread, but users are being added to the system (just to remind you that the Spawn Rate is 10 users/s) quicker than the web server can adapt. That’s why it queued so many requests at the very beginning. Unsurprisingly, the thread count metric is still around 34 for the asynchronous endpoint, while it increased from 102 to 155 for the synchronous one. The median response time degraded similarly to the request per minute rate — the synchronous response time was much higher at the beginning of the experiment. If I had kept the test for 24 hours, the median numbers would become even. Experiment #3 number of users: 200 The third experiment is intended to prove trends revealed during the second one —we can see further degradation of the synchronous endpoint. Conclusion Using asynchronous instead of synchronous operations doesn’t directly improve performance or user experience. First, it enhances stability and predictability under pressure. In other words, it raises the load threshold so the system can process more before it degrades. Appendix #1. Technical Details Azure App Service: B1, 100 ACU, 1,75 Gb Memory, A-Series compute equivalent.
Azure SQL Database: Standard S4: 200 DTUs, 500 Mb storage.
SQL Connection settings: Max Pool Size=200. Appendix #2. Notes To achieve the cleanest test result, I should have run tests from 2 VMs located in the same network where the target App Services sit. However, I assumed that a network lag would impact both apps in a more or less similar way. Therefore, it cannot jeopardize the main goal — comparing how asynchronous and synchronous methods behave. Appendix #3. Bonus Experiment What did I hack to force the synchronous endpoint to perform almost as asynchronous and plot the graph below (experiment conditions are the same as in the third one — 200 users)? One of my favorite interview questions is “What do such words as async and await tell you?” because it opens up an opportunity to have an interesting discussion with an interviewee… Or it doesn’t because they float on this topic. In my opinion, it is drastically important to understand why we use this technique. async await I feel like many developers prefer to rely on the “it is the best practice” statement and use asynchronous methods blindly. This article shows the difference between asynchronous and synchronous methods in practice. Tools .NET Web API application (test target) .NET Web API application (test target) 2 Azure SQL Databases 2 Azure SQL Databases 2 Azure App Service on Windows (hosts the application) 2 Azure App Service on Windows (hosts the application) Azure App Insights (to gather metrics) Azure App Insights (to gather metrics) locust framework (to simulate user load). locust framework (to simulate user load). locust Configuration I will run a benchmark in the following way. Two independent locust instances are running on two machines. Locust instances simulate a user that does the following: The user from the locust host 1 hits the synchronous endpoint of the App Service 1, gets the response, and stays idle for 0.5–1 seconds (the exact time delay is random). Repeats till the end of the experiment. The user from the locust host 1 hits the synchronous endpoint of the App Service 1, gets the response, and stays idle for 0.5–1 seconds (the exact time delay is random). Repeats till the end of the experiment. synchronous App Service 1, The user from the locust host 2 behaves precisely the same, with only one difference — he hits the asynchronous endpoint of App Service 2. The user from the locust host 2 behaves precisely the same, with only one difference — he hits the asynchronous endpoint of App Service 2. asynchronous App Service 2. Under the hood, each App Service connects to its own database and executes a SELECT query that takes five seconds and returns a few rows of data. See the controller’s code below for references. I’ll use Dapper to make a call to the database. I’d like to draw your attention to the fact that the asynchronous endpoint calls the database asynchronously as well ( QueryAsync<T> ). QueryAsync<T> It's worth adding that I deploy the same code to both app services. During the test, the number of users grows evenly to the target number ( Number of Users ). The speed of growth is controlled by a Spawn Rate parameter (number of unique users to join per second) — the higher the number is, the quicker the users are being added. The spawn rate is set to 10 users/s for all experiments. Number of Users Spawn Rate spawn rate All experiments are limited to 15 minutes. You may find machine configuration details in the Technical Details section of the article. Metrics requests per minute — shows the number of requests that the application actually processed and returned a status code. thread count — shows the number of threads the app service consumes. median response time, ms requests per minute — shows the number of requests that the application actually processed and returned a status code. requests per minute thread count — shows the number of threads the app service consumes. thread count median response time, ms median response time, ms The red lines refer to asynchronous, and the blue lines — to the synchronous endpoint, respectively. That’s it about theory. Let’s start. Experiment #1 Experiment #1 number of users: 75 (per service) number of users : 75 (per service) number of users We can see that both endpoints perform similarly — handling around 750 requests per minute with a median response time of 5200 ms. The most fascinating graph in this experiment is a thread trend. You can see significantly higher numbers for the synchronous endpoint (a blue graph) — more than 100 threads! That’s expected, though, and matches the theory — when a request comes in, and the application makes a call to the database, the thread is blocked because it has to wait for a roundtrip to complete. Therefore, when another request comes in, the application has to produce a new thread to handle it. The red graph — the asynchronous endpoint thread count— proves different behavior. When a request comes in and the application makes a call to the database, the thread returns to a thread pool instead of being blocked. Therefore, when another request comes in, this free thread is reused. Despite incoming requests growing, the application doesn’t require any new threads, so their count remains the same. It’s worth mentioning the 3rd metric — median response time . Both endpoints showed the same result — 5200 ms. So, there is no difference in terms of performance. median response time Now, it is time to pull up the stakes. Experiment #2 number of users: 150 number of users : 150 number of users We doubled the load. The asynchronous endpoint handles this task successfully—its request per minute rate floats around 1500. The synchronous brother eventually reached a comparable number of 1410. But if you look at the graph below, you will see that it took 10 minutes! request per minute The reason is that the synchronous endpoint reacts to a new user's arrival by creating another thread, but users are being added to the system (just to remind you that the Spawn Rate is 10 users/s) quicker than the web server can adapt. That’s why it queued so many requests at the very beginning. Spawn Rate Unsurprisingly, the thread count metric is still around 34 for the asynchronous endpoint, while it increased from 102 to 155 for the synchronous one. The median response time degraded similarly to the request per minute rate — the synchronous response time was much higher at the beginning of the experiment. If I had kept the test for 24 hours, the median numbers would become even. thread count median response time request per minute Experiment #3 number of users: 200 number of users : 200 number of users The third experiment is intended to prove trends revealed during the second one —we can see further degradation of the synchronous endpoint. Conclusion Using asynchronous instead of synchronous operations doesn’t directly improve performance or user experience. First, it enhances stability and predictability under pressure. In other words, it raises the load threshold so the system can process more before it degrades. Appendix #1. Technical Details Azure App Service: B1, 100 ACU, 1,75 Gb Memory, A-Series compute equivalent. Azure SQL Database: Standard S4: 200 DTUs, 500 Mb storage. SQL Connection settings: Max Pool Size=200. Azure App Service: B1, 100 ACU , 1,75 Gb Memory, A-Series compute equivalent. ACU Azure SQL Database: Standard S4: 200 DTUs, 500 Mb storage. SQL Connection settings: Max Pool Size=200. Appendix #2. Notes To achieve the cleanest test result, I should have run tests from 2 VMs located in the same network where the target App Services sit. However, I assumed that a network lag would impact both apps in a more or less similar way. Therefore, it cannot jeopardize the main goal — comparing how asynchronous and synchronous methods behave. Appendix #3. Bonus Experiment Appendix #3. Bonus Experiment What did I hack to force the synchronous endpoint to perform almost as asynchronous and plot the graph below (experiment conditions are the same as in the third one — 200 users)?

Async vs Sync Benchmark (.NET): The Difference Between Asynchronous and Synchronous Methods

مقارنة بين Async وSync (.NET): الفرق بين الطرق المتزامنة وغير المتزامنة

Async vs Sync Benchmark (.NET): Asinxron və Sinxron Metodlar Arasındakı Fərq

Async vs Sync Benchmark (.NET): la diferencia entre métodos asincrónicos y sincrónicos

Async vs Sync Benchmark (.NET): a diferenza entre os métodos asíncronos e síncronos

Async vs Sync Benchmark (.NET): Az aszinkron és a szinkron módszerek közötti különbség

Async vs Sync Benchmark (.NET): la differenza tra metodi asincroni e sincroni

非同期 vs 同期ベンチマーク (.NET): 非同期メソッドと同期メソッドの違い

Async vs Sync Benchmark (.NET)៖ ភាពខុសគ្នារវាងវិធីសាស្ត្រ Asynchronous និង Synchronous Methods

Async vs Sync Benchmark (.NET): Асинхрондуу жана синхрондуу методдордун ортосундагы айырма

Async vs Sync Benchmark (.NET): różnica między metodami asynchronicznymi i synchronicznymi

Async vs Sync Benchmark (.NET): Rozdiel medzi asynchrónnymi a synchrónnymi metódami

Async vs Sync Benchmark (.NET): Musiyano uripakati peAsynchronous uye Synchronous Methods

Author:
(1) Salvatore Iaconesi, ISIA Design Florence and *Corresponding author (salvatore.iaconesi@artisopensource.net). Table of Links Abstract and 1. A Hymn 2. Asymmetry 3. Bubbles, Guinea Pigs 4. Interface and Data Biopolitics 5. Conclusions: Implications for Design and References 2. Asymmetry This scenario also describes a progressive asymmetry in the distribution of power, rights, freedoms and opportunities (Tufekci, 2014; boyd, 2012). As a matter of fact, it is practically and psychologically impossible for human beings to understand which and how much data is captured about them, how and why it is used, and what effects it has about their lives. The complex interplay among users; organisation; algorithms; national, international and global regulations and agreements, or lack of them; data and information flows within user experiences in the physical and online domains cause grey areas to emerge, at levels which are legal, cultural, psychological, ethical and philosophical (White, 2016). "Code is Law", Lawrence Lessig (2006) once said. And this is really the case nowadays. With thousands of updates and modifications to the interfaces, algorithms, data capture and usage profiles which are performed each month to the systems of popular services, potentially provoking radical changes to the implications for privacy, control and accountability, it is practically impossible for legal and cultural systems not only to adapt and react, but also and more importantly to perceive such changes and the effects they have on our freedoms, rights and expectations. If a national government needs to pass through a whole legislative process to approve a new privacy law, an operator like Facebook can change a few lines of code and yield substantial impact on users’ privacy profiles. With hundreds of thousands of modifications on platforms like these each year, it is easy to comprehend the reach of this kind of issue. Moreover, many of these changes are temporary, beta versions, running in parallel for different users for A/B testing purposes, making the situation even more complex. Things get even more radical in the case of algorithmic governance of processes, where technological entities assume progressively higher degrees of agency (and opacity). The Flash Crashes of the stock markets in 2010 are a demonstration: autonomous algorithmic agents gone berserk causing losses for billions of dollars, outside of any legal or cultural or perceptive framework (Menkveld, 2013). As a result, the levels of power and control exercised on human beings and their societies by the systems that they use are augmenting at exponential levels, and there are progressively fewer and less effective ways for people to perceive and comprehend such processes. On top of all of this, the dissemination of interfaces ubiquitously across devices, applications, websites and other products and services for which today everything can represent a front-end for digital and data based systems, further augments the incapability to understand the data and information which is captured from our behaviour and its flows and uses (Weber, 2010). Sharing a picture of our holidays at the beach on social networking sites does not imply the fact that it is clear, for us, that we are producing marketing relevant data about our tastes, consumption levels and geographical locations. And neither is the fact that while using wearable technologies or smart IoT appliances in our daily lives the data that gets captured can be used for marketing, health, insurance, financial and even job purposes. Furthermore, the rise of the Stacks (Madrigal, 2012) and, more in general, of “walled gardens”, or those situations in which applications, services and products pertain to closed, proprietary ecosystems which are not open source and for which both the front-ends and back-ends of the systems are opaque and inaccessible for inspection and understanding further aggravate this problem. Both those applications directly and, indirectly, the service levels they provide (for example through APIs, social logins, application frameworks) on the one hand make applications and services easy and rapid to develop and deploy, but, on the other hand, subject them to the concentration of power which these large operators represent. It is very convenient to design and develop anything from online services to network-connected physical products using, for example, Google’s, Apple’s, or Facebook’s platforms and services. But, by doing this, it is automatic that our products and services start producing data and information for these large operators, allowing them to interconnect these across a rich variety of domains: if I develop application A and someone else develops application B which is completely different, and we both use, for example, Facebook’s social login to implement access services, Facebook will benefit from the data generated from both applications, from the analytics which it desires to capture without even sharing them with A or B, and will be also able to interconnect both data flows with their own. For example, if application A captures, for example, my geographic location (it is, for example, an application which allows me to find where I parked my car) and I have configured my Facebook account so that Facebook is not allowed to know my geographic location, Facebook will have my position anyway, through application A. This kind of reasoning can be applied to all the applications, products and services that use these frameworks. These facts are valid and relevant for the users of these platforms, but also for the people conceiving and creating these systems, including designers, engineers, managers, administrators, public and private, who progressively lose the possibility (culturally and technically) to understand the implications of their designs. This paper is available on arxiv under CC BY 4.0 DEED license. Author: (1) Salvatore Iaconesi, ISIA Design Florence and *Corresponding author (salvatore.iaconesi@artisopensource.net). Author: Author: (1) Salvatore Iaconesi, ISIA Design Florence and *Corresponding author (salvatore.iaconesi@artisopensource.net). Table of Links Abstract and 1. A Hymn Abstract and 1. A Hymn 2. Asymmetry 2. Asymmetry 3. Bubbles, Guinea Pigs 3. Bubbles, Guinea Pigs 4. Interface and Data Biopolitics 4. Interface and Data Biopolitics 5. Conclusions: Implications for Design and References 5. Conclusions: Implications for Design and References 2. Asymmetry This scenario also describes a progressive asymmetry in the distribution of power, rights, freedoms and opportunities (Tufekci, 2014; boyd, 2012). As a matter of fact, it is practically and psychologically impossible for human beings to understand which and how much data is captured about them, how and why it is used, and what effects it has about their lives. The complex interplay among users; organisation; algorithms; national, international and global regulations and agreements, or lack of them; data and information flows within user experiences in the physical and online domains cause grey areas to emerge, at levels which are legal, cultural, psychological, ethical and philosophical (White, 2016). "Code is Law", Lawrence Lessig (2006) once said. And this is really the case nowadays. With thousands of updates and modifications to the interfaces, algorithms, data capture and usage profiles which are performed each month to the systems of popular services, potentially provoking radical changes to the implications for privacy, control and accountability, it is practically impossible for legal and cultural systems not only to adapt and react, but also and more importantly to perceive such changes and the effects they have on our freedoms, rights and expectations. If a national government needs to pass through a whole legislative process to approve a new privacy law, an operator like Facebook can change a few lines of code and yield substantial impact on users’ privacy profiles. With hundreds of thousands of modifications on platforms like these each year, it is easy to comprehend the reach of this kind of issue. Moreover, many of these changes are temporary, beta versions, running in parallel for different users for A/B testing purposes, making the situation even more complex. Things get even more radical in the case of algorithmic governance of processes, where technological entities assume progressively higher degrees of agency (and opacity). The Flash Crashes of the stock markets in 2010 are a demonstration: autonomous algorithmic agents gone berserk causing losses for billions of dollars, outside of any legal or cultural or perceptive framework (Menkveld, 2013). As a result, the levels of power and control exercised on human beings and their societies by the systems that they use are augmenting at exponential levels, and there are progressively fewer and less effective ways for people to perceive and comprehend such processes. On top of all of this, the dissemination of interfaces ubiquitously across devices, applications, websites and other products and services for which today everything can represent a front-end for digital and data based systems, further augments the incapability to understand the data and information which is captured from our behaviour and its flows and uses (Weber, 2010). Sharing a picture of our holidays at the beach on social networking sites does not imply the fact that it is clear, for us, that we are producing marketing relevant data about our tastes, consumption levels and geographical locations. And neither is the fact that while using wearable technologies or smart IoT appliances in our daily lives the data that gets captured can be used for marketing, health, insurance, financial and even job purposes. Furthermore, the rise of the Stacks (Madrigal, 2012) and, more in general, of “walled gardens”, or those situations in which applications, services and products pertain to closed, proprietary ecosystems which are not open source and for which both the front-ends and back-ends of the systems are opaque and inaccessible for inspection and understanding further aggravate this problem. Both those applications directly and, indirectly, the service levels they provide (for example through APIs, social logins, application frameworks) on the one hand make applications and services easy and rapid to develop and deploy, but, on the other hand, subject them to the concentration of power which these large operators represent. It is very convenient to design and develop anything from online services to network-connected physical products using, for example, Google’s, Apple’s, or Facebook’s platforms and services. But, by doing this, it is automatic that our products and services start producing data and information for these large operators, allowing them to interconnect these across a rich variety of domains: if I develop application A and someone else develops application B which is completely different, and we both use, for example, Facebook’s social login to implement access services, Facebook will benefit from the data generated from both applications, from the analytics which it desires to capture without even sharing them with A or B, and will be also able to interconnect both data flows with their own. For example, if application A captures, for example, my geographic location (it is, for example, an application which allows me to find where I parked my car) and I have configured my Facebook account so that Facebook is not allowed to know my geographic location, Facebook will have my position anyway, through application A. This kind of reasoning can be applied to all the applications, products and services that use these frameworks. These facts are valid and relevant for the users of these platforms, but also for the people conceiving and creating these systems, including designers, engineers, managers, administrators, public and private, who progressively lose the possibility (culturally and technically) to understand the implications of their designs. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

Interface and Data Biopolitics in the Age of Hyperconnectivity: Asymmetry

Hookdeck CLI: a Free Ngrok Alternative for Async Web Dev

Introducing ApyHub Fusion: The All-in-One API Client Solution 🚀✨

This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license.
Authors:
(1) Ehud Shapiro,  Department of Computer Science and Applied Math, Weizmann Institute of Science, Israel and ehud.shapiro@weizmann.ac.il. Table of Links Abstract and Introduction
Grassroots Protocols
Grassroots Implementation of Grassroots Dissemination
Applications of Grassroots Dissemination Supporting Digital Sovereignty
Future Work & Discussion
References
A. Preliminaries: Asynchronous Distributed Multiagent Transition Systems
B. All-to-All Dissemination is not Grassroots
C. Proofs A Preliminaries: Asynchronous Distributed Multiagent Transition Systems Here we introduce definitions and results regarding asynchronous distributed multiagent transition systems [24], needed for the definition and proofs of grassroots protocols. The original reference introduces them in four stages: transition systems; multiagent; distributed; asynchronous, and in addition to proofs it includes examples illustrating the various concepts. Here, we introduce distributed multiagent transition systems at once and simplify other notions by adhering to this special case. Assume a set Π of agents, each equipped with a single and unique key-pair, and identify an agent p ∈ Π by its public key. While the set of all agents Π could in principle be infinite (think of all the agents that are yet to be born), when we refer to a particular set of agents P ⊆ Π we assume P to be finite. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Authors: (1) Ehud Shapiro,  Department of Computer Science and Applied Math, Weizmann Institute of Science, Israel and ehud.shapiro@weizmann.ac.il. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Authors: Authors: (1) Ehud Shapiro,  Department of Computer Science and Applied Math, Weizmann Institute of Science, Israel and ehud.shapiro@weizmann.ac.il. Table of Links Abstract and Introduction Grassroots Protocols Grassroots Implementation of Grassroots Dissemination Applications of Grassroots Dissemination Supporting Digital Sovereignty Future Work & Discussion References A. Preliminaries: Asynchronous Distributed Multiagent Transition Systems B. All-to-All Dissemination is not Grassroots C. Proofs Abstract and Introduction Abstract and Introduction Grassroots Protocols Grassroots Protocols Grassroots Implementation of Grassroots Dissemination Grassroots Implementation of Grassroots Dissemination Applications of Grassroots Dissemination Supporting Digital Sovereignty Applications of Grassroots Dissemination Supporting Digital Sovereignty Future Work & Discussion Future Work & Discussion References References A. Preliminaries: Asynchronous Distributed Multiagent Transition Systems A. Preliminaries: Asynchronous Distributed Multiagent Transition Systems B. All-to-All Dissemination is not Grassroots B. All-to-All Dissemination is not Grassroots C. Proofs C. Proofs A Preliminaries: Asynchronous Distributed Multiagent Transition Systems Here we introduce definitions and results regarding asynchronous distributed multiagent transition systems [24], needed for the definition and proofs of grassroots protocols. The original reference introduces them in four stages: transition systems; multiagent; distributed; asynchronous, and in addition to proofs it includes examples illustrating the various concepts. Here, we introduce distributed multiagent transition systems at once and simplify other notions by adhering to this special case. Assume a set Π of agents, each equipped with a single and unique key-pair, and identify an agent p ∈ Π by its public key. While the set of all agents Π could in principle be infinite (think of all the agents that are yet to be born), when we refer to a particular set of agents P ⊆ Π we assume P to be finite.

Grassroots Distributed Systems: Preliminaries: Asynchronous Distributed Multiagent Transition System

Virtual Meetings have become an essential part of corporate collaboration, serving as the de facto way that ideas are exchanged, decisions are made, and strategies are devised. However, the true value of meetings is often diluted by their length and the complexity of the discussions. This is why note-taking and effective summaries and action points are so important. Converting long and often pointless discussions into short (actionable) summaries, meeting attendees can quickly catch up on meetings they missed, review decisions that were made, and understand discussions without having to sift through hours and hours of recordings. We thought it would be cool to create our summarizer. If you don't have one already, keep reading. This technical tutorial will guide you through creating a simple web application that summarizes daily meeting Transcripts using ApyHub’s AI Summarize Document API using NodeJS. Pre-requisites: Access to Google Meet and permission to access meeting transcripts.
A preferred programming language environment (e.g., Python).
ApyHub Account.
GitHub CLI is installed on your computer. Step 1: Clone the GitHub repository Open your terminal and run this command: git clone https://github.com/iamspathan/AI-Transcript-Summarizer.git This command will clone the project in your local environment. Once the project is cloned, you can open the repository in the code editor. Step 2. Install Required Packages: Here, in Node Package Manager (npm), we will install all the dependencies that our application needs to summarize the meeting transcribe. npm install Step 3: Add your API Key to the index.js file. Here, we will add our Secret API key from ApyHub. To generate an API key, you can visit the documentation page of AI Summarize Document API. Your secret looks like this ➡️
apy-token: APY****************************************** Copy this token and paste it in as shown in the code comment below. const express = require('express');
const fileUpload = require('express-fileupload');
const cors = require('cors');
const axios = require('axios');
const FormData = require('form-data');
const open = require('open');
const app = express();
const port = 3000;

app.use(cors());
app.use(fileUpload());

// Serve static files from the 'public' directory
app.use(express.static('public'));

app.post('/summarize', (req, res) => {
    console.log("summarixe called", req.files.file);
    if (!req.files || Object.keys(req.files).length === 0) {
        return res.status(400).send('No files were uploaded.');
    }

    // Assuming the file is attached to the request under the key 'file'
    const file = req.files.file;

    // Prepare the file to be sent using form-data
    const formData = new FormData();
    formData.append('file', file.data, file.name);

    // Set up the request headers, including the dynamic headers from form-data and the secret-apy token.
    const requestHeaders = {
        ...formData.getHeaders(),
        'apy-token': 'ADD YOUR OWN APY-TOKEN HERE'
    };

    // Call the AI Summarize API
    axios.post('https://api.apyhub.com/ai/summarize-documents/file', formData, { headers: requestHeaders })
        .then(apiResponse => {
            // Assuming the API returns JSON with a summary field
            console.log(apiResponse.data.data.summary);
            res.send({ summary: apiResponse.data.data.summary });
        })
        .catch(error => {
            console.error('Error calling the AI Summarize API:', error);
            res.status(500).send('Failed to summarize the document.');
        });
});

app.listen(port, () => {
    console.log(`Server running at http://localhost:${port}`);
    // Open the index.html file in the default browser
    open(`http://localhost:${port}`);
}); Once you’ve added the API key. Save the changes using the Ctrl+S Key. Step 4: Running Your Application Once you’ve added the API key. Save the changes using Ctrl+S in your terminal, and run this command.: node index.js That’s it :) As you can see, Now you can generate a meeting transcript anytime you want :) Virtual Meetings have become an essential part of corporate collaboration, serving as the de facto way that ideas are exchanged, decisions are made, and strategies are devised. However, the true value of meetings is often diluted by their length and the complexity of the discussions. This is why note-taking and effective summaries and action points are so important. Converting long and often pointless discussions into short (actionable) summaries, meeting attendees can quickly catch up on meetings they missed, review decisions that were made, and understand discussions without having to sift through hours and hours of recordings. We thought it would be cool to create our summarizer. If you don't have one already, keep reading. This technical tutorial will guide you through creating a simple web application that summarizes daily meeting Transcripts using ApyHub’s AI Summarize Document API using NodeJS. ApyHub’s AI Summarize Document API Pre-requisites: Access to Google Meet and permission to access meeting transcripts. A preferred programming language environment (e.g., Python). ApyHub Account. GitHub CLI is installed on your computer. Access to Google Meet and permission to access meeting transcripts. Google Meet A preferred programming language environment (e.g., Python). ApyHub Account . ApyHub Account GitHub CLI is installed on your computer. Step 1: Clone the GitHub repository Open your terminal and run this command: git clone https://github.com/iamspathan/AI-Transcript-Summarizer.git git clone https://github.com/iamspathan/AI-Transcript-Summarizer.git This command will clone the project in your local environment. Once the project is cloned, you can open the repository in the code editor. Step 2. Install Required Packages: Here, in Node Package Manager (npm), we will install all the dependencies that our application needs to summarize the meeting transcribe. npm install npm install Step 3: Add your API Key to the index.js file. Here, we will add our Secret API key from ApyHub. To generate an API key, you can visit the documentation page of AI Summarize Document API . Your secret looks like this ➡️ apy-token: APY****************************************** AI Summarize Document API apy-token: APY****************************************** Copy this token and paste it in as shown in the code comment below. const express = require('express');
const fileUpload = require('express-fileupload');
const cors = require('cors');
const axios = require('axios');
const FormData = require('form-data');
const open = require('open');
const app = express();
const port = 3000;

app.use(cors());
app.use(fileUpload());

// Serve static files from the 'public' directory
app.use(express.static('public'));

app.post('/summarize', (req, res) => {
    console.log("summarixe called", req.files.file);
    if (!req.files || Object.keys(req.files).length === 0) {
        return res.status(400).send('No files were uploaded.');
    }

    // Assuming the file is attached to the request under the key 'file'
    const file = req.files.file;

    // Prepare the file to be sent using form-data
    const formData = new FormData();
    formData.append('file', file.data, file.name);

    // Set up the request headers, including the dynamic headers from form-data and the secret-apy token.
    const requestHeaders = {
        ...formData.getHeaders(),
        'apy-token': 'ADD YOUR OWN APY-TOKEN HERE'
    };

    // Call the AI Summarize API
    axios.post('https://api.apyhub.com/ai/summarize-documents/file', formData, { headers: requestHeaders })
        .then(apiResponse => {
            // Assuming the API returns JSON with a summary field
            console.log(apiResponse.data.data.summary);
            res.send({ summary: apiResponse.data.data.summary });
        })
        .catch(error => {
            console.error('Error calling the AI Summarize API:', error);
            res.status(500).send('Failed to summarize the document.');
        });
});

app.listen(port, () => {
    console.log(`Server running at http://localhost:${port}`);
    // Open the index.html file in the default browser
    open(`http://localhost:${port}`);
}); const express = require('express');
const fileUpload = require('express-fileupload');
const cors = require('cors');
const axios = require('axios');
const FormData = require('form-data');
const open = require('open');
const app = express();
const port = 3000;

app.use(cors());
app.use(fileUpload());

// Serve static files from the 'public' directory
app.use(express.static('public'));

app.post('/summarize', (req, res) => {
    console.log("summarixe called", req.files.file);
    if (!req.files || Object.keys(req.files).length === 0) {
        return res.status(400).send('No files were uploaded.');
    }

    // Assuming the file is attached to the request under the key 'file'
    const file = req.files.file;

    // Prepare the file to be sent using form-data
    const formData = new FormData();
    formData.append('file', file.data, file.name);

    // Set up the request headers, including the dynamic headers from form-data and the secret-apy token.
    const requestHeaders = {
        ...formData.getHeaders(),
        'apy-token': 'ADD YOUR OWN APY-TOKEN HERE'
    };

    // Call the AI Summarize API
    axios.post('https://api.apyhub.com/ai/summarize-documents/file', formData, { headers: requestHeaders })
        .then(apiResponse => {
            // Assuming the API returns JSON with a summary field
            console.log(apiResponse.data.data.summary);
            res.send({ summary: apiResponse.data.data.summary });
        })
        .catch(error => {
            console.error('Error calling the AI Summarize API:', error);
            res.status(500).send('Failed to summarize the document.');
        });
});

app.listen(port, () => {
    console.log(`Server running at http://localhost:${port}`);
    // Open the index.html file in the default browser
    open(`http://localhost:${port}`);
}); Once you’ve added the API key. Save the changes using the Ctrl+S Key. Ctrl+S Step 4: Running Your Application Once you’ve added the API key. Save the changes using Ctrl+S in your terminal, and run this command.: node index.js node index.js That’s it :) As you can see, Now you can generate a meeting transcript anytime you want :)

Building an AI-Powered Summarizer using NodeJS and ApyHub API To Make Meetings Easy

Designed for developers at the intersection of curiosity and professional growth, this primer aims to illuminate how asynchronous programming can elevate application performance, scalability, and responsiveness. By focusing on the universal principles of non-blocking operations and event loops, we venture beyond specific technologies like AsyncIO, Node.js, or Go. This exploration is crafted for software developers eager to grasp the efficiencies driving modern software without the complexity of technical jargon. Think of how a single thread handling requests is like a single-lane road in a busy city: each request is a car, and when there's only one lane, cars line up, causing delays. But what if our city — our service — could manage traffic more cleverly? That's where the magic of an asynchronous runtime comes into play. It's like adding an intelligent traffic system to our city, guiding cars through multiple lanes and intersections without waiting. This system keeps traffic flowing smoothly, ensuring no car (or task) waits too long, which is precisely how an asynchronous runtime keeps our software running efficiently. Let's consider an example of a service that completes I/O operations synchronously. For clarity, these operations are shown outside the main flow of execution in the diagram: Blocking I/O during your service's startup phase might be acceptable, but avoiding this approach when processing external requests is advisable. The following diagram illustrates how service efficiency can be enhanced through the adoption of non-blocking I/O operations: These examples highlight scenarios where the server's performance gains are maximized. Nevertheless, the advantage of non-blocking operations persists across any frequency of incoming requests. Even in less-than-ideal conditions, performance benefits from integrating dedicated I/O threads into the processing workflow. The total time required to process a request (from the client's initial request to the final response, as depicted by the blue number on the right) will invariably decrease, provided there are sufficient threads to handle all requests. In the worst-case scenario, this duration will not surpass that of synchronous processing methods. We then encounter a practice that might seem counterintuitive to many developers. When I/O operations constitute a significant portion of request processing time, optimizing other code segments may yield slight improvement. The duration to fetch data from a cache might align closely with the time dedicated to business logic and template rendering. Employing caching or an in-process database can reduce data retrieval times compared to other processing activities. To segment code effectively and facilitate callback execution, one can instruct the runtime to proceed to the next event loop cycle. Below is an illustrative example of how this concept is applied: // blocking callbacks
function func1_cb(str, cb) {
 var res = func1(str);
 cb(res);
}

function func2_cb(str, cb) {
 var res = func2(str);
 cb(res);
}

// non-blocking callbacks
function func1_cb(str, cb) {
 var res = func1(str);
 process.nextTick(function () {
   cb(res);
 });
}

function func2_cb(str, cb) {
 var res = func2(str);
 process.nextTick(function () {
   cb(res);
 });
}

// usage example
func1_cb(content, function (str) {
 func2_cb(str, function (result) {
   // work with result
 });
}); By adopting this methodology to split two parts of calculations, the overall processing time for scenarios with nearly concurrent request arrivals remains the same. However, the response to the first request is delayed: This scenario represents the least favorable outcome when employing the “next tick” strategy. As shown in the initial example, the “next tick” method proves benign for infrequent requests. Should requests arrive at a moderate pace, leveraging this technique enhances processing speed by allowing the initiation of new requests and the start of non-blocking operations to be interleaved during execution breaks. This approach effectively reduces both the total processing time and the average time per request: In conclusion, adopting non-blocking I/O is crucial for enhancing application performance and beneficial in environments with both sparse and heavy incoming request volumes. Additionally, effectively sequencing the execution flow — illustrated by concepts similar to the "next tick" technique — significantly improves server efficiency. Embracing these asynchronous programming practices offers clear advantages over traditional, synchronous methods.

Stories, News & Mentions about APSY

Apsy’s Stories on HackerNoon